Re: [gentoo-dev] creating ebuilds

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

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

On Tuesday 06 January 2004 08:36, Allen Parker wrote:
>
> Avenj, as I recently was interested in submitting ebuilds myself.
> Could we possibly come up with a quick and easy system for devs to pop
> in, check a list of submitted ebuilds, grab ones that look interesting
> to them, test to see if they build/self-destruct, mark them as ~ARCH
> (for ARCH they can test on), either clear the initial listing and slap
> them into the tree or kick it back to the user?

With many ebuilds the actual maintenance and bugfixing is more work than 
just committing an ebuild to the tree. Basically what most devs do is 
maintain or co-maintain a number of ebuilds and handle their bugs. If 
you would be the defacto maintainer of a number of ebuilds you would 
basically be doing the same as a real dev, but with the limitation that 
there's allways someone between you and the tree. (and less bugzilla 
power)

> Personally, I found it to be a pain in the rear to see 1 1/2 yr old
> ebuilds relating to the packages I was developing ebuilds for in
> bugzilla, yet with information so stale as to be stinking the place
> up. I think that there are a lot of things that could be offered to
> Gentoo users without too much hassle by other Gentoo users as long as
> dev says "ok, that sounds fun." I mean, I got passed back and forth
> from hardened to general and back a few times and it was all because
> the devs reviewing my bug(s) didn't understand the packages.

I'm sorry for that. It however can be a sign that the tree is not ready 
for those ebuilds, or that they are in very low demand.

> I may not know C/C++ very well (minimal understanding at most), so I
> wouldn't be able to "fix" something that was broken via diff, but I
> sure as heck have the computing power to do 100s of compiles :-D and
> thoroughly test certain things before I put them live on my OWN
> production machines. Basically, I'm not a programmer, but I can
> *still* write a darned good ebuild with the proper help (thx
> Spyderous, obz and others in #gentoo-dev). Simply because I can't
> program, I can't be a dev... does that mean I can't do thorough
> package mangling/testing? Not really... In fact, I've been told, that
> with most things, if anyone can break it, I can :-D

Writing ebuilds is programming. In ebuilds you just use a different 
language (bash shell script language), but beyond being able to write 
ebuilds there is no need for an ebuild handling dev to be able to 
program. A willingness to learn is always an advantage though. In any 
case programming is absolutely not the same as knowing C or C++.

> Basically, I just find that the entire ebuild submission process could
> definitely be streamlined as to take less dev time and be more
> rewarding for the users actually doing the submissions. Including
> having user response saying, "hey, so and so just bumped package-x.y.y
> to package-x.y.z and it builds fine with a renamed and digested
> ebuild."

I would agree with that. However I don't know how to do it in a good way 
that preserves quality.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE/+qr/bKx5DBjWFdsRAjeVAJ4+jgmhB+lvwB/5V+qTjDuNae4L7QCg0O09
bbcwfONCp82pufrRAGV2y+Q=
=GDi4
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 4:33 am, Paul de Vrieze wrote:
<snip>
> > dev says "ok, that sounds fun." I mean, I got passed back and forth
> > from hardened to general and back a few times and it was all because
> > the devs reviewing my bug(s) didn't understand the packages.
>
> I'm sorry for that. It however can be a sign that the tree is not ready
> for those ebuilds, or that they are in very low demand.

If someone has gone their entire life using a rock to hammer nails and has 
never heard of a hammer before and thus doesn't have the demand for it does 
that mean that if they are told about the hammer they won't use it or have a 
demand for always having it?

Sometimes you create demand where one doesn't currently exist by simply 
telling people about the hammer.

> > Basically, I just find that the entire ebuild submission process could
> > definitely be streamlined as to take less dev time and be more
> > rewarding for the users actually doing the submissions. Including
> > having user response saying, "hey, so and so just bumped package-x.y.y
> > to package-x.y.z and it builds fine with a renamed and digested
> > ebuild."
>
> I would agree with that. However I don't know how to do it in a good way
> that preserves quality.

There is but it will take effort and time to setup. Sometimes if not always 
time is required to save time in the long run. Kind of like it takes money to 
make money. It takes time to save it. Fine grain controls on cvs are required 
now. If you want until they are fully needed then there will be a ton of 
pressure to get it done yesterday. Lets not REact let's be proactive.

If there is a way to make cvs ownership based that would be the easiest 
administration wise. As in the ebuild(s) I submit I have access to and 
nothing else.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Ciaran McCreesh]

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

On Tue, 6 Jan 2004 09:26:50 -0800 Robert Cole
<robert.cole@support4linux.com> wrote:
| > I'm sorry for that. It however can be a sign that the tree is not
| > ready for those ebuilds, or that they are in very low demand.
| 
| If someone has gone their entire life using a rock to hammer nails and
| has never heard of a hammer before and thus doesn't have the demand
| for it does that mean that if they are told about the hammer they
| won't use it or have a demand for always having it?
| 
| Sometimes you create demand where one doesn't currently exist by
| simply telling people about the hammer.

*bzzzzt*, silly analogy detected. Putting something in portage is not
telling people about it.
 
| If there is a way to make cvs ownership based that would be the
| easiest administration wise. As in the ebuild(s) I submit I have
| access to and nothing else.

Uh, that's still enough to screw up portage completely. One suitably
broken ebuild can still cause lots and lots of errors all over the
place.

I still don't see what's wrong with having a seperate repositry (eg
"breakmygentoo") for things that don't make it into the "official" tree.
(Well, actually, I see the whole "submitting bugs about things that
are caused by breakmygentoo ebuilds" issue, but a few messy public
executions by, say, Spider should sort that out... A 'tainted' flag on
emerge info would be good for that...)

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 9:39 am, Ciaran McCreesh wrote:
> On Tue, 6 Jan 2004 09:26:50 -0800 Robert Cole
>
> <robert.cole@support4linux.com> wrote:
> | > I'm sorry for that. It however can be a sign that the tree is not
> | > ready for those ebuilds, or that they are in very low demand.
> |
> | If someone has gone their entire life using a rock to hammer nails and
> | has never heard of a hammer before and thus doesn't have the demand
> | for it does that mean that if they are told about the hammer they
> | won't use it or have a demand for always having it?
> |
> | Sometimes you create demand where one doesn't currently exist by
> | simply telling people about the hammer.
>
> *bzzzzt*, silly analogy detected. Putting something in portage is not
> telling people about it.

Really? I find new software all the time in the portage tree I never even knew 
about and go to the referenced webpage to check it out. Now with the new 
online packages area that has the days ebuilds its even easier to see new 
stuff. I doubt I'm the only one but maybe I am.

> | If there is a way to make cvs ownership based that would be the
> | easiest administration wise. As in the ebuild(s) I submit I have
> | access to and nothing else.
>
> Uh, that's still enough to screw up portage completely. One suitably
> broken ebuild can still cause lots and lots of errors all over the
> place.

Then portage is more fragile than it should be. If I make an ebuild for a game 
and submit it and it causes corruption then there is a deeper problem with 
the portage tree than there should be. Submitting a new app should in no way 
effect the integrity of the portage tree. 

If what you say is true portage is badly broken. From my view outside of the 
dev circle and cvs area portage seems fine and not broken. To me postage is 
the killer app of the linux world. Damn thing has me hooked to the point I 
can't stand other distros. :)

> I still don't see what's wrong with having a seperate repositry (eg
> "breakmygentoo") for things that don't make it into the "official" tree.

Or maybe this is the staging area that I've been pushing for. All that needs 
to be done is an easy and painless way for a person with cvs access to the 
gentoo tree to approve something in the breakmygentoo tree and move it over 
to the gentoo tree if there isn't already. 

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 13:01, Robert Cole wrote:
> Or maybe this is the staging area that I've been pushing for. All that needs 
> to be done is an easy and painless way for a person with cvs access to the 
> gentoo tree to approve something in the breakmygentoo tree and move it over 
> to the gentoo tree if there isn't already. 

cp -r /path/to/breakmygentoo/category/package ~cvsroot/category/package
cd ~cvsroot/category
cvs add package package/files package/files/{filnames}
package/{filenames}
repoman scan
repoman commit

done...

This would of course only apply for a package that has already gone
through testing and is deemed stable enough for inclusion.


Also, here's a little hint for everyone:

Use repoman to check your ebuilds before submitting them, even if
submitting them to breakmygentoo.  Improper ebuilds help no one.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Peter Ruskin]

On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
> Also, here's a little hint for everyone:
>
> Use repoman to check your ebuilds before submitting them, even if
> submitting them to breakmygentoo.  Improper ebuilds help no one.

Ahh but...
$ esearch repoman
[ Results for search key : repoman ]
[ Applications found : 0 ]

Peter
-- 
======================================================================
Gentoo Linux:	Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, 
glibc-2.3.2-r3, 2.6.0-gentoo-r2-w4l)	i686 AMD Athlon(tm) XP 3200+
======================================================================


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: creating ebuilds

[Michael Sterrett -Mr. Bones.-]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 584 bytes --]

On Tue, 6 Jan 2004, Peter Ruskin wrote:

> On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
> > Also, here's a little hint for everyone:
> >
> > Use repoman to check your ebuilds before submitting them, even if
> > submitting them to breakmygentoo.  Improper ebuilds help no one.
> 
> Ahh but...
> $ esearch repoman
> [ Results for search key : repoman ]
> [ Applications found : 0 ]

qpkg -f `which repoman`
sys-apps/portage *

I think you probably have repoman on you gentoo system.

Michael Sterrett
  -Mr. Bones.-
mr_bones_@gentoo.org

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: creating ebuilds

[Peter Ruskin]

On Tuesday 06 Jan 2004 20:11, Michael Sterrett -Mr. Bones.- wrote:
> On Tue, 6 Jan 2004, Peter Ruskin wrote:
> > Ahh but...
> > $ esearch repoman
> > [ Results for search key : repoman ]
> > [ Applications found : 0 ]
>
> qpkg -f `which repoman`
> sys-apps/portage *
>
> I think you probably have repoman on you gentoo system.
>
Oooops!  So I had it all along ... thanks.

Peter
-- 
======================================================================
Gentoo Linux:	Portage 2.0.49-r20 (default-x86-1.4, gcc-3.2.3, 
glibc-2.3.2-r3, 2.6.0-gentoo-r2-w4l)	i686 AMD Athlon(tm) XP 3200+
======================================================================


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Ciaran McCreesh]

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

On Tue, 6 Jan 2004 19:53:38 +0000 Peter Ruskin
<Peter.Ruskin@dsl.pipex.com> wrote:
| On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
| > Also, here's a little hint for everyone:
| >
| > Use repoman to check your ebuilds before submitting them, even if
| > submitting them to breakmygentoo.  Improper ebuilds help no one.
| 
| Ahh but...
| $ esearch repoman

You already have it installed.

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] creating ebuilds

[Marius Mauch]

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

On 01/06/04  Peter Ruskin wrote:

> On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
> > Also, here's a little hint for everyone:
> >
> > Use repoman to check your ebuilds before submitting them, even if
> > submitting them to breakmygentoo.  Improper ebuilds help no one.
> 
> Ahh but...
> $ esearch repoman
> [ Results for search key : repoman ]
> [ Applications found : 0 ]

You already have it on your system (as 99.9% of all Gentoo users have it
and don't know about it) as it's part of portage.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] creating ebuilds

[Jan Schubert]

Peter Ruskin wrote:

>Ahh but...
>$ esearch repoman
>  
>
It's part of  sys-apps/portage.

HTH,
Jan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 14:53, Peter Ruskin wrote:
> On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
> > Also, here's a little hint for everyone:
> >
> > Use repoman to check your ebuilds before submitting them, even if
> > submitting them to breakmygentoo.  Improper ebuilds help no one.
> 
> Ahh but...
> $ esearch repoman
> [ Results for search key : repoman ]
> [ Applications found : 0 ]

emerge gentoolkit

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 14:53, Peter Ruskin wrote:
> On Tuesday 06 Jan 2004 19:26, Chris Gianelloni wrote:
> > Also, here's a little hint for everyone:
> >
> > Use repoman to check your ebuilds before submitting them, even if
> > submitting them to breakmygentoo.  Improper ebuilds help no one.
> 
> Ahh but...
> $ esearch repoman
> [ Results for search key : repoman ]
> [ Applications found : 0 ]
> 
> Peter

OK... I got a bit happy on the send button... that should have been:

emerge gentoolkit
qpkg -q `which repoman`

Anyway, it is included with portage and is pretty good at checking
ebuild syntax.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 12:26, Robert Cole wrote:
> On Tue January 06 2004 4:33 am, Paul de Vrieze wrote:
> <snip>
> > > dev says "ok, that sounds fun." I mean, I got passed back and forth
> > > from hardened to general and back a few times and it was all because
> > > the devs reviewing my bug(s) didn't understand the packages.
> >
> > I'm sorry for that. It however can be a sign that the tree is not ready
> > for those ebuilds, or that they are in very low demand.
> 
> If someone has gone their entire life using a rock to hammer nails and has 
> never heard of a hammer before and thus doesn't have the demand for it does 
> that mean that if they are told about the hammer they won't use it or have a 
> demand for always having it?
> 
> Sometimes you create demand where one doesn't currently exist by simply 
> telling people about the hammer.

Great!  Then tell people about your wonderful "hammer" and get some
support behind it.  Something does not have to be in the official
portage tree to gain support.  I can guarantee you that if there's
momentum behind it, that a developer will either pick it up and add it
officially, or possibly a new developer will be added to work with the
"hammer" if it proves to be big enough.

