Re: [gentoo-dev] Project Sunrise -- Proposal

[Daniel Ostrow]

Comments inline ...

On Sat, 2006-06-10 at 13:37 +0200, Markus Ullmann wrote:
> Okay, so after figuring out open problems (thanks to kloeri and various
> other people for help here), we now have a resolution that should
> satisfy all involved parties here. This should adress dostrow's demands
> as well.
>
> 1) m-w / m-n requirement
>
> Only ebuilds that are reported to bugzie (valid bug#) and set to
> maintainer-wanted are allowed here as well as maintainer-needed ones.
>
> maintainer-needed are only allowed if they're removed from the tree and
> moved over to sunrise (and thus end up as maintainer-wanted again).

Fine.

> 2) Not one large tree but subdirs, one per herd
>
> to help herds better keeping track of which parts are alive in the
> overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
> a netmon/ dir with net-analyzer/specialapp below it.

Fine.

> 3) a yes from herds required, keeping a timeout to avoid bugspam
>
> after a comment has been placed on a maintainer-wanted bug in bugzie,
> there's a grace time of two weeks for herds to either leave a comment on
> whether they're fine with take over or not. When this time is over and
> it is assigned to maintainer-wanted, then and only then it is implied as
> an OK to keep it also in the sunrise project.

I'm 100% against implicit acceptance. If someone from the sunrise
project wishes to add an ebuild to the overlay they should have to get
an explicit OK from the team in question. The sunrise project could of
course keep a list of teams that have given a blanket OK and of those
that have totally opted out. For those teams in between an OK per
package sought by the sunrise project's team members is needed. I'm
sorry but the leg work to track this stuff and get acceptance has to be
100% on your projects head. Your proposal adds a need for me to actually
look at bugs for packages that I may have no interest in. I don't pay
any attention to maintainer-wanted now I don't want to pay any attention
to a subset of that ever.

> 4) work needed by herds
>
> - take a look at the homepage of the new program
> - take a look at the ebuild
>
> If you're at least partly happy with the new app, drop a note on the bug
> or just ping sunrise that you're ok with it. Then sunrise takes it over
> and improves the ebuild together with the contributor so that it reaches
> a level where it could theoretically be committed to the tree.
> Herds are more than welcome to help here if they feel like it but basic
> checks whether the app should ever be on gentoo will be sufficient.

So long as this is voluntary and the level of acceptance that I
described above is met I'm OK with it. 

> 5) commit access to the overlay
>
> We implement two levels of commit rights:
>
> 1. As there are people out there who just want to maintain one app for
> start, the ebuild should reach a level that project devs are fine with
> it, then the user is given permission to commit on that single app. An
> automated check makes sure that he doesn't commit anywhere else. If
> violations arise, the access is revoked immediately.
>
> 2. People who contribute good ebuilds over a certain period of time are
> allowed upon decision by project devs to actively help maintaining the
> project. They'll be given commit rights for the project then. Same frome
> above applies here: If we notice any abuse, we revoke access immediately.

Again so long as the team that would have to maintain it in the tree
says OK *explicitly* then sure.

> 6) QA assurance
>
> Of course there are minor issues with the ebuilds, otherwise they could
> be committed straight forward. Important thing is that it only finds the
> way into overlaye if the trusted committers (project devs and users who
> are given permission explicitely, see above) are fine with it.
> Additional note on arch issues: initially, just ~x86 and ~amd64 may be
> set. The rest would need successful test reports for other ~arch
> keywords. Stable keywording isn't permitted at all, there will be some
> automated check to make sure no one does it (by accident) here.
>
> Additional note: we won't start adding this to layman and making it
> available easier until the QA checks have been implemented.

Erm...no! See that is the thing about item #1 on my list...there is
nothing preventing Joe User from checking out the overlay and adding say
a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
*will* be generated for arch teams for packages that are not in the
tree.

Also note I'm not talking necessarily about the "Hey, I installed
${package} and it broke." bugs because if ${package} isn't in the tree
bug-wranglers can catch it and off you go...the arch teams aren't
involved. What I am talking about is "Hey, my ppc64 started doing weird
things yesterday, ${daemons} are no longer working." having that bug
assigned to the arch team, and then spending a long time only to track
down that the user installed some random library from sunrise seven days
ago and there just happened to be upgrades to programs that took
advantage of said library in unexpected ways.

The *only* way you can avoid dumping that sort of stuff onto the arch
teams is to have the expertise in house. Otherwise a VERY BAD habit will
form. Dev A looks at a bug, sees the sunrise overlay listed in emerge
--info and before looking even an iota further will assign it to the
sunrise project because who knows the problem *may* have come from some
unknown ebuild there and there is *no* way to know without a lot of
potentially wasted time. This *will* lower the quality of the
distribution as a whole. So...nope I don't accept the stipulation that
it will only be ~amd64 and ~x86 for now because there is no way you can
keep it that way once it hits the users machine.

I also strenuously object to the addition of other keywords without
someone on the sunrise project who can verify the reports validity. This
means by the way, having access to the arch yourself *and* having enough
understanding of the package and the arch to be able to keyword...for
the main tree we call this being an arch team member.

Above and beyond that until QA checks that meet or exceed the main
tree's standards are in place...don't bother.

> 7) tag on bugs
>
> All ebuilds that are made available on sunrise get an InOverlay KEYWORDS
> entry on bugs.g.o so that everyone, who looks at the bug, knows about it.

OK.

> 8) Grace time also given from the go point on.
>
> When we see that this gets a bit fine-tuning / acceptance among devs, we
> will explicitely call out a two weeks notice for ebuilds currently
> assigned to maintainer-wanted so that herds can keep an eye on them and
> either comment as given, reject take over permission completely, close
> as WONTFIX in case they're against the app for the tree in futures or
> just drop a note that they're fine with the take over and the
> development can be started on the ebuild.
> Remember the way they need to be reviewed as said in 4). The ebuild is
> subject to development, the sunrise devs do help with it in case your
> herd lacks time to completely take care of it.

See my comments above...an explicit OK is needed, an explicit rejection
with an implicit acceptance just plain won't do.

> 9) Security
>
> In this early stage we have no security liaison on board yet. If one is
> willing to help out here, we'd be  more than glad on welcoming him  :)

And until you do...don't bother.

Thanks for going over what I put out there but there is still a good
ways to go. I hope you see from my statements above that part of what
I'm getting at is it'll take *many many* devs to do this right. At the
moment I know of you and genstef, and again not meaning this as a dig,
but that is nowhere near enough.

The bugs are languishing because there are not enough devs to maintain
them and/or not enough interest in them. Making them more usable without
a nearly identical support structure to the main tree will not make the
social problem go away, it'll just introduce many new weird technical
problems into an already overburdened equation.

I understand the desire to use this as a facility to "train-up" new devs
but I'm frankly flabbergasted that you seem to overlook the potentially
huge burden this will place on the rest of the developer community until
such time as each and every package in sunrise is in the main tree with
a maintainer. In the long run things may get a little better, in the
short run there is a very large potential for things to get *much*
worse. 

--Dan