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". --Dan -- gentoo-dev@gentoo.org mailing list