> > > Basically, I just find that the entire ebuild submission process could
> > > definitely be streamlined as to take less dev time and be more
> > > rewarding for the users actually doing the submissions. Including
> > > having user response saying, "hey, so and so just bumped package-x.y.y
> > > to package-x.y.z and it builds fine with a renamed and digested
> > > ebuild."
> >
> > I would agree with that. However I don't know how to do it in a good way
> > that preserves quality.
> 
> There is but it will take effort and time to setup. Sometimes if not always 
> time is required to save time in the long run. Kind of like it takes money to 
> make money. It takes time to save it. Fine grain controls on cvs are required 
> now. If you want until they are fully needed then there will be a ton of 
> pressure to get it done yesterday. Lets not REact let's be proactive.
> 
> If there is a way to make cvs ownership based that would be the easiest 
> administration wise. As in the ebuild(s) I submit I have access to and 
> nothing else.
> 
> Robert
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Eldad Zack]

On Tue, 2004-01-06 at 14:33, Paul de Vrieze wrote:

> I'm sorry for that. It however can be a sign that the tree is not ready 
> for those ebuilds, or that they are in very low demand.

Perhaps we can create some sort of repository for these kind of ebuilds,
as an outlet for the low-demand ebuilds, where a user could search for
an ebuild, and not reinvent the wheel, if a package he'd like to install
falls under this category.

Searching bugzilla would yield the same results, I assume, but it's
seems to me somewhat less inviting.


Eldad 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Eldad Zack]

On Tue, 2004-01-06 at 19:56, Eldad Zack wrote:
> On Tue, 2004-01-06 at 14:33, Paul de Vrieze wrote:
> 
> > I'm sorry for that. It however can be a sign that the tree is not ready 
> > for those ebuilds, or that they are in very low demand.
> 
> Perhaps we can create some sort of repository for these kind of ebuilds,
> as an outlet for the low-demand ebuilds, where a user could search for
> an ebuild, and not reinvent the wheel, if a package he'd like to install
> falls under this category.
> 
> Searching bugzilla would yield the same results, I assume, but it's
> seems to me somewhat less inviting.

I Just noticed breakmygentoo. maybe a link with a disclaimer from
gentoo.org would come in handy?


Eldad


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 10:02 am, Eldad Zack wrote:
> On Tue, 2004-01-06 at 19:56, Eldad Zack wrote:
> > On Tue, 2004-01-06 at 14:33, Paul de Vrieze wrote:
> > > I'm sorry for that. It however can be a sign that the tree is not ready
> > > for those ebuilds, or that they are in very low demand.
> >
> > Perhaps we can create some sort of repository for these kind of ebuilds,
> > as an outlet for the low-demand ebuilds, where a user could search for
> > an ebuild, and not reinvent the wheel, if a package he'd like to install
> > falls under this category.
> >
> > Searching bugzilla would yield the same results, I assume, but it's
> > seems to me somewhat less inviting.
>
> I Just noticed breakmygentoo. maybe a link with a disclaimer from
> gentoo.org would come in handy?

I too found and looked at breakmygentoo.net and it appears not to be much 
different than just downloading ebuilds out of bugs.gentoo.org. Kinda takes 
the joys of portage out of the picture. Seems just a lot more presentable 
than bugs.gentoo.org and a better location for those ebuilds. Still not sure 
why the dev release of gnome 2.5.x has to be there while KDE 3.2 beta is in 
the tree just masked. Seems odd. I'm a KDE person so it really doesn't matter 
other than just for understanding.

Someone in this thread said that ACCEPT_KEYWORDS isn't for unstable 
ebuilds/packages. If that's the case we don't need ACCEPT_KEYWORDS do we? I 
must have it wrong that things go from masked to ACCEPT_KEYWORDS to the 
stable tree route. I'll do more reading and educate myself as to what 
ACCEPT_KEYWORDS is for and why apps are flagged that way.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 13:33, Robert Cole wrote:
> Someone in this thread said that ACCEPT_KEYWORDS isn't for unstable 
> ebuilds/packages. If that's the case we don't need ACCEPT_KEYWORDS do we? I 
> must have it wrong that things go from masked to ACCEPT_KEYWORDS to the 
> stable tree route. I'll do more reading and educate myself as to what 
> ACCEPT_KEYWORDS is for and why apps are flagged that way.

ACCEPT_KEYWORDS is for testing *ebuilds* not for testing packages.  A
packages stability/lack thereof has little to do with its KEYWORDS.

Yes, there are many packages in the tree which would be considered
"unstable", such as the beta KDE or the development-sources, but those
are generally left unsupported and usually there for the benefit of the
project/authors.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Jan Schubert]

Eldad Zack wrote:

>I Just noticed breakmygentoo. maybe a link with a disclaimer from
>gentoo.org would come in handy?
>  
>
There would also some other sites to mention then. I personaly prefer 
www/cvs.gentoo.de, to where i submit my ebuilds which i contribute in 
bugzilla.

HTH,
Jan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Spider]

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

begin  quote
On Tue, 06 Jan 2004 20:02:13 +0200
Eldad Zack <eldad@stoneshaft.ath.cx> wrote:

> On Tue, 2004-01-06 at 19:56, Eldad Zack wrote:
> > On Tue, 2004-01-06 at 14:33, Paul de Vrieze wrote:
> > 
> > > I'm sorry for that. It however can be a sign that the tree is not
> > > ready for those ebuilds, or that they are in very low demand.
> > 
> > Perhaps we can create some sort of repository for these kind of
> > ebuilds, as an outlet for the low-demand ebuilds, where a user could
> > search for an ebuild, and not reinvent the wheel, if a package he'd
> > like to install falls under this category.
> > 
> > Searching bugzilla would yield the same results, I assume, but it's
> > seems to me somewhat less inviting.
> 
> I Just noticed breakmygentoo. maybe a link with a disclaimer from
> gentoo.org would come in handy?
> 
NO DAMMIT NO!!


<soundtrack artist="sundown" cd="glimmer" track="07" title="stab">

Okay, This thread has detoriated beyond the minimum level of sanity
needed for me to allow said people to continue their breathing.

Not personal to you, Edlad, But to everyone who are involved in the
argument  "creating ebuilds"

  BMG is broken by design.  Most of the people haven't even heard
about syntax, yet lest know the basic about the few weak concepts that
are logic and case studies.  Dont get me into dependencies and quality
control here.

I have dev status, and I've got enough old time status here to take it
on me that if BMG is linked to in the current state, I will personally
maim the one who does it, and revert their links and commits.  



Second point I want to make : If anyone touches, installs or tries to
work with BMG ebuilds, their systems should be completely -Wiped- at a
low level before ever being allowed in bugzilla. preferrably they should
be blacklisted as support-impossible.    Conflicting namespaces, library
links and pkg_  time modifications of live systems all make me want to
track down and do preventive QA.

</soundtrack>



<soundtrack artist="sundown" cd="glimmer" track="04" title="prey">

Following the idea of accepting user tested ebuilds?  Don't make me
laugh. please.  I've seen the amount of complete crud , and the lack of
the even most basic concept and ideas of quality .. . "ohh, we need
gnome here gnome-base/gnome is gnome.. yeeey...  DEPEND="gtk+" is a
great way to solve it, and so is x11-libs/qt ... of coouurse.

Or the othertime favourite.. ."but you shouldn't need that cause it will
compile without it.... And then break when it is removed because
theres no dependency on it but it was linked in an update when you had
it installed" ...  Yeaaah right.  * -GAH- *




My level of frustration here is multifold..  At one point came the idea
up that ACCEPT_KEYWORDS = ~ARCH was for broken packages..  Yeahoo yahoo.
I think you should sit down and think over the documentation and
principial ideas of QA and QC for a while.  ~arch is for -testing-
builds.  For the sake of finding such nice issues like that
libao-1.8.4-r1 doesn't work with autoconf 2.57 but will work with
2.58...

Not, because libao is a fun ultrabeta that is known to eat files in
random spite, or cause complete breakage in the system.

The fact that the author who claimed that ACCEPT_KEYWORDS should be the
broken playground  is running the hard-masked version of KDE-3.2_beta, a
version which is in itself  beyond the scope of  ACCEPT_KEYWORDS , 
ought to be enough.

</soundtrack>


Others have argumented the point about "developer care" and "developer
responsibility" as well as that of "guaranteed response time"  for me
earlier in this thread, so I won't have to go into that again here, do
I?



*sigh*

//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] creating ebuilds

[Caleb Tennis]

On Tuesday 06 January 2004 09:13 am, Allen Parker wrote:
> I think I should definitely re-state my *ideal* system for ebuild
> submission, since it wasn't understood. Bugzilla is great, I agree, but
> it's for *bugs* and as was said earlier, if a dev isn't interested in an
> ebuild, it's not going into the tree. Here's the process that I suggest,

Your idea of having a separate system for ebuild submission is a fine one and 
it has its merits.  The only drawback is "who is going to do it?".  

There's a bit of a process required here - it needs to be thought out, drawn 
up, talked about, thought about some more, then implemented.  That's an 
impetus that most people don't want to deal with.  If you're willing to do 
all of those things, and it presents a great solution to the problem, I see 
no reason why it wouldn't get used.

It's just important to remember that developer or not, we're all volunteers 
and we're all human.  This isn't directed at you, but from my experience as a 
developer the comments I hear the most often are: "Gentoo needs xxxx" or 
"xxxx doesn't work so someone needs to fix it".  After a while, you tend to 
dole back a canned "put your money where you mouth is" response.

In summary, if you have a good idea for this, GLEP it.  
http://www.gentoo.org/proj/en/glep.  Then be prepared for what comes next. :)

Caleb



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Mon January 05 2004 11:36 pm, Allen Parker wrote:
<snip>

> Basically, I just find that the entire ebuild submission process could
> definitely be streamlined as to take less dev time and be more rewarding
> for the users actually doing the submissions. Including having user
> response saying, "hey, so and so just bumped package-x.y.y to package-x.y.z
> and it builds fine with a renamed and digested ebuild."

I couldn't agree more. After all whats the ARCH for anyway if it's not really 
being used. My contributions in the past have been along the lines and 
compiling and testing and summiting info. I've got 7 systems to crunch with 
and they all use distcc. So testing and submitting bug reports to 
bugs.gentoo.org, kde.org, openoffice.org, etc has been my way of 
contributing. Now I've devoted 3 of my best systems to get really serious 
about giving back even more. 

But I want to know if the brick wall that others have hit is still there or 
not. There's been a bit o conflict in teh past where gentoo will call for 
maintainers for certain projects yet previously slapped down up and coming 
devs that want to maintain a different project. Why would they volunteer for 
the requested project after being hammered previously even if they have the 
skill to do the requested one? Would you? Who would? From my understanding 
the devs are overwhelmed right now with maintaining the current tree and need 
more people to take on maintaining packages. The egos need to go by by and 
just do a quick check to see if the ebuild and the dev have followed policy 
and mark the thing ~x86 or whatever arch it is and toss it out. If it floats 
then great they've proven themselves. If it sinks then a bit more education 
is in order, pull the package and politely ask the new dev to find and fix 
the problem and describe clearly what the problem was and what they did to 
fix it and if it apears they understand the problem and had a good solution 
toss it back in the tree to go again. It would likely float the second time.

I'm not suggesting giving someone new with no established background any sort 
of access. What I'm suggesting is basically what Allen spoke of in just 
encouraging more contributions but accepting ebuilds faster and the person 
with the proper access toss it in the tree.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

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

On Tuesday 06 January 2004 09:17, Robert Cole wrote:
> But I want to know if the brick wall that others have hit is still
> there or not. There's been a bit o conflict in teh past where gentoo
> will call for maintainers for certain projects yet previously slapped
> down up and coming devs that want to maintain a different project. Why
> would they volunteer for the requested project after being hammered
> previously even if they have the skill to do the requested one? Would
> you? Who would? From my understanding the devs are overwhelmed right
> now with maintaining the current tree and need more people to take on
> maintaining packages. The egos need to go by by and just do a quick
> check to see if the ebuild and the dev have followed policy and mark
> the thing ~x86 or whatever arch it is and toss it out. If it floats
> then great they've proven themselves. If it sinks then a bit more
> education is in order, pull the package and politely ask the new dev
> to find and fix the problem and describe clearly what the problem was
> and what they did to fix it and if it apears they understand the
> problem and had a good solution toss it back in the tree to go again.
> It would likely float the second time.

There is unfortunately a limit on the amount of devs that we can handle. 
We are still busy putting more structure in the gentoo organization, but 
we would certainly have a problem if the amount of developers increased 
drastically.

> I'm not suggesting giving someone new with no established background
> any sort of access. What I'm suggesting is basically what Allen spoke
> of in just encouraging more contributions but accepting ebuilds faster
> and the person with the proper access toss it in the tree.

Like said before, the issue is not the initial ebuild. It is the 
maintenance, including fixing bug reports and new versions. At the 
moment there are allready too many packages in the tree that are not 
actually maintained. This is partly due to the fact that  those packages 
are not easy to identify, and partly because it are just low-profile 
packages. But that does not mean that we want more of those packages. 
However when an ebuild gets committed without someone maintaining it 
that is exactly what happens. If there are too many of those orphan 
ebuilds it will reflect on the distribution (most orphan ebuilds have 
issues because of not being maintained)

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE/+rDEbKx5DBjWFdsRAoeNAJ4x9wMNJoi7CCMRqBCPJPrGOHrDUwCdGLGp
oA6tDMX7fglK22bUZ2zsy54=
=sYex
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Seemant Kulleen]

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

Listen, I'd like to chime in on this thread.  Our policy (where "our"
reflects Gentoo DevRel -- DevRel == Developer Relations) is that if you
want to be a dev, don't ask to be a dev, just be a dev.  You don't NEED
CVS access to develop, just to commit something to the tree.  In that
regard, Avenj's point (about proving thyself) was simply: do the work,
create a relationship with the gentoo dev team via bug day or through
bugzilla and cvs access follows as a natural course.  It's not
specifically a wall, as much as it is establishing a relationship of
mutual trust.  That does NOT mean that fraternising with the devs grants
you developerhood, what it does mean is that if your work is going by
seemingly unnoticed, point it out to someone.  More often than not,
however, one of the developers at least will notice your work.

