| 1 |
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: |
| 2 |
> Asking developers to "proxy" takes almost as much time as it does to |
| 3 |
> ask them to maintain a package by themselves. |
| 4 |
|
| 5 |
wrong |
| 6 |
|
| 7 |
> The developer is |
| 8 |
> directly responsible for anything he commits, so he will have to still |
| 9 |
> test the ebuild, still test any revisions, and still follow the |
| 10 |
> package to make sure there are no problems. The writing the ebuild |
| 11 |
> part of the process is not that much of the commitment, I don't see |
| 12 |
> the point. |
| 13 |
> |
| 14 |
|
| 15 |
we are not just talking about new ebuilds/bumps |
| 16 |
having someone do all the work and having to only verify the end results |
| 17 |
of the users work is a big help, instead of having to look into the |
| 18 |
problem, checking if a fix exists elsewhere, or digging through the |
| 19 |
source yourself, you verify the fix solves the problem and does only |
| 20 |
that. |
| 21 |
|
| 22 |
and everyone wins |
| 23 |
|
| 24 |
> On 3/22/06, Thomas Cort <linuxgeek@×××××.com> wrote: |
| 25 |
> > > > A developer could then take these ebuilds, make sure they |
| 26 |
> > > > don't do anything malicious, or break QA, or whatever, and act as the |
| 27 |
> > > > bridge between the portage tree and the users actually working on the |
| 28 |
> > > > ebuild and keeping things up to date and working. |
| 29 |
> > |
| 30 |
> > > The easiest way to handle "contrib" as far as that "big warning" is to |
| 31 |
> > > make it a separate tree. That way, folks who want the flexibility get |
| 32 |
> > > it, but those who prefer not to "risk it", don't have to worry about it. |
| 33 |
> > > As well, contribs becomes another fertile developer recruitment ground. |
| 34 |
> > |
| 35 |
> > Why would the packages need a "big warning"/overlay/eclass if they |
| 36 |
> > were checked by a developer to make sure they "don't do anything |
| 37 |
> > malicious, or break QA, or whatever"? There are many user contributed |
| 38 |
> > ebuilds that have made their way into portage after being reviewed by |
| 39 |
> > devs that don't have any such warnings. |
| 40 |
> > |
| 41 |
> > I don't think creating a "contrib" overlay as an official part of |
| 42 |
> > Gentoo would be a good idea because making it an official Gentoo |
| 43 |
> > project conveys a certain level of quality. If the quality is there, |
| 44 |
> > then why not add the ebuilds to portage in the first place? If the |
| 45 |
> > quality isn't there, then you will have a lot of unhappy users |
| 46 |
> > complaining that an official Gentoo overlay broke their system. |
| 47 |
> > |
| 48 |
> > Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea |
| 49 |
> > either IMO because the contributors wouldn't be contributing to |
| 50 |
> > Gentoo, and they wouldn't be interacting as much with the Gentoo |
| 51 |
> > developer community. Sure they would learn a lot of the skills |
| 52 |
> > required to be a Gentoo developer, but they wouldn't be increasing the |
| 53 |
> > value of anything in portage (unless they got a proxy to commit some |
| 54 |
> > of their work to portage). Also, there are many overlays out there |
| 55 |
> > already. Adding another one won't help with "making the developer |
| 56 |
> > community more open". Additionally, I don't personally know of a lot |
| 57 |
> > of people who actually use third party overlays except to get an |
| 58 |
> > ebuild for a particular package they want or to beta test ebuilds. |
| 59 |
> > |
| 60 |
> > -Thomas |
| 61 |
> > |
| 62 |
> > -- |
| 63 |
> > gentoo-dev@g.o mailing list |
| 64 |
> > |
| 65 |
> > |
| 66 |
> |
Archives