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