As for ebuilds sitting in the tree for a year, that means a couple of
things:

1.  Nobody on the dev team has the hardware to test it (like the
opensmartcard bug [1]).

2.  There is simply a low demand for that -- if more people tested and
chimed in on a bug with their results it would likely see more action.

You see, I've taken on maintainership for some packages, with the
express understanding that any bugs get assigned to the initial
submitter.  

Basically, things can be worked out, you just have to talk to someone
about it.  Hope that helps.

Thanks,



-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E


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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

> 1.  Nobody on the dev team has the hardware to test it (like the
> opensmartcard bug [1]).

I looked this up and this is probably the best example I've seen of the low 
demand bit. I will say that if someone wants a smartcard reader to try and 
develop for it they should post an email. Heck I have a brand new one I got 
for free from amex a couple of years ago I could send someone. Sure I'd like 
it back eventually. :)

I have no problem donating equipment I've even brought stuff to the linuxworld 
when requested to. I'm going to make a habit of asking if equipment is needed 
for the booth.

> You see, I've taken on maintainership for some packages, with the
> express understanding that any bugs get assigned to the initial
> submitter.

Now this is what I'm talking about. Good job. :)

> Basically, things can be worked out, you just have to talk to someone
> about it.  Hope that helps.

And we are working it out. :) I'm gaining a much better understanding of the 
gentoo dev policies and thought processes than I ever could from the docs. 
Hopefully there are others getting benefit from this thread.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Jan Schubert]

Seemant Kulleen wrote:

>2.  There is simply a low demand for that -- if more people tested and
>chimed in on a bug with their results it would likely see more action.
>  
>
I'd like these vote things where also "normal" user can have some 
impact, like on bugs.kde.org or "Vote for a bug" at SUN's
(java) bug tracking site. Maybe this would be interessting for gentoo too...

Jan

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] creating ebuilds

[Robert Cole]

I would like to start creating ebuilds for products and maintaining them but 
I'm a little concerned that my contributions won't be accepted. Will I be 
wasting my time asking to be a maintainer for a couple of ebuilds I create 
and get them in the tree?

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Jon Portnoy]

On Mon, Jan 05, 2004 at 11:05:45PM -0800, Robert Cole wrote:
> I would like to start creating ebuilds for products and maintaining them but 
> I'm a little concerned that my contributions won't be accepted. Will I be 
> wasting my time asking to be a maintainer for a couple of ebuilds I create 
> and get them in the tree?
> 

Generally, when someone asks, my response is an automatic no.

Prove yourself and you'll be picked up as a dev.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] creating ebuilds

[Allen Parker]

> On Mon, Jan 05, 2004 at 11:05:45PM -0800, Robert Cole wrote:
> > I would like to start creating ebuilds for products and maintaining them
> but
> > I'm a little concerned that my contributions won't be accepted. Will I
> be
> > wasting my time asking to be a maintainer for a couple of ebuilds I
> create
> > and get them in the tree?
> >
> 
> Generally, when someone asks, my response is an automatic no.
> 
> Prove yourself and you'll be picked up as a dev.
Sorry, this seems a bit elitist. :(
> 
> --
> Jon Portnoy
> avenj/irc.freenode.net

Avenj, as I recently was interested in submitting ebuilds myself. Could we
possibly come up with a quick and easy system for devs to pop in, check a
list of submitted ebuilds, grab ones that look interesting to them, test to
see if they build/self-destruct, mark them as ~ARCH (for ARCH they can test
on), either clear the initial listing and slap them into the tree or kick it
back to the user?

Personally, I found it to be a pain in the rear to see 1 1/2 yr old ebuilds
relating to the packages I was developing ebuilds for in bugzilla, yet with
information so stale as to be stinking the place up. I think that there are
a lot of things that could be offered to Gentoo users without too much
hassle by other Gentoo users as long as dev says "ok, that sounds fun." I
mean, I got passed back and forth from hardened to general and back a few
times and it was all because the devs reviewing my bug(s) didn't understand
the packages.

I may not know C/C++ very well (minimal understanding at most), so I
wouldn't be able to "fix" something that was broken via diff, but I sure as
heck have the computing power to do 100s of compiles :-D and thoroughly test
certain things before I put them live on my OWN production machines.
Basically, I'm not a programmer, but I can *still* write a darned good
ebuild with the proper help (thx Spyderous, obz and others in #gentoo-dev).
Simply because I can't program, I can't be a dev... does that mean I can't
do thorough package mangling/testing? Not really... In fact, I've been told,
that with most things, if anyone can break it, I can :-D

Basically, I just find that the entire ebuild submission process could
definitely be streamlined as to take less dev time and be more rewarding for
the users actually doing the submissions. Including having user response
saying, "hey, so and so just bumped package-x.y.y to package-x.y.z and it
builds fine with a renamed and digested ebuild."

That's my 2/100ths of a monetary unit.
Allen Parker
infowolfe on irc.freenode.net


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

Hmm so I guess the message did go through... Sorry for the dupe going through. 
Got a rejected msg.

How is one suppose to "prove" themselves if they aren't allowed to contribute?

I've seen several things sit in bugs.gentoo.org with working ebuilds attached 
from other "unapproved" devs that never make it.

So from what I've seen:
Volunteer + Ebuild + Willingness to maintain = rejection

My question boils down to has this policy changed? It looks like this policy 
is changing more these days for the better. Just trying to save myself the 
frustration I've seen others going through.

I am actually very serious about this and ramped up to contribute with a test 
server, test work station and dev machine and gentoo is where I want to put 
my focus.

Robert

On Mon January 05 2004 11:15 pm, Jon Portnoy wrote:
> On Mon, Jan 05, 2004 at 11:05:45PM -0800, Robert Cole wrote:
> > I would like to start creating ebuilds for products and maintaining them
> > but I'm a little concerned that my contributions won't be accepted. Will
> > I be wasting my time asking to be a maintainer for a couple of ebuilds I
> > create and get them in the tree?
>
> Generally, when someone asks, my response is an automatic no.
>
> Prove yourself and you'll be picked up as a dev.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Jon Portnoy]

On Mon, Jan 05, 2004 at 11:39:01PM -0800, Robert Cole wrote:
> Hmm so I guess the message did go through... Sorry for the dupe going through. 
> Got a rejected msg.
> 
> How is one suppose to "prove" themselves if they aren't allowed to contribute?
> 

Whoa, there must be a major misunderstanding here. Nobody said you 
aren't allowed to contribute. What you aren't allowed to have is 
official developer status without having proven yourself. See below.

> I've seen several things sit in bugs.gentoo.org with working ebuilds attached 
> from other "unapproved" devs that never make it.
> 
> So from what I've seen:
> Volunteer + Ebuild + Willingness to maintain = rejection

Okay, let me explain a little bit about how the recruitment process 
works.

A few cases:

One, a developer sponsors someone as a new developer. They offer to act 
as mentor throughout the training period and beyond, and they're 
personally responsible for that developer. This is the usual case.

Two, a high-profile package is unmaintained and recruiters search for 
people with a history of contributions who have shown they can handle it 
and are trustworthy.

Three, someone has a history of contributions, especially on Bugzilla, 
and has shown they can do high-quality, reliable work.

I _won't_ just take someone at their word that they're capable of doing 
something. Would you put somebody with a blank resume in a critical 
position?

Additionally, there are nearly 6,000 individual packages in the tree at 
last count. Most of these are relatively trivial; they just aren't 
critical applications and do not require their own developer. For 
example, if you wanted to maintain one or two image viewers, the 
benefits (a maintainer for two low profile packages that likely do not 
require very much attention) do not outweigh the risks (another 
developer who's a potential security risk) in my view.

You would be cautious too if there were an estimated quarter of a 
million systems at stake.

Does any of this mean that people are shut out from contributing? Not at 
all.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Mon January 05 2004 11:55 pm, Jon Portnoy wrote:
> Okay, let me explain a little bit about how the recruitment process
> works.

I like it. That's a very good process. I'm talking about ebuilds here. I'll be 
honest and say I don't know how the backend of the portage tree works with 
security and all but maybe another tier would be in order if possible. Like a 
low access new ebuild access that gets queued and not actually put in the 
tree and someone with access could simply flag it to move into the tree or 
reject it sending an email back to the creator of the ebuild why.

Would simplify getting things in greatly. Then again such a process may 
already exist I don't know. If it does exist it doesn't "appear" to be in 
use. I say "appear" because it doesn't look that way to me but I don't see 
the whole picture. I get the frontend of portage only and I see apps sit for 
a year or more in bugs.gentoo.org.

> You would be cautious too if there were an estimated quarter of a
> million systems at stake.

Those systems aren't yours or any other gentoo devs responsibility. I think if 
most gentoo users/admins would really really think about it they know the 
risks they took when they started using gentoo. It's bleeding edge using 
ACCEPT_KEYWORDS or not. I understand, and if every gentoo user would really 
be honest with themselves, that my system could go POOF on the next world 
update. I know mine has a few times in the earlier days of gentoo. That's 
life on the bleeding edge.

New ebuilds are normally put in the testing area anyhow and if someone has a 
system they really care about and have ACCEPT_KEYWORDS set and merge that new 
package and it toasts their system then that's just a bummer ain't it? 
Seriously who's at fault? Besides I've seen people moan about the loss of 
their system now again but I don't recall anyone placing blame with the devs 
but maybe I missed that.

> Does any of this mean that people are shut out from contributing? Not at
> all.

Good enough for me I'll get to work on a few awesome packages that would make 
a nice edition to the tree and see what happens dispite many packages that 
currently sit in bugs.gentoo.org. Maybe they just need a maintainer and 
tester. I'll start with those. Prolly ACID first. Got a portage bug to report 
first.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Kurt Lieber]

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

On Tue, Jan 06, 2004 at 12:39:29AM -0800 or thereabouts, Robert Cole wrote:
> I like it. That's a very good process. I'm talking about ebuilds here. I'll be 
> honest and say I don't know how the backend of the portage tree works with 
> security and all but maybe another tier would be in order if possible. Like a 
> low access new ebuild access that gets queued and not actually put in the 
> tree and someone with access could simply flag it to move into the tree or 
> reject it sending an email back to the creator of the ebuild why.

You've just described bugs.gentoo.org.

Granted, plenty of ebuilds sit in there and never make it into the tree.
This is not the fault of bugzilla, however.  It is more a problem with our
process.  Ebuilds make it into the tree when a developer cares about them.
If no developer cares about them, they tend not to make it into the tree.
For right or wrong, that's how things work today.

I could see benefits to having a dedicated person, who was extremley
knowledgeable in the ins/outs of ebuild creation who did nothing else
except scan bugs.gentoo.org for new ebuilds and put them into the tree.
Whether there's a person out there with the right skill set willing to do
such a job is another question entirely.  (not saying there isn't, btw)

> > You would be cautious too if there were an estimated quarter of a
> > million systems at stake.
> 
> Those systems aren't yours or any other gentoo devs responsibility. I think if 
> most gentoo users/admins would really really think about it they know the 
> risks they took when they started using gentoo. It's bleeding edge using 
> ACCEPT_KEYWORDS or not. I understand, and if every gentoo user would really 
> be honest with themselves, that my system could go POOF on the next world 
> update. I know mine has a few times in the earlier days of gentoo. That's 
> life on the bleeding edge.

I believe Jon was talking more about the security side of the house.  Each
developer we give CVS access to is one more developer that can commit a
trojaned ebuild or do something else nasty.  Thus, we try to be somewhat
careful about handing the keys to the kingdom over to new folks.

--kurt

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

Re: [gentoo-dev] creating ebuilds

[Caleb Tennis]

On Tuesday 06 January 2004 04:54 am, Kurt Lieber wrote:
> I could see benefits to having a dedicated person, who was extremley
> knowledgeable in the ins/outs of ebuild creation who did nothing else
> except scan bugs.gentoo.org for new ebuilds and put them into the tree.
> Whether there's a person out there with the right skill set willing to do
> such a job is another question entirely.  (not saying there isn't, btw)

This is a bad idea, IMHO.  I used to think more in favor of it, but if someone 
really wants an ebuild that isn't in portage they can very easily search 
bugzilla, download the ebuild, and put it in their overlay.

What would be more beneficial is if there was a repository where unaccepted 
ebuilds go after a period of time 
(http://www.gentoo.org/proj/en/glep/glep-0017.html).  That way, people who 
want to use those ebuilds can download them from there.

--
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] creating ebuilds

[Allen Parker]

> On Tuesday 06 January 2004 04:54 am, Kurt Lieber wrote:
> > I could see benefits to having a dedicated person, who was extremley
> > knowledgeable in the ins/outs of ebuild creation who did nothing else
> > except scan bugs.gentoo.org for new ebuilds and put them into the tree.
> > Whether there's a person out there with the right skill set willing to
> do
> > such a job is another question entirely.  (not saying there isn't, btw)
> 
> This is a bad idea, IMHO.  I used to think more in favor of it, but if
> someone
> really wants an ebuild that isn't in portage they can very easily search
> bugzilla, download the ebuild, and put it in their overlay.
> 
> What would be more beneficial is if there was a repository where
> unaccepted
> ebuilds go after a period of time
> (http://www.gentoo.org/proj/en/glep/glep-0017.html).  That way, people who
> want to use those ebuilds can download them from there.

I think I should definitely re-state my *ideal* system for ebuild
submission, since it wasn't understood. Bugzilla is great, I agree, but it's
for *bugs* and as was said earlier, if a dev isn't interested in an ebuild,
it's not going into the tree. Here's the process that I suggest, and I think
it'll streamline things and reduce the workload on ebuild submission. Avenj,
this does NOT require people like me to have CVS access.

1. New submission is created, submitted to system
2. System sees new ebuild, notifies submitter, dev that has notified system
that they have free time, and possibly herd maintainer for ebuild's proposed
home (opt-in via web interface).
3. Dev checks in, sees ebuild, downloads ebuild, attempts build. Here,
things split:
** Assuming everything is perfect
a. Ebuild works fine, no patches need to be applied/software is now known
stable.
b. User response is requested, users vote yay or nay on whether the package
compiles for them without error.
c. Dev ok's and ~ARCH's ebuild, system picks that up and spits it into
/usr/portage/ebuild-submits/ (which can be specifically defined as a
PORTDIR_OVERLAY, and is undefined as per default)
d. User is happy, dev doesn't have to spend too much time messing with
things, and when they get time to check the package out more thoroughly, it
can be "moved" to the main tree via the interface.
** Possible "gotchas" for submitter:
A. System does a basic syntax check and rejects Ebuild due to syntax errors.
B. Ebuild is ok'd by system for syntax, but when ebuild is attempted in a
sandbox, by dev or "trusted" user, fails and is kicked into another area
where the submitter now has to figure out if it's the ebuild or the package.
(Possible chroot'd script for auto-testing via ebuild <package>.ebuild
digest with failures going to submitter, if no failures, ebuild -v
<package>.ebuild package, with errors going to submitter. (queued ebuilding
via a distcc cluster would probably be preferable on this)
C. Human review, information attached to the ebuild is incomplete, automatic
1 week suspension of submitter from system with 5 or more complaints from
their peers or 1 complaint from a dev. If package does not have a listed
"stable" release, ebuild is thrown out via the above conditions.
D. Ratings: The more successful ebuild submissions you've got, the better
chances you have for having your ebuild moved to the main tree quickly.
E. Existing packages are *NOT* acceptable for submission. New packages
only!! If the system finds that there is an existing ebuild for whatever it
is you're attempting to submit, the ebuild will automatically be dropped
(${PN} matching, maybe md5 distfile db scans or more?)

This is just a rough idea of a way to streamline things. If non-gentoo devs
work on this, it shouldn't take too long to see if it'll sink or swim. IMHO,
Bugzilla is a great thing, it just isn't suited very well or even designed
for this task. I think Bugzilla should be for bugs with existing software...
not ebuild submission. With the proper checks, it should be possible to use
a system for ebuilds only that can handle revision-bump requests, new ebuild
submissions, and possibly more, without overloading bugzilla OR the
Gentoo-devs.

At no point would ANY non-dev be allowed direct cvs access (1 week sandbox
before going into ebuild-submits overlay for last-minute checking by devs).
At no point would any non-dev have access to anything that could be
considered a security risk, in fact, with one of the ebuilds I was working
on developing, it would be possible to setup multiple "virtual" build
systems with immutable linking on every file that could be a hazard (which
via cron, the whole build environment could be cleared and reset every 24
hours without a problem) rm -rf /vservers/genbuild && cp -la
/vservers/genskel /vservers/genbuild would take care of it with anything
that could be possibly used to hurt someone else's work chattr +it (to keep
from being trojanned).

That's my 2/100ths of a monetary unit.
Allen Parker

PS. I hope I cleared some misconceptions up, I wasn't suggesting that
non-devs be allowed cvs access, only that a system would be put into place
that would automate things, because I know for a fact that the ebuild
submission process as it stands isn't really a process, it's an abomination.

(if you'd like an idea how I figured this out, I was thinking of making
vserver-sources, vserver and util-vserver ebuilds... months later, I have
nothing solid, and I don't have the time to chase people around to get an
ebuild in the tree... and it doesn't seem right.)




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Spider]

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

begin  quote
On Tue, 6 Jan 2004 09:13:30 -0500
"Allen Parker" <allenp@efn.org> wrote:



> 
> I think I should definitely re-state my *ideal* system for ebuild
> submission, since it wasn't understood. Bugzilla is great, I agree,
> but it's for *bugs* and as was said earlier, if a dev isn't interested
> in an ebuild, it's not going into the tree. Here's the process that I
> suggest, and I think it'll streamline things and reduce the workload
> on ebuild submission. Avenj, this does NOT require people like me to
> have CVS access.

Actually, before this the build should go through several other stages:
 
> 1. New submission is created, submitted to system


1b)  automated repocheck (compare repoman lintool) 

> 2. System sees new ebuild, notifies submitter, dev that has notified
> system that they have free time, and possibly herd maintainer for
> ebuild's proposed home (opt-in via web interface).
> 3. Dev checks in, sees ebuild, downloads ebuild, attempts build. Here,
> things split:

3b) QC,  by developer of the strictest sense. A lot of people failto
grasp even the most basic concepts of  ebuild programming and / or the
case of boolean logic. ( if foo then bar ; then baz.....  or was that or
baz?  or ... or.... if foo then bar... then we ignore the case of not
foo?  )



> ** Assuming everything is perfect
> a. Ebuild works fine, no patches need to be applied/software is now
> known stable.

No. its not, we have yet no conclusion as to wether the build is
complete or not. Does it build all documentation? are the files really
with that license?   are the dependencies correct according to
configure.*  or did it just happen to work on a fully installed system? 

Is all functionality accounted for in the dependencies, or will it build
without, say X, but with reduced functionality?  None of this is checked
for, and almost none of them are accountable by automagic.


> b. User response is requested, users vote yay or nay on whether the
> package compiles for them without error.

compare the old "stable.gentoo.org" which was a great idea, but lacked
in ease of use and functionality.

<SNIP>



These checks also fail to scan for upstream behaviour. how does upsteam
deal with versions? do they silently fuck up binary releases in the past
or not, is it actively supported?  how long has the package been alive?
(no, just releasing 0.03 to the public last month doesn't mean its alive
and well)


> This is just a rough idea of a way to streamline things. If non-gentoo
> devs work on this, it shouldn't take too long to see if it'll sink or
> swim. IMHO, Bugzilla is a great thing, it just isn't suited very well
> or even designed for this task. I think Bugzilla should be for bugs
> with existing software... not ebuild submission. With the proper
> checks, it should be possible to use a system for ebuilds only that
> can handle revision-bump requests, new ebuild submissions, and
> possibly more, without overloading bugzilla OR the Gentoo-devs.




The idea is sorta-good, I'm not too sure it will be feasible in a larger
scale, but one could hope it is.  And definitely, it'd be a good idea to
separate this from bugzilla.

However, this procedure still means that a developer -HAS- to take
responsibility for a package before it goes into the tree, Which is
something a lot of people whine at just now , becuase their favourite
javawrapper for a string() class didn't go into the tree when everyone
should use it,  or because noone (almost) have a  ps2 devkit to try
foo-app....  (Examples , dont take it too badly)

The policy is, all packages in the tree -needs- a developer contact, if
that person is a relay to somone else, or deals with it himself isn't
much of an issue, but if he's a relay to somone who isn't there (oh, got
bored and went to hack on lfs instead)  he still has to deal with it.
Wether dealing in this case means removing the package and deprecating
it, or actively taking over the upstream abandoned source in a futile
attempt to make it build against the new gcc+glibc combo of the week, is
another issue.


Conclusion : please, write a GLEP. i want to see this discussed more,
but in a whole new thread.



//Spider



-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 1:09 pm, Spider wrote:
> 3b) QC,  by developer of the strictest sense. A lot of people failto
> grasp even the most basic concepts of  ebuild programming and / or the
> case of boolean logic. ( if foo then bar ; then baz.....  or was that or
> baz?  or ... or.... if foo then bar... then we ignore the case of not
> foo?  )
>
> > ** Assuming everything is perfect
> > a. Ebuild works fine, no patches need to be applied/software is now
> > known stable.
>
> No. its not, we have yet no conclusion as to wether the build is
> complete or not. Does it build all documentation? are the files really
> with that license?   are the dependencies correct according to
> configure.*  or did it just happen to work on a fully installed system?
>
> Is all functionality accounted for in the dependencies, or will it build
> without, say X, but with reduced functionality?  None of this is checked
> for, and almost none of them are accountable by automagic.

I guess I think a little differently in that my response to the above is: You 
mean ebuild creators don't already do this? 

I don't say that to be funny, honest. I just can't seeing letting ANYONE even 
see an ebuild I create without having done all those checks in the first 
place! Then after that I would give it to my sponsor to give a brutal 
evaluation of it and then and only then after further changes and testing 
would I ask it to be included in the tree.

I don't know maybe I'm wierd or something it just comes from my early 
programming instructors in the mid 80s, document, document, document, test, 
test, test and then test some more.

> Conclusion : please, write a GLEP. i want to see this discussed more,
> but in a whole new thread.

Agree this thread is dead.

I feel I got a much better understanding of the whole gentoo dev process and I 
feel it was pretty good and most of it was useful back and forth. Overall a 
decent thread I think. Lets all just try to relax now. :) Let's go back to 
playing nice in the sandbox :)

BTW, Happy new year! 

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 19:24, Robert Cole wrote:
> On Tue January 06 2004 1:09 pm, Spider wrote:
> > 3b) QC,  by developer of the strictest sense. A lot of people failto
> > grasp even the most basic concepts of  ebuild programming and / or the
> > case of boolean logic. ( if foo then bar ; then baz.....  or was that or
> > baz?  or ... or.... if foo then bar... then we ignore the case of not
> > foo?  )
> >
> > > ** Assuming everything is perfect
> > > a. Ebuild works fine, no patches need to be applied/software is now
> > > known stable.
> >
> > No. its not, we have yet no conclusion as to wether the build is
> > complete or not. Does it build all documentation? are the files really
> > with that license?   are the dependencies correct according to
> > configure.*  or did it just happen to work on a fully installed system?
> >
> > Is all functionality accounted for in the dependencies, or will it build
> > without, say X, but with reduced functionality?  None of this is checked
> > for, and almost none of them are accountable by automagic.
> 
> I guess I think a little differently in that my response to the above is: You 
> mean ebuild creators don't already do this? 

