Re: [gentoo-dev] Unstable branch proposal - second round

[Michael Lang]

I like this decentralized idea as it lets the users help drive the ebuild 
tree without core developers being involved in every single 
decision.  However, I think it is flawed in trying to push users to the 
bugzilla interface as this forces the user to learn yet another interface 
with dealing with Gentoo ebuilds.  Why not borrow Freshmeat's design for 
searching, displaying and drilling down to the various packages available 
in the portage tree.

As you just pointed out, a lot of information is getting lost because your 
average Joe isn't hanging out in bugzilla.  However, if you had a comment 
style section such as Freshmeat has, then bugs and issues could also go 
here and we could let users "vote" on how their installs went as well as 
report problems right there on the package's description and ranking page 
along with all the other fun stuff Freshmeat rolls into their site.

I don't know how difficult this next suggestion would be, but it would be 
great if the user had an "Emerge" link as opposed to Freshmeat's tarball, 
rpm, binaries, src links, and that kicked off the emerge...if emerge 
failed, the error gets cookied back to the browser and user gets presented 
with a short submission form asking him to describe what went wrong.  This 
form is then sent to bugzilla upon user hitting submit.  Of course, if the 
build goes successfully, then a success submission form is offered and user 
is allowed to comment, rank, etc. and submit.

If users are going to be allowed to write ebuilds and submit them to the 
tree, then perhaps the bug submission is routed to the original ebuild 
submitter and he has a set number of days to respond.  If he doesn't 
respond within that time period, then the bug gets routed to a core developer.

The beauty of this?  Those familiar with Freshmeat barely have to learn a 
new interface and the whole Freshmeat site has *got* to be open source 
available somewhere to make this a fast start towards this sort of vision.

At 12:59 PM 3/16/2002 -0800, you wrote:
>Hi again
>
>I would like to somewhat clarify my previous submission.
>So the new ebuild submission and processing procedure can be as follows:
>
>1. new ebuild gets submitted through bugs.gentoo.org as it is now (no change)
>change starts:
>2. it immediately gets incorporated into the main portage tree with the
>"unstable" status (robot).
>3. ebuild voting statistics are kept on bugs.gentoo.org, attached to ebuild
>submission topic. Voters have to be registered with bugs.gentoo.org as they
>are now.
>4. When ebuild accumulates enough unique votes is gets "confirmed" status
>Meanwhile updates and patches to ebuild are submitted as usual but whoever
>cares to correct/update it via existing mechanism.
>5. if ebuild reaches second threshold of "approval wanted" votes or is of
>special interest for core group it gets reviewed and manually assigned
>"approved" status and is maintained by the core group.
>Or there can be additional layer, where ebuild just gets an approval and then
>when it gets core maintaince it gets "core" status.
>
>Comments
>It can seem like a lot of new activity for bugs.gentoo.org. However half of
>that functionality is already implemented and activity is taking place. The
>other half is happening and requires manual interaction. Ebiuld submissions
>are soaring so that some rework of bugs.gentoo.org will probably be necessary
>anyway. This looks like a way to simplify life fore core developers and
>everybody else. (When ebuilds start to be posted to mailing list instead of
>accepted procedure is the time to start thinking about the procedure I think).
>
>
>George
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@g.o
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev

President
www.cybrains.net

"All things should be as simple as possible, but no simpler" -- Albert Einstein