Hi.

How should we version our packages in case we've backported upstream
patches from stable branch of development? Bug 330667 requests _p or
_pre. I feel that _p|_pre versions should be left for VCS (read
development) versions of the package, while during backports we have the
best version with all important upstream+gentoo fixes available to the
moment and I'd better avoid to call it development.

If we decide to go with _p or _pre could we agree on answers for the
following questions:
- Does single patch from upstream's VCS justify _p$(date|rev) version?
What if this is _the only_ patch in the upstream's VCS?
- Now what about two patches? Three? N? When does few patches became
pile?
- What if I drop single patch from the upstream's patchset for stable
branch, should we drop _pre _p version and add -rN?
- What if there are two dependent patches, and first one fixes
indentation? Should we spend time on backporting second patch (time
consuming and error prone process) or use both and live closer to
upstream?

I think without exact answers on this questions I don't think this bug
330667 may request anything, only suggest... But what do you think?

--
Peter.

On 08/03/2010 03:03 PM, Peter Volkov wrote:
> Hi.
>
> How should we version our packages in case we've backported upstream
> patches from stable branch of development?

PV reflects the status of upstream that we base the ebuild on (usually a
release) and then we apply individual reviewed patches on top of that in
Gentoo revisions.

> Bug 330667 requests _p or
> _pre. I feel that _p|_pre versions should be left for VCS (read
> development) versions of the package, while during backports we have the
> best version with all important upstream+gentoo fixes available to the
> moment and I'd better avoid to call it development.
>

If you read the bug you will see that our python has essentially been
development versions so _p is in line with what you say above.


> If we decide to go with _p or _pre could we agree on answers for the
> following questions:
> - Does single patch from upstream's VCS justify _p$(date|rev) version?
> What if this is _the only_ patch in the upstream's VCS?

No if the patch is small and can be reasonably understood. If the patch
for example switches the used build system and I would think _p is
called for.

> - Now what about two patches? Three? N? When does few patches became
> pile?

You should ask upstream to make a release when they start to pile up.

> - What if I drop single patch from the upstream's patchset for stable
> branch, should we drop _pre _p version and add -rN?

_p reflects upstream situation so dropping a patch from that is a Gentoo
modification there so it would be _p12323-r1.

> - What if there are two dependent patches, and first one fixes
> indentation? Should we spend time on backporting second patch (time
> consuming and error prone process) or use both and live closer to
> upstream?
>

I would leave this up to the maintainer. Depends on how much time
backporting takes.

Regards,
Petteri

В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет:
> On 08/03/2010 03:03 PM, Peter Volkov wrote:
> > Bug 330667 requests _p or
> > _pre. I feel that _p|_pre versions should be left for VCS (read
> > development) versions of the package, while during backports we have the
> > best version with all important upstream+gentoo fixes available to the
> > moment and I'd better avoid to call it development.
>
> If you read the bug you will see that our python has essentially been
> development versions so _p is in line with what you say above.

Quotation from the bug:

"gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3."

Not taking into consideration that it is possible to name _p 3.1.2 I
would like to point that patches are from _stable_ branch as thus all
users want them. This is not development version.

> > If we decide to go with _p or _pre could we agree on answers for the
> > following questions:
> > - Does single patch from upstream's VCS justify _p$(date|rev) version?
> > What if this is _the only_ patch in the upstream's VCS?
>
> No if the patch is small and can be reasonably understood. If the patch
> for example switches the used build system and I would think _p is
> called for.

> > - Now what about two patches? Three? N? When does few patches became
> > pile?
>
> You should ask upstream to make a release when they start to pile up.

Yup, but since "patchset being pile" is a clause to change version, we
should formally define what is a pile. 20kb unpacked? 10 patches? Until
this is done such decision is on maintainer's discretion, like
maintainer told in comment #1.

> > - What if I drop single patch from the upstream's patchset for stable
> > branch, should we drop _pre _p version and add -rN?
>
> _p reflects upstream situation so dropping a patch from that is a Gentoo
> modification there so it would be _p12323-r1.