The Gentoo developers do, but many submitted ebuilds do not.  Especially
on breakmygentoo, which is why many of us remain adamant about not
putting links to them on the official Gentoo site.

> I don't say that to be funny, honest. I just can't seeing letting ANYONE even 
> see an ebuild I create without having done all those checks in the first 
> place! Then after that I would give it to my sponsor to give a brutal 
> evaluation of it and then and only then after further changes and testing 
> would I ask it to be included in the tree.
> 
> I don't know maybe I'm wierd or something it just comes from my early 
> programming instructors in the mid 80s, document, document, document, test, 
> test, test and then test some more.
> 
> > Conclusion : please, write a GLEP. i want to see this discussed more,
> > but in a whole new thread.
> 
> Agree this thread is dead.
> 
> I feel I got a much better understanding of the whole gentoo dev process and I 
> feel it was pretty good and most of it was useful back and forth. Overall a 
> decent thread I think. Lets all just try to relax now. :) Let's go back to 
> playing nice in the sandbox :)
> 
> BTW, Happy new year! 
> 
> Robert
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 1:54 am, Kurt Lieber wrote:
> On Tue, Jan 06, 2004 at 12:39:29AM -0800 or thereabouts, Robert Cole wrote:
> > I like it. That's a very good process. I'm talking about ebuilds here.
> > I'll be honest and say I don't know how the backend of the portage tree
> > works with security and all but maybe another tier would be in order if
> > possible. Like a low access new ebuild access that gets queued and not
> > actually put in the tree and someone with access could simply flag it to
> > move into the tree or reject it sending an email back to the creator of
> > the ebuild why.
>
> You've just described bugs.gentoo.org.

How easy is it for a person with access to approve an ebuild? Do they just 
click a button and it moves out of the "queue" and into the tree? If the 
person with access has to do allot then no wonder packages sit for a year.

> Granted, plenty of ebuilds sit in there and never make it into the tree.
> This is not the fault of bugzilla, however.  It is more a problem with our
> process.  Ebuilds make it into the tree when a developer cares about them.
> If no developer cares about them, they tend not to make it into the tree.
> For right or wrong, that's how things work today.

It appears you and Chris both missed the fact I'm not talking about someone 
not available to maintain. I'm talking about someone that is willing to and 
WANTS to maintain the package. 

It sounds like you need a better buffer between new devs and cvs. Like a said 
something queue like that the cvs dev can just click to approve and it all 
happens automagically.

> I believe Jon was talking more about the security side of the house.  Each
> developer we give CVS access to is one more developer that can commit a
> trojaned ebuild or do something else nasty.  Thus, we try to be somewhat
> careful about handing the keys to the kingdom over to new folks.

Don't you think it would ease the minds of many if there was a wait to have 
limited access to a cvs queue instead of the real thing? A place where a cvs 
dev can look at a list of packages and click either approve or not and the 
approved ones move at that point? Is that really the way bugs.gentoo.org 
works now?

In my day job I'm a network and security engineer so I know the headaches of 
having too many people with full access to a switch, router, server or 
anything else. The fewer with that sort of access the better. If you had one 
dev for every package in the tree and they all had cvs access how much of a 
problem would that be? GIANT! That would just be a mess. A horrible mess but 
it sounds like that's what gentoo is heading for if all devs go through the 
process and prove themselves you could end up with that mess and the 
possibility of someone fatfingering something and hosing things up.

I'll look at cvs closer because I have a hard time believing that something 
that's been around so long and so mature has only an all or nothing security 
setup.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 10:18, Robert Cole wrote:
> On Tue January 06 2004 1:54 am, Kurt Lieber wrote:
> > On Tue, Jan 06, 2004 at 12:39:29AM -0800 or thereabouts, Robert Cole wrote:
> > > I like it. That's a very good process. I'm talking about ebuilds here.
> > > I'll be honest and say I don't know how the backend of the portage tree
> > > works with security and all but maybe another tier would be in order if
> > > possible. Like a low access new ebuild access that gets queued and not
> > > actually put in the tree and someone with access could simply flag it to
> > > move into the tree or reject it sending an email back to the creator of
> > > the ebuild why.
> >
> > You've just described bugs.gentoo.org.
> 
> How easy is it for a person with access to approve an ebuild? Do they just 
> click a button and it moves out of the "queue" and into the tree? If the 
> person with access has to do allot then no wonder packages sit for a year.

