Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
On Wed, Aug 04, 2010 at 05:05:11PM +0400, Peter Volkov wrote: > В Срд, 04/08/2010 в 09:42 +, 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 pgpa0eS2sKdA8.pgp Description: PGP signature
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
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
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
В Срд, 04/08/2010 в 09:42 +, 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 .. > 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.
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
-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 .. 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 yvZC2ZLRfnp1mK8adT8LewkoVgBh4Plmyc0kaNZKBOMRUt
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
В Втр, 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.
Re: [gentoo-dev] Package version in case of upstream patches from stable branch of development
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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package version in case of upstream patches from stable branch of development
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.
