Against what package do I file this BZ?

[Darryl L. Pierce]

There is at least one (likely more) scripts in use for doing mass
rebuilds that are incorrectly bumping the release value. I noticed this
before and brought it up in IRC but didn't file a bug then.

What's going on is that the script is incrementing the release by 1 but
is not rounding off the value. So, for example, from one package I
maintain (perl-qpid_proton) I see the following in the %changelog:

* Sun Aug 04 2013 Fedora Release Engineering
* <rel-eng(a)lists.fedoraproject.org&gt; - 0.4-3.1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

* Mon Jul 22 2013 Petr Pisar <ppisar(a)redhat.com&gt; - 0.4-2.1
- Perl 5.18 rebuild

* Mon Apr  1 2013 Darryl L. Pierce <dpierce(a)redhat.com&gt; - 0.4-1.1
- Changed the qpid-proton dependency to qpid-proton-c.
- Changed the qpid-proton-devel dependency to qpid-proton-c-devel.

* Fri Mar  1 2013 Darryl L. Pierce <dpierce(a)redhat.com&gt; - 0.4-1
- Rebased on Proton 0.4.

The scripts doing these mass rebuilds ought to be doing something lik:

  release = floor(current_release + 1)

rather than just bumping by 1.

-- 
Darryl L. Pierce <mcpierce(a)gmail.com&gt;
http://mcpierce.fedorapeople.org/
"What do you care what people think, Mr. Feynman?"

[Rex Dieter]

On 08/04/2013 07:14 AM, Darryl L. Pierce wrote:
>  There is at least one (likely more) scripts in use for doing mass
>  rebuilds that are incorrectly bumping the release value. I noticed this
>  before and brought it up in IRC but didn't file a bug then. 
This is probably the rpmdev-bumpspec tool (from rpmdevtools).

-- rex

[Kevin Fenzi]

On Sun, 04 Aug 2013 09:12:06 -0500
Rex Dieter <rdieter(a)math.unl.edu&gt; wrote:

>  On 08/04/2013 07:14 AM, Darryl L. Pierce wrote:
>  > There is at least one (likely more) scripts in use for doing mass
>  > rebuilds that are incorrectly bumping the release value. I noticed
>  > this before and brought it up in IRC but didn't file a bug then.
>  
>  This is probably the rpmdev-bumpspec tool (from rpmdevtools). 
it is. 

kevin

[Michael Schwendt]

On Sun, 4 Aug 2013 08:14:17 -0400, Darryl L. Pierce wrote:

>  There is at least one (likely more) scripts in use for doing mass
>  rebuilds that are incorrectly bumping the release value. I noticed this
>  before and brought it up in IRC but didn't file a bug then.
>  
>  What's going on is that the script is incrementing the release by 1 but
>  is not rounding off the value. So, for example, from one package I
>  maintain (perl-qpid_proton) I see the following in the %changelog: 
The spec file is bad:

  Release:        3.1%{?dist}

This is a non-standard release versioning scheme, and certainly the
bumpspec script should not mess with that value beyond bumping the
most-significant number.

Odd is how the release value has been increased before:

>  * Mon Jul 22 2013 Petr Pisar - 0.4-2.1
>  - Perl 5.18 rebuild
>  
>  * Mon Apr  1 2013 Darryl L. Pierce - 0.4-1.1
>  - Changed the qpid-proton dependency to qpid-proton-c.
>  - Changed the qpid-proton-devel dependency to qpid-proton-c-devel.
>  
>  * Fri Mar  1 2013 Darryl L. Pierce - 0.4-1
>  - Rebased on Proton 0.4.

[Darryl L. Pierce]