Well, NOTHING would get added without testing, so there's no need for
any form of "button" to "approve" anything.

> > Granted, plenty of ebuilds sit in there and never make it into the tree.
> > This is not the fault of bugzilla, however.  It is more a problem with our
> > process.  Ebuilds make it into the tree when a developer cares about them.
> > If no developer cares about them, they tend not to make it into the tree.
> > For right or wrong, that's how things work today.
> 
> It appears you and Chris both missed the fact I'm not talking about someone 
> not available to maintain. I'm talking about someone that is willing to and 
> WANTS to maintain the package. 

Someone who is NOT a developer, and therefore not held liable.  If I add
a package to the portage tree, I HAVE to maintina it.  That is the
current Gentoo policy, and I think a VERY good policy for keeping
poor-quality ebuilds out of the tree.

> It sounds like you need a better buffer between new devs and cvs. Like a said 
> something queue like that the cvs dev can just click to approve and it all 
> happens automagically.

The truth is, I would like to see FEWER packages added, as it seems the
quality of some packages is deteriorating, while others are getting MUCH
better.  Gentoo is working to provide excellent quality control.  We do
not wish to EVER force the user community to do our QC for us, which is
why most of your ideas simply won't work.  Pushing the testing phase
onto the users is a horrible idea, as it makes it EXTREMELY easy for a
user to end up with a very broken system.  We try to provide only
working packages and not things which are of poor quality, as it
reflects on us, as developers.

> > I believe Jon was talking more about the security side of the house.  Each
> > developer we give CVS access to is one more developer that can commit a
> > trojaned ebuild or do something else nasty.  Thus, we try to be somewhat
> > careful about handing the keys to the kingdom over to new folks.
> 
> Don't you think it would ease the minds of many if there was a wait to have 
> limited access to a cvs queue instead of the real thing? A place where a cvs 
> dev can look at a list of packages and click either approve or not and the 
> approved ones move at that point? Is that really the way bugs.gentoo.org 
> works now?

It's somewhat close, at least in many areas.  There have been a few
times where a user has submitted an ebuild for something which I have
added to the tree.  The ebuild is maintained by me, however, and I am
the one responsible when something goes wrong.  This way, I don't add
anything to the tree that I would not feel comfortable running and
maintaining myself.  This provides a nice level of quality, which so far
has worked quite well for Gentoo.  It takes only a couple minutes and a
very few steps to add an ebuild to the tree.  The longest time is spent
making sure the ebuild is correct and that the package works as expected
once it is merged.

> In my day job I'm a network and security engineer so I know the headaches of 
> having too many people with full access to a switch, router, server or 
> anything else. The fewer with that sort of access the better. If you had one 
> dev for every package in the tree and they all had cvs access how much of a 
> problem would that be? GIANT! That would just be a mess. A horrible mess but 
> it sounds like that's what gentoo is heading for if all devs go through the 
> process and prove themselves you could end up with that mess and the 
> possibility of someone fatfingering something and hosing things up.

How is Gentoo heading for one dev per package?  I don't understand
this.  The games herd has only a few members, yet we maintain over 400
ebuilds.  We each proved ourselves to get brought on board as developers
and we each do our part to keep gaming on Gentoo going well.  Not to
mention that if a developer consistently falls on his duties, he will
have his status revoked.

As for fatfingering things, we've all done that before.  Forcing a few
developers to wade through hundreds of ebuild submissions isn't going to
really help that.  Instead, the developers will get lazy and become
quite lenient on what they let through.  After all, these are normal
people with normal lives.  We all volunteer our time to Gentoo and there
are many times when a person becomes lazy or unenthused.

The truth is that no matter what we do, it won't be enough.  There are
just too many users in compared to the number of developers and there
are always going to be new things the community wants added to Gentoo
which will take developer time and energy to implement.  We can only do
so much in our limited time.

> I'll look at cvs closer because I have a hard time believing that something 
> that's been around so long and so mature has only an all or nothing security 
> setup.

Well, cvs does allow a for more fine-grained controls over the tree,
however Gentoo has decided to not use these and rather to rely on trust
to keep things in order.  This way a developer is not prohibited from
contributing in an area for which he is not an "official" part.  For
example, if we were to implement strong access controls, I would be
allowed to access the games-* parts of the tree.  However, I also
maintain a few packages under net-misc.  If I were to add a new package,
I would have to request access for that area, which is a serious
bottleneck when you're looking at hundreds of developers each needing
access to different areas.

The way Gentoo looks at it is simply that if we can't trust you with the
whole tree, why should we trust you with any of it?

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 8:04 am, Chris Gianelloni wrote:
> Someone who is NOT a developer, and therefore not held liable.  If I add
> a package to the portage tree, I HAVE to maintina it.  That is the
> current Gentoo policy, and I think a VERY good policy for keeping
> poor-quality ebuilds out of the tree.

I personally believe this type of management has it's days numbered as gentoo 
grows. 

> > It sounds like you need a better buffer between new devs and cvs. Like a
> > said something queue like that the cvs dev can just click to approve and
> > it all happens automagically.
>
> The truth is, I would like to see FEWER packages added, as it seems the
> quality of some packages is deteriorating, while others are getting MUCH
> better.  Gentoo is working to provide excellent quality control.  We do
> not wish to EVER force the user community to do our QC for us, which is
> why most of your ideas simply won't work.  Pushing the testing phase
> onto the users is a horrible idea, as it makes it EXTREMELY easy for a
> user to end up with a very broken system.  We try to provide only
> working packages and not things which are of poor quality, as it
> reflects on us, as developers.

Are we talking about the same distro here? This is gentoo I'm talking about. 
We all do qc in some form or another whether we report the issue or not is a 
different story.

Gentoo is an advanced distro. It's always been easy to end up with a broken 
system. Are you trying to make gentoo into another lindows or something? 

I will say that qc from the devs has evolved to limit the broken systems that 
use to happen more but we would have never gotten to this point without 
breaking a system or 100 now and again. I not saying we should continue 
breaking systems I'm just saying it's not unexpected to get a broken package 
or two now and again even from experienced and trusted devs. Mistakes can 
happen and anyone who uses gentoo should not have a problem with that.

> Well, cvs does allow a for more fine-grained controls over the tree,
> however Gentoo has decided to not use these and rather to rely on trust
> to keep things in order.  This way a developer is not prohibited from
> contributing in an area for which he is not an "official" part.  For
> example, if we were to implement strong access controls, I would be
> allowed to access the games-* parts of the tree.  However, I also
> maintain a few packages under net-misc.  If I were to add a new package,
> I would have to request access for that area, which is a serious
> bottleneck when you're looking at hundreds of developers each needing
> access to different areas.

That's exactly the way it works. Now from an administration standpoint you 
should limit the number of exceptions that happen. I mean you having access 
to games and misc is ok that way but if you were to maintain packages across 
a dozen area then you should just have complete access.

> The way Gentoo looks at it is simply that if we can't trust you with the
> whole tree, why should we trust you with any of it?

It's not so much a matter of trust as it is a good security practice. I have 
root access to my linux systems but does that mean I just run as root all the 
time?

If I take your example here I should and everyone should just run as the root 
user on a linux/unix system. Why don't we? Because it's a security risk and 
poor security practice. Same with doing an all or nothing cvs access it's 
just lazy and there is no other way to put it except just plain lazy security 
practices.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Ciaran McCreesh]

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

On Tue, 6 Jan 2004 08:31:21 -0800 Robert Cole
<robert.cole@support4linux.com> wrote:
| Are we talking about the same distro here? This is gentoo I'm talking
| about. We all do qc in some form or another whether we report the
| issue or not is a different story.

If you want broken cowboy code, why not play with breakmygentoo instead?

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 8:45 am, Ciaran McCreesh wrote:
> On Tue, 6 Jan 2004 08:31:21 -0800 Robert Cole
>
> <robert.cole@support4linux.com> wrote:
> | Are we talking about the same distro here? This is gentoo I'm talking
> | about. We all do qc in some form or another whether we report the
> | issue or not is a different story.
>
> If you want broken cowboy code, why not play with breakmygentoo instead?

I break gentoo all the time but that is because I tinker with stuff until it 
breaks as a way to learn about it. I've been installing, breaking, and 
reinstalling gentoo for about 2 years now and it's been the best linux 
learning experience I've ever had and I teach linux classes on the side :)

I've used over 20 distros over the past 6 or 7 years now but I've never 
learned more about linux than I have with gentoo and for that I'm grateful 
and why I am going to contribute more than I have in the past.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 11:31, Robert Cole wrote:
> On Tue January 06 2004 8:04 am, Chris Gianelloni wrote:
> > Someone who is NOT a developer, and therefore not held liable.  If I add
> > a package to the portage tree, I HAVE to maintina it.  That is the
> > current Gentoo policy, and I think a VERY good policy for keeping
> > poor-quality ebuilds out of the tree.
> 
> I personally believe this type of management has it's days numbered as gentoo 
> grows. 

I respect your opinion, but as far as I can see, Gentoo is sticking with
the idea that having packages which do not have at least one developer
willing to maintain it is a bad idea.

> > > It sounds like you need a better buffer between new devs and cvs. Like a
> > > said something queue like that the cvs dev can just click to approve and
> > > it all happens automagically.
> >
> > The truth is, I would like to see FEWER packages added, as it seems the
> > quality of some packages is deteriorating, while others are getting MUCH
> > better.  Gentoo is working to provide excellent quality control.  We do
> > not wish to EVER force the user community to do our QC for us, which is
> > why most of your ideas simply won't work.  Pushing the testing phase
> > onto the users is a horrible idea, as it makes it EXTREMELY easy for a
> > user to end up with a very broken system.  We try to provide only
> > working packages and not things which are of poor quality, as it
> > reflects on us, as developers.
> 
> Are we talking about the same distro here? This is gentoo I'm talking about. 
> We all do qc in some form or another whether we report the issue or not is a 
> different story.

No.  You do bug reporting when you find something wrong.  Quality
Control is something that is done before a product is shipped to make
sure it isn't broken.

> Gentoo is an advanced distro. It's always been easy to end up with a broken 
> system. Are you trying to make gentoo into another lindows or something? 

I'm just going to leave this alone since it is obvious that you're
flame-baiting.

> I will say that qc from the devs has evolved to limit the broken systems that 
> use to happen more but we would have never gotten to this point without 
> breaking a system or 100 now and again. I not saying we should continue 
> breaking systems I'm just saying it's not unexpected to get a broken package 
> or two now and again even from experienced and trusted devs. Mistakes can 
> happen and anyone who uses gentoo should not have a problem with that.

Yes, the quality of developer commits has increased because we have been
making a conscious effort to do so.  A broken package or two every now
and then is not usually detrimental as the chaos that would ensue with
having a system as you propose where quantity and speed take precedence
over quality.

> > Well, cvs does allow a for more fine-grained controls over the tree,
> > however Gentoo has decided to not use these and rather to rely on trust
> > to keep things in order.  This way a developer is not prohibited from
> > contributing in an area for which he is not an "official" part.  For
> > example, if we were to implement strong access controls, I would be
> > allowed to access the games-* parts of the tree.  However, I also
> > maintain a few packages under net-misc.  If I were to add a new package,
> > I would have to request access for that area, which is a serious
> > bottleneck when you're looking at hundreds of developers each needing
> > access to different areas.
> 
> That's exactly the way it works. Now from an administration standpoint you 
> should limit the number of exceptions that happen. I mean you having access 
> to games and misc is ok that way but if you were to maintain packages across 
> a dozen area then you should just have complete access.

This is something that we will eventually face, but for now we prefer
the idea of allowing developers to expand their horizons and contribute
anywhere they see fit.  There are some limitations on certain areas
which are considered to be more critical, but in general everyone has
access to the entire tree.

> > The way Gentoo looks at it is simply that if we can't trust you with the
> > whole tree, why should we trust you with any of it?
> 
> It's not so much a matter of trust as it is a good security practice. I have 
> root access to my linux systems but does that mean I just run as root all the 
> time?

You're just putting words into my mouth here.  We're speaking of trust
and professionalism.  AT work, do you have access to other people's
email?  I'm sure you do, since you say that you are an administrator,
but does that mean you go reading other people's mails?

I'm willing to bet that you don't.  It is pretty much the same thing. 
There is nothing actually stopping you from doing it, other than
possible repercussions and your own integrity.

> If I take your example here I should and everyone should just run as the root 
> user on a linux/unix system. Why don't we? Because it's a security risk and 
> poor security practice. Same with doing an all or nothing cvs access it's 
> just lazy and there is no other way to put it except just plain lazy security 
> practices.

You're speaking out of both sides of your mouth.  On one side you want
to make adding ebuilds quicker, and on the other, you want us to
implement measures to slow developer's abilities to work.  Which is it?

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 11:17 am, Chris Gianelloni wrote:
> On Tue, 2004-01-06 at 11:31, Robert Cole wrote:
> > On Tue January 06 2004 8:04 am, Chris Gianelloni wrote:
> > > Someone who is NOT a developer, and therefore not held liable.  If I
> > > add a package to the portage tree, I HAVE to maintina it.  That is the
> > > current Gentoo policy, and I think a VERY good policy for keeping
> > > poor-quality ebuilds out of the tree.
> >
> > I personally believe this type of management has it's days numbered as
> > gentoo grows.
>
> I respect your opinion, but as far as I can see, Gentoo is sticking with
> the idea that having packages which do not have at least one developer
> willing to maintain it is a bad idea.

