Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Fri, 2006-01-06 at 18:11 -0500, Olivier Crete wrote: On Fri, 2006-06-01 at 09:39 -0800, Brian Harring wrote: On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote: On 06/01/06, Brian Harring [EMAIL PROTECTED] wrote: 1) Manpower. There are already 10,000 open bugs in bugzilla (and growing) without adding more. This is probably the primary reason it died. This, of course, ties in greatly to #2. Automation can reduce workload, within limits. Fex, scripting for yanking packages/deptree out of normal tree for merging into a g19 tree. Baz has developed a script that would yank a subtree with the proper deps for the original GLEP 19 effort. It wasn't that hard to do. No, but it (at least from the last message that I saw) did not update Manifests/digests. And the idea of having a subtree is that the backports would be done by a specific group of developers instead of the package maintainers and therefore not getting any more work on the other devs. This would still be the case. However, having a subtree such as the one that was used by GLEP19 severely reduces the usability. For one, the number of USE flags was reduced to only server USE flags, and even then it only included the common ones and omitted all of the others, making it even less useful and impossible for supporting an Enterprise Workstation from the same tree. I'm not really sure why the older one died... We were pretty close to being able to build the stages and starting to distribute it... I would be very favorable to seeing the whole thing restarted. I'm pretty sure it died due to lack of involvement. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote: On 06/01/06, Brian Harring [EMAIL PROTECTED] wrote: Probably better to iron out what y'all actually need and what the dev community is willing to put up with. Eg, would do some research into it, read the archives from last few wars over it, in general find (and address) the issues that lead to glep19 going still born. The problems being: 1) Manpower. There are already 10,000 open bugs in bugzilla (and growing) without adding more. This is probably the primary reason it died. This, of course, ties in greatly to #2. Automation can reduce workload, within limits. Fex, scripting for yanking packages/deptree out of normal tree for merging into a g19 tree. Doing it by hand is possible, but error prone- same reason we have ekeyword, bit harder to screw things up via ekeyword (and it's a bit quicker in use then loading up $EDITOR). 2) Lack of interest. Most developers aren't interested in supporting old packages. I tend to believe interest is there- specifically resources/manpower to do it. That said, I don't think anyone has yet provided the folks who are interested any way to help- hell, can't even tap interested folk to help with maintaining the ebuild subset at this point since their is no subset. Hell, script work that needs be done, nothing has been done in that direction either- again, specifics haven't been stated, so there isn't anything to contribute on. Not going to find people doing all the work for you, but if _something_ were available for people to build from I'd expect more folks to jump in and help. The only real subset that can easily work without dramatically increasing workload is to limit to only arch rather than both arch and ~arch. This is simply because it can be scripted. Agreed on pulling from arch. 3) The enterprise. Both of the above problems would be fixed if enterprises were contributing developers and/or money. However, they aren't, so why is that? The truth is most enterprises want to go to a big company to buy their software. They want one homogeneous binary system, not a flexible way of building packages from source, and they want someone else to do it and be responsible for it. While I don't think enterprise support is necessary to accomplish a stable portage tree, it certainly wouldn't hurt. Tend to think either we wait for someone to step in and contribute (potentially waiting a _long_ time), or just do it. Kind of obvious my preferred route is just do it ;) Truthfully, for any large enterprise, the company will be maintaining a fair number of their own packages, with custom patches and whatnot. Where I work, we use Red Hat Enterprise Linux. Why? Because we can pay for support. That isn't the point I am going to make here, however. We also have to maintain several hundred RPM packages that either are not included in RHEL or modified by us in some way. What this means is we are now in the business of maintaining a package set, using arguably inferior tools versus ebuilds and portage. The binary support in portage does make it very possible to build once, deploy everywhere quite easily. The binary support is a bit weak- realistically, for a binpkg distro based off of gentoo, it would need a bit of an enema to improve it. So... consider that a statement of proposals welcome on how to improve it. Right now, since (same with ebuild support) the format is effectively hardcoded into portage, it's hard to replace/make large changes to binpkg format. Abstraction work has/is underway to resolve that (something that help would be appreciated on also). ~harring pgpz8eZVbUoZQ.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Fri, 2006-06-01 at 09:39 -0800, Brian Harring wrote: On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: On Fri, 2006-01-06 at 09:00 +, Chris Bainbridge wrote: On 06/01/06, Brian Harring [EMAIL PROTECTED] wrote: 1) Manpower. There are already 10,000 open bugs in bugzilla (and growing) without adding more. This is probably the primary reason it died. This, of course, ties in greatly to #2. Automation can reduce workload, within limits. Fex, scripting for yanking packages/deptree out of normal tree for merging into a g19 tree. Baz has developed a script that would yank a subtree with the proper deps for the original GLEP 19 effort. It wasn't that hard to do. And the idea of having a subtree is that the backports would be done by a specific group of developers instead of the package maintainers and therefore not getting any more work on the other devs. I'm not really sure why the older one died... We were pretty close to being able to build the stages and starting to distribute it... I would be very favorable to seeing the whole thing restarted. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
Hi, I was recently reading this post [1] about gentoo's future, it mentioned a few items in relation to enterprise Gentoo, and that it currently needs features that just aren't available yet. One such example of a feature thats not available yet is GLEP 19: Gentoo Stable Tree [2]. Now, I notice that it is over a year old since last edit, and that it is still Draft, not Differed or Rejected. So, I propose to change it in hopes of making it a feasible, implementable idea. The part of this GLEP that specifically is the issue, and making it unable to be voted on, is the section concerning the exact details of how/where the 'stable' tree would be located; currently this GLEP lists a few ideas but settles on using KEYWORDS=stable. However, the point was brought up (and noted inside of the GLEP) that in order for that new keyword to work for independent archs, it would have to be 'stable:arch'. So, I am here to say 'No' to that idea. Specifically because I believe it will make dev even greater then what it currently is. Hence I propose that instead of a separate tree based on these 'stable:arch' keywords, the existing tree is used /with/ a new keywording system: KEYWORDS=+arch will denote these stable ebuilds. Also, in order to prevent excess dev-work and to make a predictable cycle, the following will also occur: prior to the release of the year's .0 media (ex 2006.0) a script would be ran that add +arch for each arch keyword (max one +arch per arch). Over the course of time, major bug fixes and security updates would allow for items to be marked +arch quickly, without necessarily waiting for the next media release. When the .0 media is released, it would include the usual portage tree in tar.bz2 which will serve as a static place for enterprise to install Gentoo from. All security and Major bug fixes would be included in .1 and .2 releases, but the vast majority of the tree would remain the same over the course of the year (enterprise's goals). Also, a few items which can be considered for this stable tree: - using a simple script it would be possible to make a copy of the tree which only contains these +arch entries, this could be used to make easier to manage tar balls of the stable tree for distribution to clients. - the existing portage code would consider +arch as a subset of arch, the reason both keywords will exist is to maintain compatibility with older versions of portage which will not recognize this. Anyways, I would personally like to see if this can stir some interest. I would be willing to help test and help make this GLEP a reality, however I can not implement this myself as I lack python skills, but I do want to help the portage team, as much as I can, to make this happen, as I have some great benefit from this added feature. Also, I hope I covered everything, and if the response from the mailing list is good I may consider revising the existing GLEP and prepare it for submittal to the council in feburary, or march, depending on how much revision the GLEP needs, and if my idea is better or worse then the current solution proposed. Thanks for taking the time to look at this, Please respond with personal opinions (+ and -) Andrew Muraco Tuxp3 [1] http://article.gmane.org/gmane.linux.gentoo.devel/34870 [2] http://www.gentoo.org/proj/en/glep/glep-0019.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
noticed something that doesn't make any sense: Andrew Muraco wrote: - the existing portage code would consider +arch as a subset of arch, the reason both keywords will exist is to maintain compatibility with older versions of portage which will not recognize this. would make more sense as: - portage should consider +arch as a subset of arch, however, the reason both keywords will exist is to maintain compatibility with older versions of portage, which will not recognize this new keyword. Thanks, Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Thu, Jan 05, 2006 at 11:52:22PM -0500, Andrew Muraco wrote: noticed something that doesn't make any sense: Andrew Muraco wrote: - the existing portage code would consider +arch as a subset of arch, the reason both keywords will exist is to maintain compatibility with older versions of portage which will not recognize this. would make more sense as: - portage should consider +arch as a subset of arch, however, the reason both keywords will exist is to maintain compatibility with older versions of portage, which will not recognize this new keyword. glep19 isn't going to become a reality in the next 3 months, so the backwards compatibility constraints for keywords isn't an issue. If people got this ironed out, any required keyword/metadata mods can just be slipped in via eapi (this is assuming the mods are sane and agreed upon by all, also). And yes, I'm going to *love* abusing the hell out eapi once the waiting period is up. Useful for fun stuff like this ;) ~harring pgppbvJooXJSS.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas
On Thu, Jan 05, 2006 at 11:42:36PM -0500, Andrew Muraco wrote: Anyways, I would personally like to see if this can stir some interest. I would be willing to help test and help make this GLEP a reality, however I can not implement this myself as I lack python skills, but I do want to help the portage team, as much as I can, to make this happen, as I have some great benefit from this added feature. Whoever spear heads this is going to have to know at least a bit python, so I'd suggest you learn- pretty straightforward. Would suggest diveintopython.org for starters. Portage however, is not, but if you have questions you are welcome to ask in #-portage. Not saying we're going to do all of the legwork, but we are available as a resource. Also, I hope I covered everything, and if the response from the mailing list is good I may consider revising the existing GLEP and prepare it for submittal to the council in feburary, or march, depending on how much revision the GLEP needs, and if my idea is better or worse then the current solution proposed. Probably better to iron out what y'all actually need and what the dev community is willing to put up with. Eg, would do some research into it, read the archives from last few wars over it, in general find (and address) the issues that lead to glep19 going still born. ~harring pgpt2KVMB9nK2.pgp Description: PGP signature
