Re: [gentoo-dev] Re: Making the developer community more open
On Thu, 2006-03-23 at 18:34 -0500, Dan Meltzer wrote: > On 3/23/06, Daniel Goller <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: > > > Asking developers to "proxy" takes almost as much time as it does to > > > ask them to maintain a package by themselves. > > > > wrong > > > > > The developer is > > > directly responsible for anything he commits, so he will have to still > > > test the ebuild, still test any revisions, and still follow the > > > package to make sure there are no problems. The writing the ebuild > > > part of the process is not that much of the commitment, I don't see > > > the point. > > > > > > > we are not just talking about new ebuilds/bumps > > having someone do all the work and having to only verify the end results > > of the users work is a big help, instead of having to look into the > > problem, checking if a fix exists elsewhere, or digging through the > > source yourself, you verify the fix solves the problem and does only > > that. > > > > and everyone wins > > So it sounds like you are asking them to do everything developers do, > > why not just make them be developers? > > because they do not want more than take care of their one package and do not want more than someone taking care of their work, maybe? or maybe because they don't like a lot of devs due to bad experiences, and would not want to be any part of the group, but still enjoy working on packages there are people who i would love to see as devs, but are not particularly interested on having to deal with some of the devs, having a proxy allows them to help gentoo w/o being exposed to the people they otherwise would have to deal with signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Making the developer community more open
On 3/23/06, Daniel Goller <[EMAIL PROTECTED]> wrote: > On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: > > Asking developers to "proxy" takes almost as much time as it does to > > ask them to maintain a package by themselves. > > wrong > > > The developer is > > directly responsible for anything he commits, so he will have to still > > test the ebuild, still test any revisions, and still follow the > > package to make sure there are no problems. The writing the ebuild > > part of the process is not that much of the commitment, I don't see > > the point. > > > > we are not just talking about new ebuilds/bumps > having someone do all the work and having to only verify the end results > of the users work is a big help, instead of having to look into the > problem, checking if a fix exists elsewhere, or digging through the > source yourself, you verify the fix solves the problem and does only > that. > > and everyone wins So it sounds like you are asking them to do everything developers do, why not just make them be developers? > > > On 3/22/06, Thomas Cort <[EMAIL PROTECTED]> wrote: > > > > > A developer could then take these ebuilds, make sure they > > > > > don't do anything malicious, or break QA, or whatever, and act as the > > > > > bridge between the portage tree and the users actually working on the > > > > > ebuild and keeping things up to date and working. > > > > > > > The easiest way to handle "contrib" as far as that "big warning" is to > > > > make it a separate tree. That way, folks who want the flexibility get > > > > it, but those who prefer not to "risk it", don't have to worry about > > > > it. > > > > As well, contribs becomes another fertile developer recruitment ground. > > > > > > Why would the packages need a "big warning"/overlay/eclass if they > > > were checked by a developer to make sure they "don't do anything > > > malicious, or break QA, or whatever"? There are many user contributed > > > ebuilds that have made their way into portage after being reviewed by > > > devs that don't have any such warnings. > > > > > > I don't think creating a "contrib" overlay as an official part of > > > Gentoo would be a good idea because making it an official Gentoo > > > project conveys a certain level of quality. If the quality is there, > > > then why not add the ebuilds to portage in the first place? If the > > > quality isn't there, then you will have a lot of unhappy users > > > complaining that an official Gentoo overlay broke their system. > > > > > > Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea > > > either IMO because the contributors wouldn't be contributing to > > > Gentoo, and they wouldn't be interacting as much with the Gentoo > > > developer community. Sure they would learn a lot of the skills > > > required to be a Gentoo developer, but they wouldn't be increasing the > > > value of anything in portage (unless they got a proxy to commit some > > > of their work to portage). Also, there are many overlays out there > > > already. Adding another one won't help with "making the developer > > > community more open". Additionally, I don't personally know of a lot > > > of people who actually use third party overlays except to get an > > > ebuild for a particular package they want or to beta test ebuilds. > > > > > > -Thomas > > > > > > -- > > > gentoo-dev@gentoo.org mailing list > > > > > > > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (GNU/Linux) > > iD8DBQBEIx8o/aM9DdBw91cRAmVoAKC8JtAm2vvWGBG2YMzpI+EGu8RFJwCeOMll > lCv/CsLde+6MbDHgX8EuKhU= > =w+ap > -END PGP SIGNATURE- > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: > Asking developers to "proxy" takes almost as much time as it does to > ask them to maintain a package by themselves. wrong > The developer is > directly responsible for anything he commits, so he will have to still > test the ebuild, still test any revisions, and still follow the > package to make sure there are no problems. The writing the ebuild > part of the process is not that much of the commitment, I don't see > the point. > we are not just talking about new ebuilds/bumps having someone do all the work and having to only verify the end results of the users work is a big help, instead of having to look into the problem, checking if a fix exists elsewhere, or digging through the source yourself, you verify the fix solves the problem and does only that. and everyone wins > On 3/22/06, Thomas Cort <[EMAIL PROTECTED]> wrote: > > > > A developer could then take these ebuilds, make sure they > > > > don't do anything malicious, or break QA, or whatever, and act as the > > > > bridge between the portage tree and the users actually working on the > > > > ebuild and keeping things up to date and working. > > > > > The easiest way to handle "contrib" as far as that "big warning" is to > > > make it a separate tree. That way, folks who want the flexibility get > > > it, but those who prefer not to "risk it", don't have to worry about it. > > > As well, contribs becomes another fertile developer recruitment ground. > > > > Why would the packages need a "big warning"/overlay/eclass if they > > were checked by a developer to make sure they "don't do anything > > malicious, or break QA, or whatever"? There are many user contributed > > ebuilds that have made their way into portage after being reviewed by > > devs that don't have any such warnings. > > > > I don't think creating a "contrib" overlay as an official part of > > Gentoo would be a good idea because making it an official Gentoo > > project conveys a certain level of quality. If the quality is there, > > then why not add the ebuilds to portage in the first place? If the > > quality isn't there, then you will have a lot of unhappy users > > complaining that an official Gentoo overlay broke their system. > > > > Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea > > either IMO because the contributors wouldn't be contributing to > > Gentoo, and they wouldn't be interacting as much with the Gentoo > > developer community. Sure they would learn a lot of the skills > > required to be a Gentoo developer, but they wouldn't be increasing the > > value of anything in portage (unless they got a proxy to commit some > > of their work to portage). Also, there are many overlays out there > > already. Adding another one won't help with "making the developer > > community more open". Additionally, I don't personally know of a lot > > of people who actually use third party overlays except to get an > > ebuild for a particular package they want or to beta test ebuilds. > > > > -Thomas > > > > -- > > gentoo-dev@gentoo.org mailing list > > > > > signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Making the developer community more open
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: > Asking developers to "proxy" takes almost as much time as it does to > ask them to maintain a package by themselves. The developer is > directly responsible for anything he commits, so he will have to still > test the ebuild, still test any revisions, and still follow the > package to make sure there are no problems. The writing the ebuild > part of the process is not that much of the commitment, I don't see > the point. Well no, that's not really what I was suggesting. Developers who took on these ebuilds would only be responsible for checking that they don't break the tree and that they do actually work. They aren't responsible for fixing the package when it breaks, or for following its development at all - that's the responsibility of the _users_ maintaining the package. Yes, writing the ebuild is the least part of the process, but there's often a lot more involved, and it's that that's being done in bugzilla at the moment. The way I see it, the developer would only be responsible for the ebuilds, and not for doing everything else. -- Jonathan Coome <[EMAIL PROTECTED]> Gentoo Forums Moderator -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making the developer community more open
Asking developers to "proxy" takes almost as much time as it does to ask them to maintain a package by themselves. The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. On 3/22/06, Thomas Cort <[EMAIL PROTECTED]> wrote: > > > A developer could then take these ebuilds, make sure they > > > don't do anything malicious, or break QA, or whatever, and act as the > > > bridge between the portage tree and the users actually working on the > > > ebuild and keeping things up to date and working. > > > The easiest way to handle "contrib" as far as that "big warning" is to > > make it a separate tree. That way, folks who want the flexibility get > > it, but those who prefer not to "risk it", don't have to worry about it. > > As well, contribs becomes another fertile developer recruitment ground. > > Why would the packages need a "big warning"/overlay/eclass if they > were checked by a developer to make sure they "don't do anything > malicious, or break QA, or whatever"? There are many user contributed > ebuilds that have made their way into portage after being reviewed by > devs that don't have any such warnings. > > I don't think creating a "contrib" overlay as an official part of > Gentoo would be a good idea because making it an official Gentoo > project conveys a certain level of quality. If the quality is there, > then why not add the ebuilds to portage in the first place? If the > quality isn't there, then you will have a lot of unhappy users > complaining that an official Gentoo overlay broke their system. > > Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea > either IMO because the contributors wouldn't be contributing to > Gentoo, and they wouldn't be interacting as much with the Gentoo > developer community. Sure they would learn a lot of the skills > required to be a Gentoo developer, but they wouldn't be increasing the > value of anything in portage (unless they got a proxy to commit some > of their work to portage). Also, there are many overlays out there > already. Adding another one won't help with "making the developer > community more open". Additionally, I don't personally know of a lot > of people who actually use third party overlays except to get an > ebuild for a particular package they want or to beta test ebuilds. > > -Thomas > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
> The process for getting unstable ebuilds from bugzilla to portage could > even be automated to the extent that when an ebuild is put into > bugzilla it gets auto committed to the tree but masked unstable. I don't think that auto committing user submitted ebuilds is safe, even if they are masked. For instance, someone could put something malicious in global scope in the ebuild. Stuff in global scope gets interpreted whenever the ebuild is sourced. More info on scope: http://www.gentoolinux.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3_sect4 -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
> > A developer could then take these ebuilds, make sure they > > don't do anything malicious, or break QA, or whatever, and act as the > > bridge between the portage tree and the users actually working on the > > ebuild and keeping things up to date and working. > The easiest way to handle "contrib" as far as that "big warning" is to > make it a separate tree. That way, folks who want the flexibility get > it, but those who prefer not to "risk it", don't have to worry about it. > As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a "big warning"/overlay/eclass if they were checked by a developer to make sure they "don't do anything malicious, or break QA, or whatever"? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a "contrib" overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with "making the developer community more open". Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
On 3/22/06, Duncan <[EMAIL PROTECTED]> wrote: > A possible alternative that could be rolled out sooner would be some form > of "contrib" eclass. Make it a simple matter to inherit contrib and get > the standard contrib warnings and handling. One thing the eclass could > handle would be a USE=contrib flag. With it off, the build wouldn't > merge. That would take care of user choice. No non-contrib package could > dep on a contrib package so if such a dependency came about, either the > non-contrib package would have to be dropped (or at least dropped to > contrib status even if it was "contributed" by a dev), or the dep raised > to full support (non-contrib) status. > > The dependency rule above would by definition mean that nobody could get > contrib accidentally, since the only way to get a contrib package would be > merging it or another contrib package that depended on it from the command > line. This would also solve the interactivity aka broken emerge session > issue, since the portage protest and failure would be right up front, > before merging started. > > Making it a use flag would allow control of specific packages thru > package.use, just as now, so a user could decide that he trusted one > contributor as the author of a specific package (and his opinion of the > dep chain) without forcing it to apply to the entire contrib tree. > > There remains the question of naming. A contrib-cat/package tree > paralleling the main category structure would potentially double the > categories right there. Not really practical. cat/package-contrib-ver > would be more practical, and allow on-sight identification, but would of > course necessitate a package rename if the contrib vs. full-supported > status changed. This aspect could be debated if the idea in general gains > enough favor to consider a glep or the like. Maybe taking a slightly different approach at this same idea is what needs done. Create a new mask level for contrib where anything deemed "stable" yet unmaintained could go so that users will have access to it without needing to search bugzilla or some third-party site. I would also propose an unstable mask as well where testing ebuilds can go, things that are in bugzilla but have not yet been vetted. The process for getting unstable ebuilds from bugzilla to portage could even be automated to the extent that when an ebuild is put into bugzilla it gets auto committed to the tree but masked unstable. This way all the "latest greatest" ebuilds are always available in the tree but it requires the user to consciously unmask them for use. You could even add a big red warning for unstable ebuilds to let people know that they should examine the ebuild before emerging... just so if they DO get rooted due to a bad ebuild you can say they where warned. You could further extend the process of emerging unstable ebuilds so that a successful emerge would create a vote "for" the ebuild in bugzilla (attached to the original ebuild bug) and an unsuccessful emerge would allow the user to add a comment/vote against the ebuild in bugzilla. Perhaps it is a radical approach but that's just my $0.02 on how to open the dev community. -Mike -- Michael E. Crute http://mike.crute.org It is a mistake to think you can solve any major problems just with potatoes. --Douglas Adams -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making the developer community more open
Jonathan Coome posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Mar 2006 10:49:29 +: > Taking this idea a bit further, what about proxy maintainers? There seem > to be quite a few packages that are being effectively maintained by > users on bugzilla, but are not in portage because they don't have a > maintainer. A developer could then take these ebuilds, make sure they > don't do anything malicious, or break QA, or whatever, and act as the > bridge between the portage tree and the users actually working on the > ebuild and keeping things up to date and working. [snip the juicy details] I think this sounds very much like the Mandrake contrib packages, back when I was there. It's a decent idea and it seemed to work reasonably well, from a user and active cooker/testing participant. The easiest way to handle "contrib" as far as that "big warning" is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to "risk it", don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Unfortunately, for that, portage needs full multi-repository support. Overlays function much that way already, but to do it right, we need multi-repository-update support, and Portage just doesn't have it yet. ... A possible alternative that could be rolled out sooner would be some form of "contrib" eclass. Make it a simple matter to inherit contrib and get the standard contrib warnings and handling. One thing the eclass could handle would be a USE=contrib flag. With it off, the build wouldn't merge. That would take care of user choice. No non-contrib package could dep on a contrib package so if such a dependency came about, either the non-contrib package would have to be dropped (or at least dropped to contrib status even if it was "contributed" by a dev), or the dep raised to full support (non-contrib) status. The dependency rule above would by definition mean that nobody could get contrib accidentally, since the only way to get a contrib package would be merging it or another contrib package that depended on it from the command line. This would also solve the interactivity aka broken emerge session issue, since the portage protest and failure would be right up front, before merging started. Making it a use flag would allow control of specific packages thru package.use, just as now, so a user could decide that he trusted one contributor as the author of a specific package (and his opinion of the dep chain) without forcing it to apply to the entire contrib tree. There remains the question of naming. A contrib-cat/package tree paralleling the main category structure would potentially double the categories right there. Not really practical. cat/package-contrib-ver would be more practical, and allow on-sight identification, but would of course necessitate a package rename if the contrib vs. full-supported status changed. This aspect could be debated if the idea in general gains enough favor to consider a glep or the like. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