Did I ever say not to have a maintainer? If I did I'm sorry I led you in this 
direction. I guess what I'm suggesting is separating dev access and ebuild 
contributer access. Ebuild contributer are a class of dev yes but a class in 
their own I believe with limited rights to the tree. 

Creating this class would give you more maintainers with less overhead for the 
cvs-dev class.

> > Are we talking about the same distro here? This is gentoo I'm talking
> > about. We all do qc in some form or another whether we report the issue
> > or not is a different story.
>
> No.  You do bug reporting when you find something wrong.  Quality
> Control is something that is done before a product is shipped to make
> sure it isn't broken.

That's what ACCEPT_KEYWORDS can be for. Is from what I can tell.

> > Gentoo is an advanced distro. It's always been easy to end up with a
> > broken system. Are you trying to make gentoo into another lindows or
> > something?
>
> I'm just going to leave this alone since it is obvious that you're
> flame-baiting.

No not really. Didn't mean it as that but as you mentioned further down you 
can't have it both ways. You can't be an advanced distro using 
curring/bleeding edge stuff AND be a rock solid distro. It's just not going 
to happen. Well not automatically that is. You can have an extremely stable 
gentoo system that pretty darn cutting edge but it takes some effort in 
working with masking and make.conf. I do it all the time. It just seems you 
want things rock solid stable out the door with gentoo and automatic. That's 
not happening at least not now. You can get close without ACCEPT_KEYWORDS 
though.

> > I will say that qc from the devs has evolved to limit the broken systems
> > that use to happen more but we would have never gotten to this point
> > without breaking a system or 100 now and again. I not saying we should
> > continue breaking systems I'm just saying it's not unexpected to get a
> > broken package or two now and again even from experienced and trusted
> > devs. Mistakes can happen and anyone who uses gentoo should not have a
> > problem with that.
>
> Yes, the quality of developer commits has increased because we have been
> making a conscious effort to do so.  A broken package or two every now
> and then is not usually detrimental as the chaos that would ensue with
> having a system as you propose where quantity and speed take precedence
> over quality.

And the addition of ACCEPT_KEYWORDS helped as well but it's meaning and use 
seems to be fading away.

> This is something that we will eventually face, but for now we prefer
> the idea of allowing developers to expand their horizons and contribute
> anywhere they see fit.  There are some limitations on certain areas
> which are considered to be more critical, but in general everyone has
> access to the entire tree.

And you feel with those controls a dev will be restricted? I don't think so it 
would just be an extra layer they would have to go through or ask to be setup 
perm with the access to the new area. They would have to think before acting.

> > > The way Gentoo looks at it is simply that if we can't trust you with
> > > the whole tree, why should we trust you with any of it?
> >
> > It's not so much a matter of trust as it is a good security practice. I
> > have root access to my linux systems but does that mean I just run as
> > root all the time?
>
> You're just putting words into my mouth here.  We're speaking of trust
> and professionalism.  AT work, do you have access to other people's

I can't do that, no one can. I'm restating what I think you are saying but a 
different way to make sure I understand it. The root analogy is actually so 
close and a perfect fit here.

> email?  I'm sure you do, since you say that you are an administrator,
> but does that mean you go reading other people's mails?

That depends on the system  but I get your point. With my everyday access no I 
can't. When I login with an admin account then I could if the system is 
insecure like Exchange but can't no matter what if it's something more mature 
like groupwise.

> > If I take your example here I should and everyone should just run as the
> > root user on a linux/unix system. Why don't we? Because it's a security
> > risk and poor security practice. Same with doing an all or nothing cvs
> > access it's just lazy and there is no other way to put it except just
> > plain lazy security practices.
>
> You're speaking out of both sides of your mouth.  On one side you want
> to make adding ebuilds quicker, and on the other, you want us to
> implement measures to slow developer's abilities to work.  Which is it?

I would like to see fine grain controls and a different group of devs like 
cvs-dev and ebuild-dev with different access controls.

cvs-dev (root cvs access)
cvs-dev-games (games area access)
cvs-dev-misc (misc access)

cvs user cgianelloni a part of cvs-dev-games and cvs-dev-misc just as an 
example. Again you can only take this as far as administration organization 
will allow. It can get out of hand too fast if your hard of a dozen area. In 
that case just full access for simplicity.

Then start with ebuild devs

ebuild-dev, etc, etc

The difference with them is I would want owner level control assigned so that 
yes you can give them ebuild-dev-games but they only have access to the 
ebuilds in that area that they've contributed.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Ciaran McCreesh]

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

On Tue, 6 Jan 2004 11:43:33 -0800 Robert Cole
<robert.cole@support4linux.com> wrote:
| I would like to see fine grain controls and a different group of devs
| like cvs-dev and ebuild-dev with different access controls.

Uh, how silly. Either you trust someone with the whole tree or you don't
trust them at all.

-- 
Ciaran McCreesh
Mail:    ciaranm at gentoo.org
Web:     http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] creating ebuilds

[John Nilsson]

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

> Uh, how silly. Either you trust someone with the whole tree or you don't
> trust them at all.

Why not build something around a "web of trust" with pgp signatures? Have an  
open tree where people could submit anything that passed autotests. All  
submisions would be signed. Signed content could only get updated buy user  
with same signature or dev with higher trust for that area.

The choice of trust-level is then up to the sys-admin.

This idea is a bit rough, but I think it could be intresting to build on.

/John

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

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

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

On Thursday 08 January 2004 08:12, John Nilsson wrote:
> > Uh, how silly. Either you trust someone with the whole tree or you
> > don't trust them at all.
>
> Why not build something around a "web of trust" with pgp signatures?
> Have an open tree where people could submit anything that passed
> autotests. All submisions would be signed. Signed content could only
> get updated buy user with same signature or dev with higher trust for
> that area.

This does not help at all for initial submissions. It allows anyone who 
knows how to create a pgp key to get something in the tree. However if 
you make some nuances to this idea, I think it could be workable.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE//SlbbKx5DBjWFdsRAmd/AKCrUJtoK0rAh45WfNOBuQQrGjYwhQCgyXnp
8dvq60N2noGeWGygqoG9Rk0=
=sVYb
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[John Nilsson]

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

On 01/08/04 10:56:43, Paul de Vrieze wrote:
> On Thursday 08 January 2004 08:12, John Nilsson wrote:
> > > Uh, how silly. Either you trust someone with the whole tree or you
> > > don't trust them at all.
> >
> > Why not build something around a "web of trust" with pgp signatures?
> > Have an open tree where people could submit anything that passed
> > autotests. All submisions would be signed. Signed content could only
> > get updated buy user with same signature or dev with higher trust for
> > that area.
> 
> This does not help at all for initial submissions. It allows anyone who
> knows how to create a pgp key to get something in the tree. However if
> you make some nuances to this idea, I think it could be workable.

This was kind of the idea... In the future I would like a system where any  
developer can publish their project as an ebuild, just as one would put an rpm  
or install script on the web to day.

Point beeing thar some submissions would be screened by core devs and signed  
by them. Some trusted signs would be signed by core devs. When the  
infrastructure is up the decision to trust an ebuild is entirely up to the  
sys-admin: latest and greatest with a serious secutity risk or only ebuilds  
trusted by core devs.

I also see the portage tree evolving from a big hunk of files mirrored all  
over the place, into a web in its on right.

/John

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

Re: [gentoo-dev] creating ebuilds

[Nicholas Hockey]

[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]

not really, because they would have to exist in the web of trust and be
signed by a gentoo developer, a developer could approve the project, and
it could be proxied through them until the developer felt they were
capable, then they sign there gpg/pgp key, allowing them to bypass the
developer who was being the proxy. i think this is a wonderful idea.

On Thu, 2004-01-08 at 04:56, Paul de Vrieze wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thursday 08 January 2004 08:12, John Nilsson wrote:
> > > Uh, how silly. Either you trust someone with the whole tree or you
> > > don't trust them at all.
> >
> > Why not build something around a "web of trust" with pgp signatures?
> > Have an open tree where people could submit anything that passed
> > autotests. All submisions would be signed. Signed content could only
> > get updated buy user with same signature or dev with higher trust for
> > that area.
> 
> This does not help at all for initial submissions. It allows anyone who 
> knows how to create a pgp key to get something in the tree. However if 
> you make some nuances to this idea, I think it could be workable.
> 
> Paul
> 
> - -- 
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@gentoo.org
> Homepage: http://www.devrieze.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQE//SlbbKx5DBjWFdsRAmd/AKCrUJtoK0rAh45WfNOBuQQrGjYwhQCgyXnp
> 8dvq60N2noGeWGygqoG9Rk0=
> =sVYb
> -----END PGP SIGNATURE-----
> 
> 
> --
> gentoo-dev@gentoo.org mailing list

-------------- 
Nicholas Hockey (tilt@bluecherry.net) Encrypted E-Mail preferred

[-- Attachment #1.2: Type: text/html, Size: 2120 bytes --]

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

Re: [gentoo-dev] creating ebuilds

[foser]

On Tue, 2004-01-06 at 20:43, Robert Cole wrote:
> On Tue January 06 2004 11:17 am, Chris Gianelloni wrote:
> > On Tue, 2004-01-06 at 11:31, Robert Cole wrote:
> > > On Tue January 06 2004 8:04 am, Chris Gianelloni wrote:
> > > > Someone who is NOT a developer, and therefore not held liable.  If I
> > > > add a package to the portage tree, I HAVE to maintina it.  That is the
> > > > current Gentoo policy, and I think a VERY good policy for keeping
> > > > poor-quality ebuilds out of the tree.
> > >
> > > I personally believe this type of management has it's days numbered as
> > > gentoo grows.
> >
> > I respect your opinion, but as far as I can see, Gentoo is sticking with
> > the idea that having packages which do not have at least one developer
> > willing to maintain it is a bad idea.
> 
> Did I ever say not to have a maintainer? If I did I'm sorry I led you in this 
> direction. I guess what I'm suggesting is separating dev access and ebuild 
> contributer access. Ebuild contributer are a class of dev yes but a class in 
> their own I believe with limited rights to the tree. 

> Creating this class would give you more maintainers with less overhead for the 
> cvs-dev class.

Adding user submitted ebuilds without proper maintainership has led to a
lot of problems which we are currently slowly trying to resolve by the
whole herds concept. We try to learn from mistakes in the past here, not
doing it all over again.

Submitting is much cooler than maintaining i can tell you and your
suggestion has no actual maintainership suggestions (although it implies
otherwise at the start), so i can't take it very seriously. As someone
else said, the ones submitting ebuilds are not always the one wanting to
maintain them for as long as it takes. And what i can get from it,
cvs-devs should do the maintaining ? Those are the ones that have enough
to do as it is.

> > No.  You do bug reporting when you find something wrong.  Quality
> > Control is something that is done before a product is shipped to make
> > sure it isn't broken.
> 
> That's what ACCEPT_KEYWORDS can be for. Is from what I can tell.

You tell wrong, ACCEPT_KEYWORDS certainly isn't suited for the large
scale usage you are suggesting and is interpreted the wrong way a lot of
times as it is.

> No not really. Didn't mean it as that but as you mentioned further down you 
> can't have it both ways. You can't be an advanced distro using 
> curring/bleeding edge stuff AND be a rock solid distro. It's just not going 
> to happen. Well not automatically that is. You can have an extremely stable 
> gentoo system that pretty darn cutting edge but it takes some effort in 
> working with masking and make.conf. I do it all the time. It just seems you 
> want things rock solid stable out the door with gentoo and automatic. That's 
> not happening at least not now. You can get close without ACCEPT_KEYWORDS 
> though.

Actually Gentoo always promotes itself as a meta-distro, so we can be
everything, it just depends on how you want it. We can be both rock
stable and cutting-stable-edge, it just depends on the user.

> And the addition of ACCEPT_KEYWORDS helped as well but it's meaning and use 
> seems to be fading away.

And this is based on what evidence ?

> And you feel with those controls a dev will be restricted? I don't think so it 
> would just be an extra layer they would have to go through or ask to be setup 
> perm with the access to the new area. They would have to think before acting.

That is a non-argument, devs should think before taking action at all
times. Restricting access won't help there. The only reason for
different access levels i can see is security concerns, but i actually
like it open as it is and the inter-dev trust that it implies.

> > You're speaking out of both sides of your mouth.  On one side you want
> > to make adding ebuilds quicker, and on the other, you want us to
> > implement measures to slow developer's abilities to work.  Which is it?
> 
> I would like to see fine grain controls and a different group of devs like 
> cvs-dev and ebuild-dev with different access controls.
> 
> cvs-dev (root cvs access)
> cvs-dev-games (games area access)
> cvs-dev-misc (misc access)
> 
> cvs user cgianelloni a part of cvs-dev-games and cvs-dev-misc just as an 
> example. Again you can only take this as far as administration organization 
> will allow. It can get out of hand too fast if your hard of a dozen area. In 
> that case just full access for simplicity.
> 
> Then start with ebuild devs
> 
> ebuild-dev, etc, etc
> 
> The difference with them is I would want owner level control assigned so that 
> yes you can give them ebuild-dev-games but they only have access to the 
> ebuilds in that area that they've contributed.

So it's pretty much the latter to conclude. As said, i don't think
restrictions are the way to go. What would be the defining difference
between 'cvs-devs' and 'ebuild-devs' anyway ? It looks like it's only a
restriction thing. I don't see what it adds besides a lot of
administratory cruft and low quality ebuilds.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Chris Gianelloni]

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

On Tue, 2004-01-06 at 03:39, Robert Cole wrote:
> On Mon January 05 2004 11:55 pm, Jon Portnoy wrote:
> > Okay, let me explain a little bit about how the recruitment process
> > works.
> 
> I like it. That's a very good process. I'm talking about ebuilds here. I'll be 
> honest and say I don't know how the backend of the portage tree works with 
> security and all but maybe another tier would be in order if possible. Like a 
> low access new ebuild access that gets queued and not actually put in the 
> tree and someone with access could simply flag it to move into the tree or 
> reject it sending an email back to the creator of the ebuild why.

