[gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Andrew Muraco]

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

[Andrew Muraco]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Bainbridge]

On 06/01/06, Brian Harring <ferringb@gentoo.org> 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.
2)  Lack of interest. Most developers aren't interested in supporting
"old" packages.
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.

Look at the arch/~arch split - as a guideline ebuilds are supposed to
move from ~arch -> arch after some reasonable period of time with no
bugs reported (eg. 30 days). Yet as the friendly script shows us,
there are many ebuilds that that stuck in ~arch for a long long time.
Why? The main reason is developer interest - a lot of people only run
~arch, so the motivation is reduced. It's difficult for users to help
- in the end it's easier to mark stuff ~arch in
/etc/portage/package.keywords than to file a bug requesting that some
developer test and change the ebuild. Proper testing of a tree
requires developers to run both arch and ~arch. The stable proposals
would add yet another tree to test.

The only way I can see to solve these problems is more automation.
Link bugs directly to individual versions (or sets) of ebuilds. Have a
defined process for marking stuff stable - either x days with no bugs,
and/or through sampling of users installed packages to see what is
actually installed out there. Bug voting would fix the disconnect
between users and devs (sometimes people are interested in working on
a random problem to help gentoo - at the moment it's difficult to see
which bugs are really the important ones to users). Decentralise
development - allow users to share their own patches in a searchable
system, rather than force everything through bugzilla; add support to
portage to utilise other peoples trees - the current system of devs
publishing overlays on their web pages/svn and users having to
manually wget or svn up is too difficult for users and removes ebuilds
from the tree - so they are less visible and get less testing. For QA
gentoo really needs a compile farm with automated compile, install and
test (from those ebuilds that support it).  Make the system smarter,
instead of throwing more people at the problem.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Duncan]

Chris Bainbridge posted <623652d50601060100w2bd03634i@mail.gmail.com>,
excerpted below,  on Fri, 06 Jan 2006 09:00:59 +0000:

> The problems being:
> 
> 1)  Manpower. There are already 10,000 open bugs in bugzilla (and
> growing) without adding more.
> 2)  Lack of interest. Most developers aren't interested in supporting
> "old" packages.
> 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.

> The only way I can see to solve these problems is more automation. []
> For QA gentoo really needs a compile farm with automated compile,
> install and test (from those ebuilds that support it).  Make the system
> smarter, instead of throwing more people at the problem.

You didn't say it, but it should be self-evident.  The automation solution
is tied to money, which, ultimately, comes back to #3.

I know it's been said before, but really, Gentoo doesn't seem to fit the
enterprise  mold well enough to get the enterprise money.  There are
better fitting organizations out there, that require less direct
modificatiion to get them into the enterprise mold, so /they/ get the
enterprise money.  I know some disagree with this and think Gentoo should
be specifically targeting the enterprise, but IMO, that's not Gentoo's
niche and never will be.

OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
emerge at some point.  IMO, however, there's enough conflict with what
makes Gentoo great at what it does today, that such efforts should be
separate from Gentoo itself.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> emerge at some point.  IMO, however, there's enough conflict with what
> makes Gentoo great at what it does today, that such efforts should be
> separate from Gentoo itself.

I don't disagree with you entirely, but there's nothing stopping us from
*also* producing a "Gentoo Enterprise Linux" distribution.