On Sun, Aug 04, 2013 at 10:34:50PM +0200, Michael Schwendt wrote:
>  On Sun, 4 Aug 2013 08:14:17 -0400, Darryl L. Pierce wrote:
>  
>  > There is at least one (likely more) scripts in use for doing mass
>  > rebuilds that are incorrectly bumping the release value. I noticed this
>  > before and brought it up in IRC but didn't file a bug then.
>  > 
>  > What's going on is that the script is incrementing the release by 1 but
>  > is not rounding off the value. So, for example, from one package I
>  > maintain (perl-qpid_proton) I see the following in the %changelog:
>  
>  The spec file is bad:
>  
>    Release:        3.1%{?dist}
>  
>  This is a non-standard release versioning scheme, and certainly the
>  bumpspec script should not mess with that value beyond bumping the
>  most-significant number. 
I see on the package naming guidelines that this should be 3{?dist}.1.
I'll fix that in my packages for their next release.

>  Odd is how the release value has been increased before:
>  
>  > * Mon Jul 22 2013 Petr Pisar - 0.4-2.1
>  > - Perl 5.18 rebuild
>  > 
>  > * Mon Apr  1 2013 Darryl L. Pierce - 0.4-1.1
>  > - Changed the qpid-proton dependency to qpid-proton-c.
>  > - Changed the qpid-proton-devel dependency to qpid-proton-c-devel.
>  > 
>  > * Fri Mar  1 2013 Darryl L. Pierce - 0.4-1
>  > - Rebased on Proton 0.4.
>  --
>  packaging mailing list
>  packaging(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/packaging 
-- 
Darryl L. Pierce <mcpierce(a)gmail.com&gt;
http://mcpierce.fedorapeople.org/
"What do you care what people think, Mr. Feynman?"

[Darryl L. Pierce]

On Sun, Aug 04, 2013 at 08:14:17AM -0400, Darryl L. Pierce wrote:
>  There is at least one (likely more) scripts in use for doing mass
>  rebuilds that are incorrectly bumping the release value. I noticed this
>  before and brought it up in IRC but didn't file a bug then.
>  
>  What's going on is that the script is incrementing the release by 1 but
>  is not rounding off the value. So, for example, from one package I
>  maintain (perl-qpid_proton) I see the following in the %changelog:
>  
>  * Sun Aug 04 2013 Fedora Release Engineering
>  * <rel-eng(a)lists.fedoraproject.org&gt; - 0.4-3.1
>  - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
>  
>  * Mon Jul 22 2013 Petr Pisar <ppisar(a)redhat.com&gt; - 0.4-2.1
>  - Perl 5.18 rebuild
>  
>  * Mon Apr  1 2013 Darryl L. Pierce <dpierce(a)redhat.com&gt; - 0.4-1.1
>  - Changed the qpid-proton dependency to qpid-proton-c.
>  - Changed the qpid-proton-devel dependency to qpid-proton-c-devel.
>  
>  * Fri Mar  1 2013 Darryl L. Pierce <dpierce(a)redhat.com&gt; - 0.4-1
>  - Rebased on Proton 0.4.
>  
>  The scripts doing these mass rebuilds ought to be doing something lik:
>  
>    release = floor(current_release + 1)
>  
>  rather than just bumping by 1. 
Filed BZ#993058

-- 
Darryl L. Pierce <mcpierce(a)gmail.com&gt;
http://mcpierce.fedorapeople.org/
"What do you care what people think, Mr. Feynman?"

[Michael Schwendt]

On Mon, 5 Aug 2013 10:26:35 -0400, Darryl L. Pierce wrote:

>  > The scripts doing these mass rebuilds ought to be doing
> something lik:
>  > 
>  >   release = floor(current_release + 1)
>  > 
>  > rather than just bumping by 1.
>  
>  Filed BZ#993058 
Hmm, I had hoped you would agree that the script should not mess with
the release value. It already tries to cover Fedora's Package_Versioning
guidelines, i.e. the 0.x pre-release scheme, for example. So, once you've
fixed the Release in perl-qpid_proton, the script would bump as expected.
The script has bumped thousands of packages before.

On which basis should the script know when to "round up" as you describe?
The number (or whatever else, such as a snapshot date) at the right of the
leading number of %{release} could be anything. It could be the packager's
internal package revision number (e.g. "patch-level").

[Darryl L. Pierce]

On Mon, Aug 05, 2013 at 07:47:45PM +0200, Michael Schwendt wrote:
>  On Mon, 5 Aug 2013 10:26:35 -0400, Darryl L. Pierce wrote:
>  
>  > > The scripts doing these mass rebuilds ought to be doing something lik:
>  > > 
>  > >   release = floor(current_release + 1)
>  > > 
>  > > rather than just bumping by 1.
>  > 
>  > Filed BZ#993058
>  
>  Hmm, I had hoped you would agree that the script should not mess with
>  the release value. It already tries to cover Fedora's Package_Versioning
>  guidelines, i.e. the 0.x pre-release scheme, for example. So, once you've
>  fixed the Release in perl-qpid_proton, the script would bump as expected.
>  The script has bumped thousands of packages before.
>  
>  On which basis should the script know when to "round up" as you describe?
>  The number (or whatever else, such as a snapshot date) at the right of the
>  leading number of %{release} could be anything. It could be the packager's
>  internal package revision number (e.g. "patch-level"). 
If it detects that the release is something like ##%{?dist}.## then it
should drop the decimal place and increment the release number.
Repository snapshots, prereleases, etc. all use something other than a
number value (.BETA, .CR2, .20130805git, .0a1bcde3) which wouldn't get
dropped if that were the case.

But, your comment about patch levels makes me think on it more. I'll
have to consider more what I'm expecting.

-- 
Darryl L. Pierce <mcpierce(a)gmail.com&gt;
http://mcpierce.fedorapeople.org/
"What do you care what people think, Mr. Feynman?"

[Michael Schwendt]

On Mon, 5 Aug 2013 14:33:35 -0400, Darryl L. Pierce wrote:

>  > On which basis should the script know when to "round
> up" as you describe?
>  > The number (or whatever else, such as a snapshot date) at the right of the
>  > leading number of %{release} could be anything. It could be the packager's
>  > internal package revision number (e.g. "patch-level").
>  
>  If it detects that the release is something like ##%{?dist}.## then it
>  should drop the decimal place and increment the release number. 
That's a different case than what has been done in perl-qpid_proton.
But again, how should the script know whether to drop anything? And how
much to drop?
If there were an option, it would likely not be the default during
mass-rebuilds, because one cannot rule out that it wouldn't break
someone's "strange" release versioning scheme.
In either case, a "clean up" recipe would be needed. Cleaning up a
Release tag could involve dropping pieces anywhere. You wanted it to
drop something left of %dist, minor release bumps are right of %dist.

In older branches you may not want to drop anything automatically, because
the package may have seen a "minor release bump for old branches" before:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_b...

rpmdev-bumpspec can be given the -r (--rightmost) option to prefer
a minor release bump.

  $ grep Release test.spec
  Release:        4%{?dist}.1
  $ rpmdev-bumpspec -r test.spec
  $ grep Releasec -r test.spec
  Release:        4%{?dist}.2

  $ grep Release test.spec
  Release:        5%{?dist}
  $ rpmdev-bumpspec -r test.spec
  $ grep Release test.spec
  Release:        5%{?dist}.1

At the very left side, the most important thing is to bump "correctly",
i.e. to recognise Fedora's 0. prefix for pre-releases. Dropping
less significant portions of the release tag is something the packager
could do eventually (e.g. during an upgrade).

There's even an option for introducing and bumping at the very right side:

  $ grep Release test.spec
  Release:        6%{?dist}
  $ rpmdev-bumpspec -s try test.spec
  $ grep Release test.spec
  Release:        6%{?dist}.try1
  $ rpmdev-bumpspec -s try test.spec
  $ grep Release test.spec
  Release:        6%{?dist}.try2