That is exactly what is done with Bugzilla.  If ti isn't being done on
certain ebuild submissions, it should be.

> Would simplify getting things in greatly. Then again such a process may 
> already exist I don't know. If it does exist it doesn't "appear" to be in 
> use. I say "appear" because it doesn't look that way to me but I don't see 
> the whole picture. I get the frontend of portage only and I see apps sit for 
> a year or more in bugs.gentoo.org.

Bugs will stay in Bugzilla if no developer wants to maintain the
package.  At the end of the day, if I submit an ebuild that you created,
*I* am responsible for it, not you.  Many developers do not want to take
on the responsibility of maintaining ebuilds that they know little to
nothing about.  I know I surely don't.

> > You would be cautious too if there were an estimated quarter of a
> > million systems at stake.
> 
> Those systems aren't yours or any other gentoo devs responsibility. I think if 
> most gentoo users/admins would really really think about it they know the 
> risks they took when they started using gentoo. It's bleeding edge using 
> ACCEPT_KEYWORDS or not. I understand, and if every gentoo user would really 
> be honest with themselves, that my system could go POOF on the next world 
> update. I know mine has a few times in the earlier days of gentoo. That's 
> life on the bleeding edge.

In a way, they are our responsibility.  People expect a certain level of
quality from our "distribution" and we are here to provide it.  Gentoo
has been much more "beta" or "bleeding-edge" in the past, but we are
maturing, and quality control is a big issue for us right now.  In fact,
I would not be surprised if many developers wouldn't mind if the tree
didn't grow any more right now and just the quality of the entire tree
went up for a while.  This is usually how we work when it comes close to
time for a new release.  We tend to try to stabilize and bug fix rather
than try to add new "testing" packages.  As for ACCEPT_KEYWORDS, Gentoo
does not use ~ARCH as an unstable area.  It is an area for testing
EBUILDS, not for testing packages.  If a package is unstable, it doesn't
belong in our tree.  Period.

> New ebuilds are normally put in the testing area anyhow and if someone has a 
> system they really care about and have ACCEPT_KEYWORDS set and merge that new 
> package and it toasts their system then that's just a bummer ain't it? 
> Seriously who's at fault? Besides I've seen people moan about the loss of 
> their system now again but I don't recall anyone placing blame with the devs 
> but maybe I missed that.

No.  It is a bug that should be fixed by the developer/maintainer.  It
very well COULD be a developer's fault that someone's system went
haywire.  Usually, though, it is simply a combination of items which was
not explicitly tested for and ends up being a bug in either the ebuild
or the package itself.

> > Does any of this mean that people are shut out from contributing? Not at
> > all.
> 
> Good enough for me I'll get to work on a few awesome packages that would make 
> a nice edition to the tree and see what happens dispite many packages that 
> currently sit in bugs.gentoo.org. Maybe they just need a maintainer and 
> tester. I'll start with those. Prolly ACID first. Got a portage bug to report 
> first.

Yes.  You can always add ebuilds to bugzilla.  If you think people will
be interested in them, stir up some support for them in the forums and
have people test your ebuilds.  Look at lots of ebuilds and see how the
"official" developers do things and try to improve the general quality
of your ebuilds.  Try to help out on Bug Day.  Prove yourself as a
valuable asset to Gentoo and the development team will scoop you up
quickly.  It's that simple.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

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

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 4:09 am, Chris Gianelloni wrote:
> On Tue, 2004-01-06 at 03:39, Robert Cole wrote:
> > On Mon January 05 2004 11:55 pm, Jon Portnoy wrote:
> > > Okay, let me explain a little bit about how the recruitment process
> > > works.
> >
> > I like it. That's a very good process. I'm talking about ebuilds here.
> > I'll be honest and say I don't know how the backend of the portage tree
> > works with security and all but maybe another tier would be in order if
> > possible. Like a low access new ebuild access that gets queued and not
> > actually put in the tree and someone with access could simply flag it to
> > move into the tree or reject it sending an email back to the creator of
> > the ebuild why.
>
> That is exactly what is done with Bugzilla.  If ti isn't being done on
> certain ebuild submissions, it should be.

I couldn't agree more with Allen on this. Bugzilla should be for software bugs 
not ebuilds. It obviously sucks for that.

> Bugs will stay in Bugzilla if no developer wants to maintain the
> package.  At the end of the day, if I submit an ebuild that you created,
> *I* am responsible for it, not you.  Many developers do not want to take
> on the responsibility of maintaining ebuilds that they know little to
> nothing about.  I know I surely don't.

Now this is just wrong. A cvs dev shouldn't have to shoulder someone elses 
ebuild when the submitter is willing to maintain it. 

<snip>
> than try to add new "testing" packages.  As for ACCEPT_KEYWORDS, Gentoo
> does not use ~ARCH as an unstable area.  It is an area for testing
> EBUILDS, not for testing packages.  If a package is unstable, it doesn't
> belong in our tree.  Period.

Whoa then I guess you better clear out half the gentoo tree then! Just because 
a new release of a software is put out doesn't mean its stable. Heck look at 
gcc, gnupg, cvs, etc yet because those packages have active maintainers they 
get rev bumped within hours of a new release and some get downgraded quickly.

I run KDE 3.2 beta 2 but it's not 100% stable so you better hurry up and take 
it out of the tree.

See how bogus " If a package is unstable, it doesn't belong in our tree.  
Period." is? Simply not true. Gentoo is a bleeding edge distro and gets all 
the latest releases of anything that has a maintainer beta, pre, or release.

> No.  It is a bug that should be fixed by the developer/maintainer.  It
> very well COULD be a developer's fault that someone's system went
> haywire.  Usually, though, it is simply a combination of items which was
> not explicitly tested for and ends up being a bug in either the ebuild
> or the package itself.

And I say so what? Again as a gentoo user I accept that risk when I use the 
gentoo distro. If I want "stable" I could run debian stable and be a few 
years back on everything all the time.

> Yes.  You can always add ebuilds to bugzilla.  If you think people will
> be interested in them, stir up some support for them in the forums and
> have people test your ebuilds.  Look at lots of ebuilds and see how the
> "official" developers do things and try to improve the general quality
> of your ebuilds.  Try to help out on Bug Day.  Prove yourself as a
> valuable asset to Gentoo and the development team will scoop you up
> quickly.  It's that simple.

I'll do my best. I feel I owe gentoo, kde, openoffice.org, etc allot and right 
now the only way I can pay back is testing and submitting ebuilds. When I 
have the financial means I'll do that too.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Marius Mauch]

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

On 01/06/04  Robert Cole wrote:

 And I say so what? Again as a gentoo user I accept that risk when I
> use the gentoo distro. If I want "stable" I could run debian stable
> and be a few years back on everything all the time.

You do, but you can't necessarily expect that from all other users too.
Gentoo has become a lot more mainstream in the past year (I leave it for
everyone to decide for themselves if that's good or bad). We can't (and
don't wanto to) control the community and what it expects from us,
Gentoo has to adjust to it's community, not the other way round.
Ask the community if it's safe to use ~arch packages, I'll bet many
people will answer that it is. As a new user you trust them, it breaks
your system badly, you loose some important data. This leaves a bad
image for Gentoo and that can spread very fast.

One idea I've seen in this thread I've thought about some time ago, but
never got it implemented due to lack of time (and maybe skills ;):
A website for users to do some auto-quality checking for their ebuilds,
a webinterface for repoman or similar (so upload your ebuild and get
some feedback about quality without waiting for a dev). Not to replace
but enhance bugzilla. If anyone feels like implementing this, I think it
would be a nice addition.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

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

On Tuesday 06 January 2004 09:39, Robert Cole wrote:
>
> Those systems aren't yours or any other gentoo devs responsibility. I
> think if most gentoo users/admins would really really think about it
> they know the risks they took when they started using gentoo. It's
> bleeding edge using ACCEPT_KEYWORDS or not. I understand, and if every
> gentoo user would really be honest with themselves, that my system
> could go POOF on the next world update. I know mine has a few times in
> the earlier days of gentoo. That's life on the bleeding edge.

I would need to disagree with this. The gentoo project is responsible for 
doing everything reasonable to maintain the integrity of the tree. Say 
in a case where everyone would just be able to add an ebuild to the tree 
given that it compiled, and the tree would get say a trojaned glibc 
turning all gentoo system into spam zombies. Then imagine I was the 
manager of a company that as a result had extra costs of say $100000. In 
that case I would certainly try to sue gentoo technologies inc. I feel 
that I actually should be awarded damages.

While the GPL does have a waranty disclaim, there is no way that this can 
actually be enforced in the case of gross negligence (with most laws, at 
least the European ones). Allowing the gentoo tree to be a free-for-all 
would equal gross negligence for me.

This is certainly not a matter of broken ebuilds or instability it is 
against protection of malice (i.e. criminal behaviour). Besides that 
there must be quality mechanisms in place, but we must protect agains 
criminal behaviour first.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE/+q2wbKx5DBjWFdsRAhOjAKDlYVE2qrHSyTrhZ0KNPkOZlD9XfgCg4gCA
A3UYhU4RfyLy+CjVmHINhyE=
=yQlP
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Robert Cole]

On Tue January 06 2004 4:44 am, Paul de Vrieze wrote:
<snip>
> turning all gentoo system into spam zombies. Then imagine I was the
> manager of a company that as a result had extra costs of say $100000. In
> that case I would certainly try to sue gentoo technologies inc. I feel
> that I actually should be awarded damages.

I'm just going to let this part go but I will say I'm not advocating 
irresponsibility.

> This is certainly not a matter of broken ebuilds or instability it is
> against protection of malice (i.e. criminal behaviour). Besides that
> there must be quality mechanisms in place, but we must protect agains
> criminal behaviour first.

I personally feel the fewer that have access to cvs the better. I and I 
believe Allen are advocating a better middle layer. One that eases the 
shoulders of the cvs devs and one that encourages more participation. 
Currently it doesn't appear that you can have that participation without cvs 
access. 

I don't think anyone that only submits ebuilds should have or even needs cvs 
access. I want to submit and maintain ebuilds but I don't want cvs access 
until I'm submitting patches for portage or some other app.

Robert

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1815 bytes --]

On Tuesday 06 January 2004 16:45, Robert Cole wrote:
> On Tue January 06 2004 4:44 am, Paul de Vrieze wrote:
> <snip>
>
> > turning all gentoo system into spam zombies. Then imagine I was the
> > manager of a company that as a result had extra costs of say $100000. In
> > that case I would certainly try to sue gentoo technologies inc. I feel
> > that I actually should be awarded damages.
>
> I'm just going to let this part go but I will say I'm not advocating
> irresponsibility.

I know you don't, I was just making sure that everyone understands that the 
distribution team can not just ignore that there are very many (hundreds of 
thousands?) systems depending on gentoo and they expect gentoo to have a tree 
that aims at being stable and certainly secure.

> I personally feel the fewer that have access to cvs the better. I and I
> believe Allen are advocating a better middle layer. One that eases the
> shoulders of the cvs devs and one that encourages more participation.
> Currently it doesn't appear that you can have that participation without
> cvs access.

I would be the first one to agree that bugzilla is not perfect, and that a 
better way of handling ebuild submissions would be welcome. However in any 
case there is some level of trust given to the non-dev maintainer. It is 
actually trusting both that this person will actually maintain the ebuild, 
and that the person is actually capable of doing so (and handling the bugs).

What I think would be very likely in such a case is a group of second-class 
citizens that have more recognition than just the next guy, but that are not 
full devs. I don't know whether this is desirable, you decide.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] creating ebuilds

[Jon Portnoy]