Like I said, I'll post my proposal, modified to fit the times, of
course, as soon as I get a chance (it'll take a while to write back up).

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> 
>>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
>>emerge at some point.  IMO, however, there's enough conflict with what
>>makes Gentoo great at what it does today, that such efforts should be
>>separate from Gentoo itself.
> 
> 
> I don't disagree with you entirely, but there's nothing stopping us from
> *also* producing a "Gentoo Enterprise Linux" distribution.
> 
> Like I said, I'll post my proposal, modified to fit the times, of
> course, as soon as I get a chance (it'll take a while to write back up).

As seen from the discussion earlier this week, I don't think Gentoo has
the proper open-mindness to create a proper enterprise distro. There are
too many things that would get in the way of Gentoo proper to make it
work right. I agree with Duncan that the best route is an outside
project so that they don't have the constraints of Gentoo proper. Trying
to inflict the ideals of an enterprise distro into Gentoo right now will
be an uphill battle the whole way. Just look at all the comments made
from my thread earlier. You cannot make an enterprise distro without
focus or direction and a leader. You'll be stuck in committee decisions
all the time.

Not saying its impossible, but it won't be easy.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Friday 06 January 2006 16:27, Lance Albertson wrote:
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro.

This has nothing to with open-mindness, but having enough people doing the 
general maintenance of a clearly defined frozen (sub-)tree as well as 
backports to fix vulnerabilities and other critical issues, without negative 
effects on other Gentoo subprojects (like "I work now on GLEP 19 stuff and 
don't care what I leave unmaintained instead."). Don't expect that 
maintainers of packages of the current tree do backports for a GLEP 19 tree. 
This is something the proponents would need to do themselves. You can't 
expect a commitment of the whole developer crowd in something only a minority 
is interested in. This doesn't mean there can't be a frozen tree within the 
context of Gentoo or as a separate project, of course.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Fri, 2006-01-06 at 17:19 +0100, Carsten Lohrke wrote:
> On Friday 06 January 2006 16:27, Lance Albertson wrote:
> > As seen from the discussion earlier this week, I don't think Gentoo has
> > the proper open-mindness to create a proper enterprise distro.
> 
> This has nothing to with open-mindness, but having enough people doing the 
> general maintenance of a clearly defined frozen (sub-)tree as well as 
> backports to fix vulnerabilities and other critical issues, without negative 
> effects on other Gentoo subprojects (like "I work now on GLEP 19 stuff and 
> don't care what I leave unmaintained instead."). Don't expect that 
> maintainers of packages of the current tree do backports for a GLEP 19 tree. 
> This is something the proponents would need to do themselves. You can't 
> expect a commitment of the whole developer crowd in something only a minority 
> is interested in. This doesn't mean there can't be a frozen tree within the 
> context of Gentoo or as a separate project, of course.

Exactly.  I'm finishing up my proofreading and spell-checking and should
be sending out my little idea within the hour.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

Lance Albertson wrote: [Fri Jan 06 2006, 09:27:23AM CST]
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro. There are
> too many things that would get in the way of Gentoo proper to make it
> work right. I agree with Duncan that the best route is an outside
> project so that they don't have the constraints of Gentoo proper. Trying
> to inflict the ideals of an enterprise distro into Gentoo right now will
> be an uphill battle the whole way. Just look at all the comments made
> from my thread earlier. You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

I understand that you are naturally disheartened that the discussion you
started did not end as you would have liked.  Fair enough, but I think
you should also take another look at that body of responses.  Many were,
indeed, sulky "I don't wanna leader" comments, but there were also a
number of well-written, cogently-argued replies both in favor of and
opposed to what you wrote.  All in all, I would say that the discussion
you started was a net "win" for Gentoo.  (Of course, I also happen to
disagree with your premise, so I'm biased, but I hope that I'm
open-minded enough that I would feel the same if the results had gone
the other way.)  Indeed, I suggest that this reasonably well-behaved
discussion indicates that the Gentoo community is rather open-minded
itself.

Addressing your point about Enterprise Gentoo, I think you're probably
right about it needing focus, direction, and a leader, but that's quite
different from needing Gentoo as a whole to have any of those.  The
Gentoo *BSD work is a good example of how much can be done by a team 

> Not saying its impossible, but it won't be easy.

Absolutely true.  That said, there's relatively little resistance to the
concept of Enterprise Gentoo, as far as I know.  There is substantial
resistance to anything that might add additional work to
already-overwhelmed package maintainers, however, and I believe that
the lack of an acceptable solution there is what stalled things the last
time around.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Grant Goodyear wrote: [Fri Jan 06 2006, 10:46:55AM CST]
> Addressing your point about Enterprise Gentoo, I think you're probably
> right about it needing focus, direction, and a leader, but that's quite
> different from needing Gentoo as a whole to have any of those.  The
> Gentoo *BSD work is a good example of how much can be done by a team 
  working on stuff that the vast majority of our devs do not care about
  at all.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Stuart Herbert]

Hi,

On 1/6/06, Grant Goodyear <g2boojum@gentoo.org> wrote:
> Absolutely true.  That said, there's relatively little resistance to the
> concept of Enterprise Gentoo, as far as I know.  There is substantial
> resistance to anything that might add additional work to
> already-overwhelmed package maintainers, however, and I believe that
> the lack of an acceptable solution there is what stalled things the last
> time around.

I can only speak for myself, but I believe that the "enterprise"
project hasn't discovered either a winning strategy or a sustainable
one so far.

I'd like to see the "Enterprise" project put forward a clear value
proposition, and clearly demonstrate both how it will deliver that
value and how it will sustain the offering.  I'd like to see it
identify all of the required enablers, and how they will be delivered.
 I'd like to see it demonstrate an understanding of where this work
will fit well with what already happens in Gentoo, and where this work
is at odds with the existing Gentoo project.

These are all questions that I don't think GLEP 19 adequately
addresses as I read it today.

I guess that I'm asking for something that would fall somewhere
between a funding pitch and a full-blown business plan.  At the very
least, something that you could reasonably preset to a company board. 
What I feel I've been seeing so far is low-level technical planning,
and most of the discussion seems to be focused only at this level.  (I
know I'm not going to get it, but what's the harm in asking? :)

Although I admit to having concerns about whether this project can be
delivered by a volunteer workforce - and this workforce in particular
- I can't form a strong position on this, because I don't really
understand what this project is trying to achieve yet.  I can't help
but feel that what we've got at the moment is a solution-driven
project, instead of one that's benefit-driven.

An "enterprise" offering worthy of the name is to make a promise that
goes a long way beyond what Gentoo offers today (although, alas,
nowhere near as far as I wish the term "enterprise" meant).  Mark
Shuttleworth can guarantee that promise for Ubuntu from the loose
change in his pockets.  How are we doing to guarantee that promise?

And if we're not, could we stop using the "enterprise" word in
relation to this project, to ensure that casual observers don't get
the wrong idea? :)

Best regards,
Stu
--

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

On Fri, Jan 06, 2006 at 09:27:23AM -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> > On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> > 
> >>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> >>emerge at some point.  IMO, however, there's enough conflict with what
> >>makes Gentoo great at what it does today, that such efforts should be
> >>separate from Gentoo itself.
> > 
> > 
> > I don't disagree with you entirely, but there's nothing stopping us from
> > *also* producing a "Gentoo Enterprise Linux" distribution.
> > 
> > Like I said, I'll post my proposal, modified to fit the times, of
> > course, as soon as I get a chance (it'll take a while to write back up).
> 
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro.

Why should gentoo do it?  While this statement likely will be twisted 
around as "gentoo developers don't want enterprise", what I'm asking 
specifically is why pulling and maintaining a subset of ebuilds is 
something that must exist within gentoo.  We *do* have projects 
external to gentoo.

Either way, 'open-mindness' bit is off- I'm mentioning this 
alternative due to the fact that it's not a matter of 'open-mindness', 
matter of interest.  Can't make folk do what they don't give a damn 
about.

> Just look at all the comments made from my thread earlier. 
> You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

If y'all spawn an enterprise distro of gentoo you can run it however 
you want.  Sub project or external, your stuff, your decisions- 
reaction was to y'all pushing that management structure upon gentoo as 
a whole, rather then the folk who desire it.

Meanwhile, either we can discuss glep19 specifics, or continue working 
over an issue that bluntly doesn't matter right now- management 
structure matters not if y'all don't have the basic technical reqs 
nailed down.

So can we stick tech crap at this point please?

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lance Albertson wrote:
| As seen from the discussion earlier this week, I don't think Gentoo has
| the proper open-mindness to create a proper enterprise distro. There are
| too many things that would get in the way of Gentoo proper to make it
| work right. I agree with Duncan that the best route is an outside
| project so that they don't have the constraints of Gentoo proper. Trying
| to inflict the ideals of an enterprise distro into Gentoo right now will
| be an uphill battle the whole way. Just look at all the comments made
| from my thread earlier. You cannot make an enterprise distro without
| focus or direction and a leader. You'll be stuck in committee decisions
| all the time.

As a couple people have alluded to, there's very little stopping anyone
from essentially creating a sub-distribution as part of a server TLP.
Particularly if it doesn't affect the work of other people if they
aren't interested, and you can get infra to agree to whatever you need.
You can treat the lead of your server TLP as this single corporate-style
leader if you want.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvrnzXVaO67S1rtsRAhS7AJwJHeT0meNdqhSzCBgBue57wGGK2QCfcxzn
ngITehzzU+XMBrUC0z18uoM=
=Iwzg
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Fri, 2006-01-06 at 09:27 -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> > On Fri, 2006-01-06 at 02:36 -0700, Duncan wrote:
> > 
> >>OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
> >>emerge at some point.  IMO, however, there's enough conflict with what
> >>makes Gentoo great at what it does today, that such efforts should be
> >>separate from Gentoo itself.
> > 
> > 
> > I don't disagree with you entirely, but there's nothing stopping us from
> > *also* producing a "Gentoo Enterprise Linux" distribution.
> > 
> > Like I said, I'll post my proposal, modified to fit the times, of
> > course, as soon as I get a chance (it'll take a while to write back up).
> 
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro. There are
> too many things that would get in the way of Gentoo proper to make it
> work right. I agree with Duncan that the best route is an outside
> project so that they don't have the constraints of Gentoo proper. Trying
> to inflict the ideals of an enterprise distro into Gentoo right now will
> be an uphill battle the whole way. Just look at all the comments made
> from my thread earlier. You cannot make an enterprise distro without
> focus or direction and a leader. You'll be stuck in committee decisions
> all the time.

I agree with you.  My point was that it could be done, still.  Let me
get my proposal sent out and we'll see what people think.  More than
likely, it'll be something along the lines of "great idea, now where do
we find the time/money/people/goats to do it" but we can always hope.

> Not saying its impossible, but it won't be easy.

Hopefully my proposal gives enough of a split to allow for a separate
"Enterprise" solution without alienating the current developers,
dramatically increasing their workload, or changing what Gentoo
currently is and isn't...

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 4860 bytes --]

On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote:
> On 06/01/06, Brian Harring <ferringb@gentoo.org> 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.

> 2)  Lack of interest. Most developers aren't interested in supporting
> "old" packages.

Again, another of the issues.  Another problem was the insistence on
using some form of subset of the tree.  Using a subset of the tree
actually *increases* the workload rather than reduces it.  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.

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

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.

> Look at the arch/~arch split - as a guideline ebuilds are supposed to
> move from ~arch -> arch after some reasonable period of time with no
> bugs reported (eg. 30 days). Yet as the friendly script shows us,
> there are many ebuilds that that stuck in ~arch for a long long time.
> Why? The main reason is developer interest - a lot of people only run
> ~arch, so the motivation is reduced. It's difficult for users to help
> - in the end it's easier to mark stuff ~arch in
> /etc/portage/package.keywords than to file a bug requesting that some
> developer test and change the ebuild. Proper testing of a tree
> requires developers to run both arch and ~arch. The stable proposals
> would add yet another tree to test.

The current stable proposals do, yes.

I'll post up my proposal (in another email), which I believe I had given
a couple years ago, somewhere around when GLEP19 was introduced.  Given
it has been a while, I can't say for certain exactly what order anything
came about in, so I won't even try.

> The only way I can see to solve these problems is more automation.
> Link bugs directly to individual versions (or sets) of ebuilds. Have a
> defined process for marking stuff stable - either x days with no bugs,
> and/or through sampling of users installed packages to see what is
> actually installed out there. Bug voting would fix the disconnect
> between users and devs (sometimes people are interested in working on
> a random problem to help gentoo - at the moment it's difficult to see
> which bugs are really the important ones to users). Decentralise
> development - allow users to share their own patches in a searchable
> system, rather than force everything through bugzilla; add support to
> portage to utilise other peoples trees - the current system of devs
> publishing overlays on their web pages/svn and users having to
> manually wget or svn up is too difficult for users and removes ebuilds
> from the tree - so they are less visible and get less testing. For QA
> gentoo really needs a compile farm with automated compile, install and
> test (from those ebuilds that support it).  Make the system smarter,
> instead of throwing more people at the problem.

All of these solutions I think are good period, not just to be for some
"enterprise" usage, especially multiple repositories (it's coming, yay!)
and automated build systems.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3974 bytes --]

On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote:
> > On 06/01/06, Brian Harring <ferringb@gentoo.org> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

On Fri, 2006-01-06 at 09:39 -0800, Brian Harring wrote:
> Automation can reduce workload, within limits.  Fex, scripting for 
> yanking packages/deptree out of normal tree for merging into a g19 
> tree.

Exactly, though I am not sure GLEP19 is the right way to go anyway, as
it still put a decent additional load on ebuild developers.

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

That is the primary thing my proposal aims to solve... to give people
something to work on.

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

Perhaps a good explanation of the binpkg format would be in order to
give us a chance to determine what could/should be changed?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Duncan]

Chris Gianelloni posted <1136575828.18383.81.camel@cgianelloni.nuvox.net>,
excerpted below,  on Fri, 06 Jan 2006 14:30:28 -0500:

> Perhaps a good explanation of the binpkg format would be in order to
> give us a chance to determine what could/should be changed?

As I regularly use the binpkg features on packages I've build with
FEATURES=buildpkg, I believe I can answer this:

The format is really pretty simple.  It's a tar.bz2 (labeled as
package-ver-r#.tbz2), with some additional data appended to the end. 
As such, it can be handled with the usual tarball tools, save that they
usually complain about the extra data at the end, but proceed anyway.  I
regularly open them in mc's utar virtualfs for instance, to compare what's
actually tarballed in one version to what's in another or to what's on my
system.

The tarball itself consists of all the files in the fake-install image,
that would ordinarily be transferred to the live filesystem during the
qmerge step.  (Note that with FEATURES=buildpkg, rather than qmerging from
the fake-install image, portage creates the binpkg, then decompresses it
and does the merge from it, thereby testing the binpkg in the process.  If
something's wrong with the binpkg, the merge will fail right away, thereby
avoiding creating bad ones that cannot be relied upon.)

The extra data on the end includes a plain-text (not compressed) version
of the ebuild, very handy if that ebuild disappears from the tree for
some reason or to compare the ebuild from when the package was built with
the same one now in the tree.  The rest of the data tacked on is
essentially what's stored in /var/db/portage when the ebuild is actually
merged.  Keep in mind that the binpkg must contain all that info as it 
must be self-contained -- no portage tree need be available to merge from
binpkg.

All this extra data is packed using a call from portage to a data-packer,
then simply appended (not compressed into, literally appended) to the end
of the existing package-files tarball.  Again, the format is such that in
an emergency, the tarball itself can be extracted directly over the live
filesystem, replacing whatever damaged package files created the emergency
in the first place in the process.  This is in fact exactly the procedure
recommended in the README for emergency portage recovery (using a portage
binpkg retrieved from the internet, since most don't have
FEATURES=buildpkg toggled on and therefore don't have a local copy). 
Naturally, one is urged to backup make.conf or other such config files as
may be in the package, before doing such direct extraction.  The extractor
will normally complain about the extra data, but will ignore it and
perform the extraction anyway.

It's really quite a clever system.  Whoever came up with it came up with
a very good thing, in my book! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

Duncan wrote:
> Chris Gianelloni posted <1136575828.18383.81.camel@cgianelloni.nuvox.net>,
> excerpted below,  on Fri, 06 Jan 2006 14:30:28 -0500:
> 
> 
>>Perhaps a good explanation of the binpkg format would be in order to
>>give us a chance to determine what could/should be changed?
> 
> 
> As I regularly use the binpkg features on packages I've build with
> FEATURES=buildpkg, I believe I can answer this:
> 
> The format is really pretty simple.  It's a tar.bz2 (labeled as
> package-ver-r#.tbz2), with some additional data appended to the end. 
> As such, it can be handled with the usual tarball tools, save that they
> usually complain about the extra data at the end, but proceed anyway.  I
> regularly open them in mc's utar virtualfs for instance, to compare what's
> actually tarballed in one version to what's in another or to what's on my
> system.

<snip a bunch about binpkg>

I think a key thing that is missing is build info that is only kept on
the installed system. If we were to ever create a build server setup, we
need to be able to have multiple binpkg's of the same version depending
on differences between sub-arch, use flags, cflag differences, gcc
version differences, etc. The key one i'm after is use flags. I'm not
sure of the technical details behind it, but we need something to make
the binpkgs more useful outside of the local system. Having the ebuild
packed at the end is a great idea! I think its just time to extend the
format to include more and possibly add things for build servers.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

On Fri, 2006-01-06 at 17:32 -0600, Lance Albertson wrote:
> <snip a bunch about binpkg>
> 
> I think a key thing that is missing is build info that is only kept on
> the installed system. If we were to ever create a build server setup, we
> need to be able to have multiple binpkg's of the same version depending
> on differences between sub-arch, use flags, cflag differences, gcc
> version differences, etc. The key one i'm after is use flags. I'm not
> sure of the technical details behind it, but we need something to make
> the binpkgs more useful outside of the local system. Having the ebuild
> packed at the end is a great idea! I think its just time to extend the
> format to include more and possibly add things for build servers.

USE flags are stored in the package.  The main thing is that portage
doesn't consider them, at all, unless you use --newuse, in which case if
the USE flags do not match, it will not use the package and will compile
from source.  We use this every day in Release Engineering with
catalyst.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

Chris Gianelloni wrote:
> On Fri, 2006-01-06 at 17:32 -0600, Lance Albertson wrote:
> 
>><snip a bunch about binpkg>
>>
>>I think a key thing that is missing is build info that is only kept on
>>the installed system. If we were to ever create a build server setup, we
>>need to be able to have multiple binpkg's of the same version depending
>>on differences between sub-arch, use flags, cflag differences, gcc
>>version differences, etc. The key one i'm after is use flags. I'm not
>>sure of the technical details behind it, but we need something to make
>>the binpkgs more useful outside of the local system. Having the ebuild
>>packed at the end is a great idea! I think its just time to extend the
>>format to include more and possibly add things for build servers.
> 
> 
> USE flags are stored in the package.  The main thing is that portage
> doesn't consider them, at all, unless you use --newuse, in which case if
> the USE flags do not match, it will not use the package and will compile
> from source.  We use this every day in Release Engineering with
> catalyst.

That maybe true, but if you're going to use such things on a build
server, you need to be able to have multiple tars of the same package
for the different use flags you may use. Maybe for one server setup I
need useflag foo, but another setup I don't need it. This central
repository needs to differentiate between those two needs. I know you
could make two separate binpkg dirs for those cases, but thats not
scalable at all. I was looking for something more generic.

To summarize, differentiating use flags in gentoo binary packages isn't
very scalable at the moment. A few rough ideas that just popped in my
head is either packing all of these versions into one tarball (not even
sure if thats feasible), or creating a hashed suffix based upon the
useflags enabled/disabled at the time that you append to the tarball name.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Sun, Jan 08, 2006 at 10:55:50AM -0600, Lance Albertson wrote:
> A few rough ideas that just popped in my
> head is either packing all of these versions into one tarball (not even
> sure if thats feasible)

Ugly, binpkgs are bzip2ed tarballs + xpak at the end of the bzip2 
stream, jamming multiple contents sets in would lose the ability to 
just untar the bugger to the fs in worst case.

Plus... it's nasty from a format standard, trying to determine which 
contents set to pull.  Basically have to jump to eof, read the footer, 
either store _all_ offsets there (extension of xpak format), or jump 
from there to the previous xpak, repeat till you've found what you 
want.

> , or creating a hashed suffix based upon the
> useflags enabled/disabled at the time that you append to the tarball name.
+1 on mangling the name.  Need something for keywords anyways.

Alternative is expanding the bintree format, cat/pkg-ver being a 
directory, with the binpkgs held with in...

Either way, bintree/binpkg format are all rolled into one mess, as 
stated, open to proposals to make it less sucky.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: GLEP 19: Gentoo Stable Portage Tree -- ideas

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

Brian Harring wrote:
> On Sun, Jan 08, 2006 at 10:55:50AM -0600, Lance Albertson wrote:
> 
>>A few rough ideas that just popped in my
>>head is either packing all of these versions into one tarball (not even
>>sure if thats feasible)

<snip>

>>, or creating a hashed suffix based upon the
>>useflags enabled/disabled at the time that you append to the tarball name.
> 
> +1 on mangling the name.  Need something for keywords anyways.
> 
> Alternative is expanding the bintree format, cat/pkg-ver being a 
> directory, with the binpkgs held with in...
> 
> Either way, bintree/binpkg format are all rolled into one mess, as 
> stated, open to proposals to make it less sucky.

Is there an alternative format outside of bzip2tarballs that might fit
this better? Ignoring backward compatibility, is there anything?

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Olivier Crete]

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 +0000, Chris Bainbridge wrote:
> > > On 06/01/06, Brian Harring <ferringb@gentoo.org> 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
tester@gentoo.org
Gentoo Developer


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

[Chris Gianelloni]

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 +0000, Chris Bainbridge wrote:
> > > > On 06/01/06, Brian Harring <ferringb@gentoo.org> 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