Rigorously speaking even dropping one patch makes it not to be _p12323
any more and we should version it somehow differently. How? Since ebuild
is based on upstream's stable tarbal obvious solution is to use the
tarbal's version.

> > - What if there are two dependent patches, and first one fixes
> > indentation? Should we spend time on backporting second patch (time
> > consuming and error prone process) or use both and live closer to
> > upstream?
>
> I would leave this up to the maintainer. Depends on how much time
> backporting takes.

After reading your answers I don't understand why the bug is still
opened and what it is about. Arfrever told that he fells that it's up to
him how to version packages. And I agree with him in this exact case.

--
Peter.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04-08-2010 07:56, Peter Volkov wrote:
> В Втр, 03/08/2010 в 22:17 +0300, Petteri Räty пишет:
>> On 08/03/2010 03:03 PM, Peter Volkov wrote:
>>> Bug 330667 requests _p or _pre. I feel that _p|_pre versions
>>> should be left for VCS (read development) versions of the
>>> package, while during backports we have the best version with
>>> all important upstream+gentoo fixes available to the moment and
>>> I'd better avoid to call it development.
>>
>> If you read the bug you will see that our python has essentially
>> been development versions so _p is in line with what you say
>> above.
>
> Quotation from the bug:
>
> "gentoo's 3.1.2 is _not_ 3.1.2, it's a pre of 3.1.3."
>
> Not taking into consideration that it is possible to name _p 3.1.2
> I would like to point that patches are from _stable_ branch as thus
> all users want them. This is not development version.

If you take KDE's team example, we provide ebuilds to track the stable
branch from upstream in our overlay. They're called <version>.9999.
It's true that our ebuild does use the live vcs, but in this case the
difference is that instead of the users using a live ebuild, they get
a snapshot of the tree done by our maintainer from time to time.
Trying to pretend these "snapshot" ebuilds are the release version is
very wrong and no one should assume they'll build fine. There are
already a few bugs that can be attributed to this.

>>> If we decide to go with _p or _pre could we agree on answers
>>> for the following questions: - Does single patch from
>>> upstream's VCS justify _p$(date|rev) version? What if this is
>>> _the only_ patch in the upstream's VCS?
>>
>> No if the patch is small and can be reasonably understood. If the
>> patch for example switches the used build system and I would
>> think _p is called for.
>
>>> - Now what about two patches? Three? N? When does few patches
>>> became pile?
>>
>> You should ask upstream to make a release when they start to pile
>> up.
>
> Yup, but since "patchset being pile" is a clause to change version,
> we should formally define what is a pile. 20kb unpacked? 10
> patches? Until this is done such decision is on maintainer's
> discretion, like maintainer told in comment #1.

The point here is that one thing is for a maintainer to pick specific
commits from the stable branch and back port them to fix some bugs,
another thing is to blindly fetch a snapshot of the stable branch.

>>> - What if I drop single patch from the upstream's patchset for
>>> stable branch, should we drop _pre _p version and add -rN?
>>
>> _p reflects upstream situation so dropping a patch from that is a
>> Gentoo modification there so it would be _p12323-r1.
>
> Rigorously speaking even dropping one patch makes it not to be
> _p12323 any more and we should version it somehow differently. How?
> Since ebuild is based on upstream's stable tarbal obvious solution
> is to use the tarbal's version.

It would be based on a release if it only applied specific patches to
fix known issues. The minute you start "tracking" a stable branch you
should stop calling it a release and 300kloc is not a "small" patch.

>>> - What if there are two dependent patches, and first one fixes
>>> indentation? Should we spend time on backporting second patch
>>> (time consuming and error prone process) or use both and live
>>> closer to upstream?
>>
>> I would leave this up to the maintainer. Depends on how much
>> time backporting takes.
>
> After reading your answers I don't understand why the bug is still
> opened and what it is about. Arfrever told that he fells that it's
> up to him how to version packages. And I agree with him in this
> exact case.