On Tue, Jan 06, 2004 at 02:36:53AM -0500, Allen Parker wrote:
> > On Mon, Jan 05, 2004 at 11:05:45PM -0800, Robert Cole wrote:
> > > I would like to start creating ebuilds for products and maintaining them
> > but
> > > I'm a little concerned that my contributions won't be accepted. Will I
> > be
> > > wasting my time asking to be a maintainer for a couple of ebuilds I
> > create
> > > and get them in the tree?
> > >
> > 
> > Generally, when someone asks, my response is an automatic no.
> > 
> > Prove yourself and you'll be picked up as a dev.
> Sorry, this seems a bit elitist. :(

Why, because I don't want to pick up every Tom, Dick, and Harry with a 
couple ebuilds and give them access to the tree, which means access to 
deliver executable data to your system and tens if not hundreds of 
thousands of others? I'm sorry if it's elitist, but someone who's just 
maintaining a couple of ebuilds in most cases does not need CVS access 
and someone who hasn't proven themselves _definitely_ does not need 
CVS access.

Now, if important packages are going unmaintained, _then_ new devs are 
recruited to maintain them. What I'm getting at is that if, say, courier 
(just as an example) is going unmaintained, I (as a recruiter) or other 
devs (as new dev sponsors) will look for people who have a history of 
valuable contributions and ask them to be developers.

None of this means you can't contribute to Gentoo or that contributors 
have no chance of becoming developers. Fundamentally it means I find it 
very difficult to trust people who straight out ask for CVS access. 
Would you do differently in my position?

> 
> Avenj, as I recently was interested in submitting ebuilds myself. Could we
> possibly come up with a quick and easy system for devs to pop in, check a
> list of submitted ebuilds, grab ones that look interesting to them, test to
> see if they build/self-destruct, mark them as ~ARCH (for ARCH they can test
> on), either clear the initial listing and slap them into the tree or kick it
> back to the user?

This is the function bugzilla is supposed to serve. Why would a second 
system be any more efficient?

> 
> Personally, I found it to be a pain in the rear to see 1 1/2 yr old ebuilds
> relating to the packages I was developing ebuilds for in bugzilla, yet with
> information so stale as to be stinking the place up. I think that there are
> a lot of things that could be offered to Gentoo users without too much
> hassle by other Gentoo users as long as dev says "ok, that sounds fun." I
> mean, I got passed back and forth from hardened to general and back a few
> times and it was all because the devs reviewing my bug(s) didn't understand
> the packages.
> 
> I may not know C/C++ very well (minimal understanding at most), so I
> wouldn't be able to "fix" something that was broken via diff, but I sure as
> heck have the computing power to do 100s of compiles :-D and thoroughly test
> certain things before I put them live on my OWN production machines.
> Basically, I'm not a programmer, but I can *still* write a darned good
> ebuild with the proper help (thx Spyderous, obz and others in #gentoo-dev).
> Simply because I can't program, I can't be a dev... does that mean I can't
> do thorough package mangling/testing? Not really... In fact, I've been told,
> that with most things, if anyone can break it, I can :-D

No, but it does mean you probably don't need CVS access at this time.


-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[George Shapovalov]

So, this topic came up again. Well its been a while, more than usual half a 
year :).
Lots have been said about the stalls and the importance of roper maintaince, 
but I want to chime in on another aspect of this issue - the one that's 
causing this (and other similar in the past) discussion[s].

On Tuesday 06 January 2004 07:45, Robert Cole wrote:
> On Tue January 06 2004 4:44 am, Paul de Vrieze wrote:
> > This is certainly not a matter of broken ebuilds or instability it is
> > against protection of malice (i.e. criminal behaviour). Besides that
> > there must be quality mechanisms in place, but we must protect agains
> > criminal behaviour first.
>
> I personally feel the fewer that have access to cvs the better. I and I
> believe Allen are advocating a better middle layer. One that eases the
> shoulders of the cvs devs and one that encourages more participation.
> Currently it doesn't appear that you can have that participation without
> cvs access.

I should say I agree with both sides on many points. However the problem is 
real:
We fant to provide maximum flexibility, (that partially means lots of 
packages) but we want them all be high-quality.
Lets face it, Gentoo is triving mostly because of active user involvment, 
users, who not only [help] fix the bugs and produce new features, but also 
submit new ebuilds. That's in their nature and I am afraid we cannot separate 
these things. We cannot say - we want the part of our users that helps us fix 
the bugs, but we do not want one that's submitting ebuilds :). The roots are 
deep and psychological, as in what constitutes satisfaction. But I'll leave 
this topic and go back to the question at hand.

Gentoo is growing and we are gonna be faced with larger and larger number of 
new submissions. 
So, we can lock the tree and only accept a handfull of new packages now and 
then. Well, I do not think this will work in the long run:
1. This puts a lot of stress on user-developer relations, and it shows in a 
regular outbursts of this nature. Plus the locked distro is effectively a 
dead one - people will start leaving it eventually..
2. Its too late anyway (actually being like that for a long time already). We 
are at 100-200 devs (realistically ~100 "maintainers" as there are many 
doc/infrastructure/other people) but we have 4000+ packages and 7000+ ebuilds 
(may be even more by now). The ratio is already unhealthy and has been like 
that for a long time. It did not grow too fast lately because we were 
stalling somewhat on new submissions, but continuing to do so will increase 
strain and user unhappiness :(.

Another approach: grow the developer base. Not good either - we would have to 
get like 1000 more devs onboard and, eventually, more close to 10000. Plus, 
if we would want to match the speed of ebuild submissions (we are taking 
people in, what I am referring to here is accepting them in "quickly enough") 
we would not be able to do proper trining. So either forget QA or this will 
persist for a bit more. But then growing into 10000 arear has a good chances 
of turning Gentoo into something slow and not very responsive (perhaps other 
that to the maintained ebuilds needs).

So, here I would like to stress the importance of user involvment once again 
and point out that effectively we do rely on it.
I've suggested a possible solution to this dilemma a long time ago (see 
#1523). It hasn'e been GLEPped yet, because I was (am) bisy with other, 
"regular" stuff and because this was suggested loong before GLEPs ever came 
around :). But it will have to if we come to a stage of reall agreement of 
what we want to do. Plus it has to be reworked a lot since then..

That description is based around the idea of "splitting" the tree (via the 
means of KEYWORDS for example, but lots have changed since, we might want 
another way now) into "official" (with its further stable/testing) and "user" 
areas (considered less stable by portage. This makes these submissions 
automatically visible and easy to install for those who care, but retains 
them invisible (and perhaps even unfetchable) for those who dont).

While there was support behind it, there was an opposition as well. One real 
and I think most important objection is along the lines 'do we really want to 
stress our servers by all these "unsupported" ebuilds?'

Nonetheless all is not that bad. We already have a bunch of suggested features 
implemented. Other parts are still in progress - for example 
gentoo-stable/stats was up shortly then it ceased to function, but I believe 
there is an ongoing work on that project "to get it right" this time. 
portage-ng has tied resources lately as well, but it is necessary in order to 
provide a way to get all the necessary hooks in..

In short I think it is possible to resolve this problem and build even more 
versatile system in the end, but this is a lot of work on top of the pending 
changes to the ongoing projects.. And of course this requires a clear support 
of the idea in community (and takes a lot of push to actually accomplish 
things).

George


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[George Shapovalov]

Umh, damn laptop keyboard

> Lots have been said about the stalls and the importance of roper
This should have been "proper" of course :).                       ^^^^^^^

George


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Marius Mauch]

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

On 01/06/04  George Shapovalov wrote:

> That description is based around the idea of "splitting" the tree (via
> the means of KEYWORDS for example, but lots have changed since, we
> might want another way now) into "official" (with its further
> stable/testing) and "user" areas (considered less stable by portage.
> This makes these submissions automatically visible and easy to install
> for those who care, but retains them invisible (and perhaps even
> unfetchable) for those who dont).

Maybe I should say again that I'm working on a portage feature to allow
emerge to sync from multiple repositories, see bugs 28796 and 35535.
That should solve most existing (technical) problems for offering
ebuilds outside
the official tree.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] creating ebuilds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 778 bytes --]


> That description is based around the idea of "splitting" the tree (via the
> means of KEYWORDS for example, but lots have changed since, we might want
> another way now) into "official" (with its further stable/testing) and
> "user" areas (considered less stable by portage. This makes these
> submissions automatically visible and easy to install for those who care,
> but retains them invisible (and perhaps even unfetchable) for those who
> dont).

I think that such an idea would be workable if we do implement at least a 
sanity check. Someone to look over the ebuild and the packages it downloads 
to check whether there are no trojans etc. in it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] creating ebuilds

[foser]

On Tue, 2004-01-06 at 19:56, George Shapovalov wrote:
> Gentoo is growing and we are gonna be faced with larger and larger number of 
> new submissions. 

Why is that, there are only so many packages, the main ones are covered.
There will be new things, others will disappear, but i don't think the
submission rate necessarily increases (i don't have figures, but i doubt
it does).

> So, we can lock the tree and only accept a handfull of new packages now and 
> then. Well, I do not think this will work in the long run:
> 1. This puts a lot of stress on user-developer relations, and it shows in a 
> regular outbursts of this nature. Plus the locked distro is effectively a 
> dead one - people will start leaving it eventually..

As long as you can make clear why it shouldn't be in the tree it should
give no problems, we're all reasonable individuals here. There are no
rules for package rejection at this time, but those could be devised and
should be anyway.
 
> 2. Its too late anyway (actually being like that for a long time already). We 
> are at 100-200 devs (realistically ~100 "maintainers" as there are many 
> doc/infrastructure/other people) but we have 4000+ packages and 7000+ ebuilds 
> (may be even more by now). The ratio is already unhealthy and has been like 
> that for a long time. It did not grow too fast lately because we were 
> stalling somewhat on new submissions, but continuing to do so will increase 
> strain and user unhappiness :(.

The ratio may not be be the best, but ebuilds are pretty simple and
Gentoo's vanilla nature allows for a lot more packages per dev than
other distros have.

> Another approach: grow the developer base. Not good either - we would have to 
> get like 1000 more devs onboard and, eventually, more close to 10000. Plus, 
> if we would want to match the speed of ebuild submissions (we are taking 
> people in, what I am referring to here is accepting them in "quickly enough") 
> we would not be able to do proper trining. So either forget QA or this will 
> persist for a bit more. But then growing into 10000 arear has a good chances 
> of turning Gentoo into something slow and not very responsive (perhaps other 
> that to the maintained ebuilds needs).

In my opinion this is all based on assumptions not necessarily true. For
example, more devs is not necessarily the best solution to more
packages.

I don't think a distros responsiveness is based on the rate it's package
number increases. It's about being responsive to current packages, their
quality and not lingering versions behind for no-good reasons that makes
a distro worthwhile to me.

> So, here I would like to stress the importance of user involvment once again 
> and point out that effectively we do rely on it.

With IRC, mailinglists & bugzilla i feel we're pretty much up to speed
on 'user involvement'. Improvements could be made of course, but the
far-fetched utopian suggestions here are not the way to go in my
opinion.

> That description is based around the idea of "splitting" the tree (via the 
> means of KEYWORDS for example, but lots have changed since, we might want 
> another way now) into "official" (with its further stable/testing) and "user" 
> areas (considered less stable by portage. This makes these submissions 
> automatically visible and easy to install for those who care, but retains 
> them invisible (and perhaps even unfetchable) for those who dont).
> 
> While there was support behind it, there was an opposition as well. One real 
> and I think most important objection is along the lines 'do we really want to 
> stress our servers by all these "unsupported" ebuilds?'

I think that's a non-issue and certainly not the main argument against
it. It's more about ensuring quality of the distro as a whole, where do
you put the line of what is Gentoo and what is not, what is supported
and what isn't. It all becomes a fuzzy area, maybe clear to our users or
not even all of them, certainly not the outside linux world.

I don't expect newcomers to Gentoo/Linux that now happily use ~arch
because someone on IRC recommended it -while it really is meant as a
testing ground for experienced users, to help out the distro- to know
the difference between the different levels of Gentoo-ness or make a
conscience choice on what they want. They probably go for 'hey that's a
cool new alpha quality app on that screenie. Hey more cool, someone on
IRC says it's in the Gentoo user submitted ebuilds level, i'll make that
my default level from now on.', getting an unreliable distro in return.
This may be a bleak picture, but in a sense these things are already
happening.

I also fear that devs will miss important changes in ebuilds. For
example, say you are a dev and only do reviews, you probably take the
easy way out sometimes and just check for syntactical correctness, say
ok and grant it in on a higher level, while for all you know all deps
may have changed, options may have been added, etc. This already happens
in devland for all i know, i see ebuilds where i'm pretty sure the
actual package source never got checked on a bump. This isn't too
problematic if it happens on occasion, but if it is done on a regular
basis the quality of the ebuild decreases.

Besides that i see ebuild submissions as a way to educate users on how
to write proper ebuilds as-is. Hardly ever i get ebuilds submitted that
i do not have to work on, this is nothing more than logical : I do a lot
more review/ebuilding than the general user. Submitting a user ebuild
without review is a bad idea. And the whole QA deal in the tree itself
is already a problem and a lot of ebuild mistakes are made by devs also,
so lets start there and make sure all devs do it correctly.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] creating ebuilds

[Jason Stubbs]

On Saturday 10 January 2004 20:13, foser wrote:
> On Tue, 2004-01-06 at 19:56, George Shapovalov wrote:
> > That description is based around the idea of "splitting" the tree (via
> > the means of KEYWORDS for example, but lots have changed since, we might
> > want another way now) into "official" (with its further stable/testing)
> > and "user" areas (considered less stable by portage. This makes these
> > submissions automatically visible and easy to install for those who care,
> > but retains them invisible (and perhaps even unfetchable) for those who
> > dont).
> >
> > While there was support behind it, there was an opposition as well. One
> > real and I think most important objection is along the lines 'do we
> > really want to stress our servers by all these "unsupported" ebuilds?'
>
> I think that's a non-issue and certainly not the main argument against
> it. It's more about ensuring quality of the distro as a whole, where do
> you put the line of what is Gentoo and what is not, what is supported
> and what isn't. It all becomes a fuzzy area, maybe clear to our users or
> not even all of them, certainly not the outside linux world.
>
> I don't expect newcomers to Gentoo/Linux that now happily use ~arch
> because someone on IRC recommended it -while it really is meant as a
> testing ground for experienced users, to help out the distro- to know
> the difference between the different levels of Gentoo-ness or make a
> conscience choice on what they want. They probably go for 'hey that's a
> cool new alpha quality app on that screenie. Hey more cool, someone on
> IRC says it's in the Gentoo user submitted ebuilds level, i'll make that
> my default level from now on.', getting an unreliable distro in return.
> This may be a bleak picture, but in a sense these things are already
> happening.

A little bit of a side issue, but this is actually seems to be quite a big 
problem. I'm a relative newbie to the IRC channels and haven't really seen it 
on the forums or mailing list, but the standard response to "I'm installing 
Gentoo for the first time - can you tell me what the best method is?" seems 
to be "2.6 kernel and ~arch" from two thirds of the respondents. I've even 
seen recommendations for breakmygentoo to a new user. Another one is "emerge 
says the digest is wrong - what should I do?" with the 'answer' being "run 
ebuild <ebuild> digest".

Maybe something similar to Spider's recent developer-wide reprieve would be 
good in the GWN for the short-term. For the long-term, though, Gentoo "dos 
and donts" or, more to the point, "what Gentoo supports" really need to be 
explained to a new user from the beginning. Coming back to the topic, any 
'solution' that allows user-contributed ebuilds to bypass QA (and even 
breakmygentoo has minimal QA) needs to be thoroughly pre-advised too.

--
Regards,
Jason Stubbs

--
gentoo-dev@gentoo.org mailing list