Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development

[Jorge Manuel B. S. Vicetto]

-----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/

iQIcBAEBAgAGBQJMWTXuAAoJEC8ZTXQF1qEPp3EQAMfpoiEuXuPN8sWF1ZFG27M4
yvZC2ZLRfnp1mK8adT8LewkoVgBh4Plmyc0kaNZKBOMRUtIDZ1uun3lFJr6SbLwH
i8E5OSSsotWubuo3iSYVaP1tefOxx6GtJqly86uIYbrFZE1HVsJ2j0DrL3pkO+b6
PMLi0mof4a3iVNhzNWiA0t9sETvzevYHHOgVg2c609w73oQBVDQnnyH0f7Il0Q3p
9GjylllHXLEYuw9Fn4vtqKfTwgnhOBGfGHG+GSWBcU1rAhImwGzQOVoUBpPSpXHS
gR5Pf+lhO5yYc6eCruCSfhkZjYoa3Zl9UW+ulu4zpNJQwvZo9qpoGyAehZ+uKHgU
UgJPF4haQHZcJKGJjvMLI5hsSXbIAUKyDmLcm+2cIDj65WhePn4GoCZHzeRfOyTk
/86vYW+gB0YcG7yThhkF8TBGimkaWAcWI69FEgRa/BPMMjGpc0JMQcbvSZjVL8jI
Y1V9/qt3mqtYvNpNnHAXllb5nH7UwLNldSEqlHZ1wUGfU77/0w1BEJ9m4fulUm1u
Bi/YmU4PcRiBzmDwnPsNtNckBNpPwVM9h4uAyC5g4sWefRc9RdOpZR0+ADD959hn
DU1+LJn/mEC9Wr/AHV+8FtJaDcYUALbd/MyrWoOl/IFcEg5j+hZkktPuMXRdJOhU
pMlw72B+TmyFJFF3gQ7P
=Inrp
-----END PGP SIGNATURE-----