This is unfortunately the main issue here. You may work on a specific
package on Gentoo, but when that package is essential for the system
use / stability, it stops being just "your" package. This latest
example has lead users to a point where their PM stopped working.
Breaking the PM is not a small "oops" and doing it by continuously
breaking our policies or ignoring one doesn't work alone, is a very
serious offense.
Should the toolchain team start providing "testing" gcc or glibc
packages that have slight "oops" here and there that break systems?
What about the kernel team deciding to mark stable some kernel
versions with drivers that break hardware support without proper
testing? Or what about the PERL team deciding they only care about the
language and not the hundreds of packages that use it and start
pushing new versions the day they're released no matter how many
packages they break in the process?

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMWTXuAAoJEC8ZTXQF1qEPp3EQAMfpoiEuXu PN8sWF1ZFG27M4
yvZC2ZLRfnp1mK8adT8LewkoVgBh4Plmyc0kaNZKBOMRUtIDZ1 uun3lFJr6SbLwH
i8E5OSSsotWubuo3iSYVaP1tefOxx6GtJqly86uIYbrFZE1HVs J2j0DrL3pkO+b6
PMLi0mof4a3iVNhzNWiA0t9sETvzevYHHOgVg2c609w73oQBVD QnnyH0f7Il0Q3p
9GjylllHXLEYuw9Fn4vtqKfTwgnhOBGfGHG+GSWBcU1rAhImwG zQOVoUBpPSpXHS
gR5Pf+lhO5yYc6eCruCSfhkZjYoa3Zl9UW+ulu4zpNJQwvZo9q poGyAehZ+uKHgU
UgJPF4haQHZcJKGJjvMLI5hsSXbIAUKyDmLcm+2cIDj65WhePn 4GoCZHzeRfOyTk
/86vYW+gB0YcG7yThhkF8TBGimkaWAcWI69FEgRa/BPMMjGpc0JMQcbvSZjVL8jI
Y1V9/qt3mqtYvNpNnHAXllb5nH7UwLNldSEqlHZ1wUGfU77/0w1BEJ9m4fulUm1u
Bi/YmU4PcRiBzmDwnPsNtNckBNpPwVM9h4uAyC5g4sWefRc9RdOpZ R0+ADD959hn
DU1+LJn/mEC9Wr/AHV+8FtJaDcYUALbd/MyrWoOl/IFcEg5j+hZkktPuMXRdJOhU
pMlw72B+TmyFJFF3gQ7P
=Inrp
-----END PGP SIGNATURE-----

В Срд, 04/08/2010 в 09:42 +0000, Jorge Manuel B. S. Vicetto пишет:
> If you take KDE's team example, we provide ebuilds to track the stable
> branch from upstream in our overlay. They're called <version>.9999.
> It's true that our ebuild does use the live vcs, but in this case the
> difference is that instead of the users using a live ebuild, they get
> a snapshot of the tree done by our maintainer from time to time.
> Trying to pretend these "snapshot" ebuilds are the release version is
> very wrong and no one should assume they'll build fine.

Even for official upstream releases build tests are not enough. So there
is not difference with _p here.

> There are already a few bugs that can be attributed to this.

Ok, let's say that this depends on upstream. And for Gentoo this means
that the decision how to set version for the package depends on
maintainer. Lot's of packages do not have dedicated release tests
upstream (even build tests) and for this packages I don't see difference
between stable branch and release. In such case our version just
indicates that our package is base on tarbal of that version and nothing
more.

> The point here is that one thing is for a maintainer to pick specific
> commits from the stable branch and back port them to fix some bugs,
> another thing is to blindly fetch a snapshot of the stable branch.

In reality it's hard to see difference if commit was done blindly or it
was well tested until obvious crash happens.

> It would be based on a release if it only applied specific patches to
> fix known issues. The minute you start "tracking" a stable branch you
> should stop calling it a release and 300kloc is not a "small" patch.

