On Fri, 2006-06-09 at 16:18 -0400, Daniel Ostrow wrote: > On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote: > > On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote: > > > > Markus Ullmann wrote: > > > > > Maybe that way we avoid any misunderstandings, nearly doubled posts > > > > > and > > > > > repeating ourselves over and over again. > > > > > > > > The problem is that some questions and answers easily get lost in a > > > > mailing > > > > list. To solve this shortcoming, I am starting to make a FAQ page in the > > > > trac wiki: > > > > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq > > > > > > > > We are adding new questions there, if you have some additions, please > > > > talk > > > > to me and I will add them for you. > > > > > > I have one... > > > > > > What will it take for this project to go away? > > > > > I have a counter-question to this: What modifications to the sunrise > > (not sunrice, btw) project would have to be made to get you to stop > > actively trying to shut it down? I really don't care if you think the > > team will be willing to make the changes, list them anyway, please. :) > > > > I'm asking because I think that this project is a Good Thing, if it > > gets handled correctly. I also agree that if it is not handled > > correctly it can and will be a Very Bad Thing. > > > To start with (and mind you this is just my list): > > 1). At least one member of the project must be familiar enough with each > of the officially supported architectures, x86, amd64, ppc, ppc64, hppa, > alpha, mips, sparc and ia64, to support any bugs which arise due to arch > specific issues. The level of knowledge must be on par with that which > is required to join any of the aforementioned arch teams. This is the > only way to ensure that arch teams do not experience a higher work load > because of this overlay's existence. > > 2). For a package to be added to the overlay at least one member of the > project must be familiar enough with the package that they would be > accepted into the team that would maintain the package if it were in the > mainline tree if they are not already a team member. This is the only > way to ensure that non-arch teams do not experience a higher work load > because of this overlay's existence. > > 3). Teams must have the option to "opt-out" of participation. What this > would mean is if a team "opts-out" no packages may be placed in the > overlay that would be maintained by said team if the package was added > to the main tree. > > 4). Packages cannot be added that are version bumps or bug fixes of > packages that are already in the tree. > > 5). The project must have an active security liaison who's job it would > be to ensure that there are no packages in the overlay that have > outstanding vulnerabilities. > > 6). The project must have an active QA liaison who's job it would be to > ensure that *all* of the QA standards that are applied to the main tree > are also applied to the projects overlay. > > And the above is just the tip of the iceberg...but satisfy those and > I'll give you the rest. > > The next thing I'll hear is "But this is really no different then > hosting them on Bugzilla except it lowers the bar for their use..." > Which brings me to my next point...like it or not the lower the bar for > their use the more generally accepted the idea that using the ebuilds in > this overlay is "officially supported".
I would accept these steps being completed as a nice barrier for entry for this project to start to be useful as a development tool. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
