It is a natural consequence of software development and feature addition that bugs are introduced to any system. I've noticed that portage itself doesn't follow the differentiation between arch and ~arch, and instead new releases are masked or unmasked bringing with them the entirety of their new featureset. I'd like to suggest that portage follow a stable (bugfix only) branch and restrict feature additions and major changes in the way things are done to the ~arch branch. Some issues such as those outlined in bug 16599 (while a minor example) indicate that the current state of affairs can result in a discordant filesystem layout or even cause other issues which can render the filesystem, the administrative methods employed, and/or basic system functionality impaired or non-existent. Portage itself is the most important part of Gentoo, and the process of upgrading it should be one that is trusted implicitly and absolutely by the user. Reproducible: Always Steps to Reproduce:
I agree. New portages should be released into ~arch unless it's absolutely necessary to have consistency between stable/unstable (e.g. new ebuild-related features that require all users to have a new version to continue using the tree properly). Too often people using stable are bitten by bugs that didn't come up in testing while the new release was masked.
No. It either works, or it doesn't. If it's not production ready, I'm not going to just toss it out there. package.mask _ensures_ that people aren't just messing around, and that they know the condition of the package. As for major changes, that is one of the reasons ~arch isn't employed. The issues between any major changes are remedied in the ebuilds _and_ in portage itself to limit any consequences. Random users in ~arch would probably be quite unhappy for random changes occuring on their machines. There is also a reason portage attempts to be annoying when it merges itself... People need to recognise changes. ~arch will not help this condition. I can't see a strong reason to do as requested... but if you have good reasons and suggestions, I'm listening.
What prompted this was a discussion in #gentoo between a few people who basically said that Gentoo was absolutely not production ready because new versions of the package system do not get extensive testing before it heads on into the stable branch. A few devs merge it explicitly while it's masked and that's pretty much the extent of it. Brad can provide more detailed information on the issues that came up during that discussion; the extent of my involvement was pretty much "if you don't like how it's done now, file a bug about it." The gist of the discussion was that bugs in new versions of Portage in the stable branch bork people's systems in one way or another too often. If it's in the unstable branch, from my perspective, we can say "you're using unstable - bad things happen from time to time" - basically that they're effectively beta testers by virtue of using unstable packages. What do we tell people when they're using stable and their system is borked by a bug in a new version of Portage? That if they're using Gentoo they're beta testers?
Hmmmm... I can start doing something along those lines. The argument against portage there does makes sense. Large changes can hit ~arch for a couple days after a normal package.mask period.
Thanks :-) That would be excellent.
I'm all in favour of having a ~arch testing period before Portage hits my live systems. I couldn't agree more - get it out there and get it tested before it's unleashed to the world. Another point about Portage development; it's one of the only ebuilds I've encountered thus far that doesn't have a ChangeLog present. Sure, I could read the CVS commit logs, but with my burdgeoning TODO list, there's just no time. It would be nice to see atleast a summary of the major changes in each revision - especially those that require updates to /etc/[passwd|group], an `emerge sync` to "fix some filesystem permissions", update my make.globals post haste, etc.
done
2.0.47-r10 has been marked stable from the ~ branch after only about a day. Was adequate testing done to ensure that this release is stable, by the userbase or the developerbase?
-r10 fixes a lot of bugs. I can see where getting out quickly would be important.
There is _one_ new feature... That's a forced merge option in etc-update. As I said... Major changes I'll leave in ~arch. This was nothing resembling a major change. -r9 and -r10 are greater than 90% bug fixes, and the ~arch period for -r10 was to ensure that potential lockups/deadlocks due to permissions (ccache and cvs-src) were remedied properly.