Actually I think this limit depends on size of project. In any case
until we have something documented that's up to maintainer...

> This is unfortunately the main issue here. You may work on a specific
> package on Gentoo, but when that package is essential for the system
> use / stability, it stops being just "your" package. This latest
> example has lead users to a point where their PM stopped working.
> Breaking the PM is not a small "oops"

That's completely different topic... I'm not talking about stability at
all. Of course, python is special package and should be treated/tested
by maintainers as such! Probably for such core packages ~arch is not
enough and we need different process... But that a different topic.

Bug I mentioned pretends that we have policy how to set version for
packages that use backported upstream patches. My point is that there is
no such policy and line between _p or -rN is very fuzzy to set such
policy. Thus bug itself is INVALID...

--
Peter.

On 4.8.2010 16.05, Peter Volkov wrote:

>
> Bug I mentioned pretends that we have policy how to set version for
> packages that use backported upstream patches.

Snapshotting a branch that is becoming next release is not backporting.

Regards,
Petteri

On Wed, Aug 04, 2010 at 05:05:11PM +0400, Peter Volkov wrote:
> В Срд, 04/08/2010 в 09:42 +0000, Jorge Manuel B. S. Vicetto пишет:
> > There are already a few bugs that can be attributed to this.
>
> Ok, let's say that this depends on upstream. And for Gentoo this means
> that the decision how to set version for the package depends on
> maintainer. Lot's of packages do not have dedicated release tests
> upstream (even build tests) and for this packages I don't see difference
> between stable branch and release. In such case our version just
> indicates that our package is base on tarbal of that version and nothing
> more.

The core thing people are ignoring in this discussion is that when you
do the following in your python consuming code-

python -c 'import sys.version;print sys.version_info'
(2, 6, 5, 'final', 0)

You know what version of python you're running- not even version as
much as what the api is. Code relies on this.

When a 2.6.5 is actually a 2.6.6rc* in API but still exporting
sys.version == 2.6.5, you screw up consuming code's ability to detect
the version and adjust itself accordingly.

That right there is a serious problem. Combine that with gentoo's
longstanding history of patching things to make it work, but not going
insanely beyond that and you've got a pretty strong qa/policy
conflict. If you doubt this history, why not look through the python
projects previous patch-

http://overlays.gentoo.org/proj/python/browser/patches

The point people miss in this discussion is that python isn't some
standalone pkg- a lot of code consume's it's api's. As such silently
pulling in api changes that will land in 2.6.6 starts becoming
_extremely_ problematic, and it's contrary to longstanding gentoo
maintenance.


> > This is unfortunately the main issue here. You may work on a specific
> > package on Gentoo, but when that package is essential for the system
> > use / stability, it stops being just "your" package. This latest
> > example has lead users to a point where their PM stopped working.
> > Breaking the PM is not a small "oops"
>
> That's completely different topic... I'm not talking about stability at
> all. Of course, python is special package and should be treated/tested
> by maintainers as such! Probably for such core packages ~arch is not
> enough and we need different process... But that a different topic.
>
> Bug I mentioned pretends that we have policy how to set version for
> packages that use backported upstream patches. My point is that there is
> no such policy and line between _p or -rN is very fuzzy to set such
> policy. Thus bug itself is INVALID...

This is essentially lawyering; it's not bad until someone creates
a rule saying it's bad, even if historical precedent proceeds it.
Trying to legislate every possible scenario of common sense/sane
maintenance practices leads to insanity. Godel had something to say
about this

Gentoo generally speaking, is fixed versions of upstream released. We
do have integration done, but we don't monkey patch the hell out of
their releases- notice also I said 'fixed'.

Trying to make 2.6.5 a 2.6.6 isn't exactly "fixing it"- yes there are
fixes that should be pulled from the maintenance branch, but there is
a very real difference between selective cherry picking and full scale
importation as was occuring.

~harring