On Wed, 18 Nov 2015 06:59:19 -0500 Rich Freeman <ri...@gentoo.org> wrote:
> On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller <u...@gentoo.org> > wrote: > > > > And on what basis would you stabilise Portage, when there are no > > ebuilds in the tree to test its EAPI 6 code? > > > > As long as the EAPI6 code in the new portage is no more broken than > the EAPI6 code in the current stable version of portage (which doesn't > work/exist at all), it isn't much of a regression. What would be more > of a pain is dealing with fixes in stable. > > But, I don't have a problem with starting to use EAPI6 now, mainly > because the ~arch version of portage does not require any new ~arch > dependencies that would create a mess for stable users. So, if a user > needs to switch to a newer portage for a month or two it shouldn't be > that big of a deal. > The above part is fine :) But this next bit... > Actually, what is less clear to me is how portage versioning actually > works, or if we attach any meaning to the version numbers at all. > Both the stable and unstable series are on 2.2.x, but there are no > versions in the tree between 2.2.20 and 2.2.23. > So, we have 2 user groups, stable and unstable. Current stable is 2.2.20.1 current unstable is 2.2.25 <==just released So, when we release a new unstable version, unstable users upgrade, what do you think happens to the older unstable version at that point. It no longer receives much testing as the unstable users upgrade to the newer unstable version. If we feel that there is enough bugs in those that we do not want to stabilize it. Why would we keep it in the tree? Just so more users can potentially come across those bugs and open new bugs, since the old bugs for those were closed with the newer release that contains the fix? Are the bug wranglers low on work? Here is a current example: portage-2.2.23 is now old enough to consider stabilizing it. It contains a new cgroup feature. It has a bug making it difficult for people unless they again disable that feature. portage-2.2.24 has no new features, just a bunch of bug fixes. We decided that we will wait a few weeks and call for 2.2.24 to be stabilized, maybe we will wait just one week (not the normal 30 days), since 2.2.23 is out of consideration, 2.2.24 testing will dwindle to nothing in the next week as people upgrade to 2.2.25. With 2.2.4 becoming stable, why would we keep the buggy ~ 2.2.3 in the tree taking up space? We already established that ~ users will have migrated away from it. > The main thing I find painful in following ~arch on the odd package is > when maintainers drop versions quickly after bumping them. You want a package version with known serious bugs left in the tree so more people can experience them? > That tends > to result in a situation where if you follow ~arch you end up having > to accept lots of updates because none of the versions stay in the > tree long enough to actually get stabilized. that happens for some pkgs, if it happens too much for you, update less often. > Unless a ~arch package > version is so broken that it could never be stabilized it is probably > better to leave them there so that it is easier for users to drop back > from ~arch to stable without downgrading. > Rich, please re-read your above statements until you see the total failure in your logic. -- Brian Dolbec <dolsen>
