Mailing List Archive

On Sat, 10 Jun 2006 13:37:15 +0200
Markus Ullmann <jokey@gentoo.org> 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).

> 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.

One more rule I'd like to see (should be obvious, but better to write
it down):

People who commit to a certain project/ebuild have to be on the CC
list of the relevant bug report(s) and any important commits should be
documented on the bugs (including the revision of/link to the commit).

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

On 6/10/06, Markus Ullmann <jokey@gentoo.org> 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).
>
> 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.
>

If its unofficially part of a herd, then isn't it no longer a m-w/m-n ebuild?

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 :)
>
>
> Greetz,
> Jokey
>
>
>
>


I think this is a much improved//thought out version of the proposal.
From the looks of things sunrise should never make it to layman
however, because as we all know, anything that makes things more
easily accessible to users is going to be (mis)used by more of them.
From what I understand, you see Sunrise as an overlay for users to
improve their ebuilds because they are insufficient quality to be in
the main tree. If they are of this poor quality, they should be no
where near users hands, this doesn't make sense.

If on the other hand you saw sunrise as a way for more packages to be
available to users due to there being a lack of maintainers, asking
herds to check out ebuilds as part of the proposal seems
counterproductive to the cause.

Maybe you should expand on the goal of the sunrise project, what
exactly do you want it to do?
--
gentoo-dev@gentoo.org mailing list

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

On Sat, Jun 10, 2006 at 01:37:15PM +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.

While I do think this proposal is much better than the previous
non-existing proposal, it still doesn't address the problem of having
the sunrise overlay hosted on a non *.gentoo.org address to make it
100% clear to the public that it is unsupported.

Regards,
Brix
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

Henrik Brix Andersen wrote:
> On Sat, Jun 10, 2006 at 01:37:15PM +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.
>
> While I do think this proposal is much better than the previous
> non-existing proposal, it still doesn't address the problem of having
> the sunrise overlay hosted on a non *.gentoo.org address to make it
> 100% clear to the public that it is unsupported.
>
> Regards,
> Brix

So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if
you feel it will help anybody. I feel it's completely irrelevant, but
that's just me.


--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

On Sun, 11 Jun 2006 07:33:19 -0400
Peter <pete4abw@comcast.net> wrote:

> On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:
>
> > 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).
> >
>
> Um, there are numerous "new" not-in-portage-tree ebuilds submitted to
> bz which have been assigned to teams. However, they may still
> languish. They were assigned by the wranglers, and not improperly.
> Yet, for many reasons, the bugs wait. So, will there be a mechanism
> for a contributor to get an ebuild uploaded to sunrise in this
> circumstance?

What those bugs are waiting for is a dev to step up and agree to
maintain it. I don't see how sunrise improves that situation. The
only way such a bug will be resolved if no dev is interested, is if
someone who wants the package in the tree decides to become a dev - and
that means demonstrating technical ability, and sticking around (not
just dumping it in the tree then disappearing - in which case the
package would likely get removed after a while anyway due to lack of
maintenance).

> I would also suggest having some sort of review process for inclusion
> of m-n/m-w bugs. Some may not have any relevance (i.e. the program is
> no longer supported, or the upstream project has been incorporated
> into a new one, or the version of dated). Doing a blanket import of
> m-w bugs could make quite a mess of things IMO.
>
> One of the terrific benefits of sunrise will be the cleaning out of
> bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, I don't buy that. Having m-w/m-n packages in the sunrise
overlay cannot be sufficient to close the bugs in bugzilla. The bugs
get closed when the package gets maintenance support from a dev and is
put into the tree. Sunrise doesn't do anything to make that more
likely.

I also don't think that having large numbers of bugs open in bugzilla
is a problem. The search facilities are quite capable of giving you
focused lists of open bugs. If you don't want to see the bugs about
m-w/m-n ebuilds, filter them out of your search.

> Lastly, what about user contributions? Will users require some kind of
> sponsorship in order to have their ebuilds posted? What will the
> procedure be (or did I miss it in one of the hundreds of emails)?

This reflects back on the primary objection to sunrise on gentoo.org.
Your question is essentially, "who will take responsibility for it and
put it in the tree?". Sunrise might help in getting ebuilds to a decent
standard, and it might help some users to contribute, but it won't help
if no dev wants to take on maintainership of the package. That last
point is the only reason why m-w/m-n packages are not in the tree.

--
Kevin F. Quinn

Henrik Brix Andersen wrote:
> While I do think this proposal is much better than the previous
> non-existing proposal, it still doesn't address the problem of having
> the sunrise overlay hosted on a non *.gentoo.org address to make it
> 100% clear to the public that it is unsupported.

It's no more or less supported than anything else on
overlays.gentoo.org. The word "overlays" ought to be enough. I suppose
you oppose the whole concept, anyhow?

Thanks,
Donnie

On Sun, Jun 11, 2006 at 04:01:50PM +0200, Stefan Schweizer wrote:
> You need to ask a team member then to move them to maintainer-wanted.
> Usually the teams have no problem with moving bugs over to
> maintainer-wanted because they know that they cannot maintain everything
> themselves.

But Project Sunrise can? I'm sorry, but I believe you are
overestimating yourself...

Regards,
Brix
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

On Sun, Jun 11, 2006 at 09:43:01AM -0700, Donnie Berkholz wrote:
> It's no more or less supported than anything else on
> overlays.gentoo.org. The word "overlays" ought to be enough. I suppose
> you oppose the whole concept, anyhow?

No, I am certainly not opposed to overlays in general. I even maintain
my own public overlay of packages I work on in portage, an overlay I
consider moving to overlays.g.o when I have more time.

However, as has been pointed out several times in this thread already,
back when the devloper community agreed to the overlays project it was
also agreed that projects similar to what is now known as Project
Sunrise was not be present on overlays.gentoo.org. I believe this was
why many developers agreed to having the overlays project in the first
place. The idea was to have a central repository for the team and
developer specific overlays that already are available on
e.g. dev.gentoo.org. Overlays that are far more limited in contents
and where the ebuilds are written and reviewed by people who actually
know the packages in question.

Instead of following this consensus, the people behind Project Sunrise
choose to ignore this and went ahead and implemented the project -
without even presenting the idea to the developer community before
announcing it's presence to the world; perhaps thinking it would be
easier to get pardon than permission.

As I see it we have already agreed that an overlay of this type should
not be hosted on the overlays project back when the overlays project
was agreed upon. Yet a small number of developers ignored this and
implemented it anyhow behind the back of the rest of the developers,
disregarding their public stated oppinion. As this is a project that
has the potential of affecting the entire project I find this very
problematic.

Regards,
Brix
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henrik Brix Andersen wrote:
| However, as has been pointed out several times in this thread already,
| back when the devloper community agreed to the overlays project it was
| also agreed that projects similar to what is now known as Project
| Sunrise was not be present on overlays.gentoo.org.

Can you provide a reference to this, please? I've been through my -dev M/L
archive several times, and cannot find an email where I agreed to this.

Best regards,
Stu
- --
Stuart Herbert stuart@gentoo.org
Gentoo Developer http://www.gentoo.org/
~ http://blog.stuartherbert.com/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEjFivDC+AuvmvxXwRAungAKCejd72YGbpZ5bzFjtg2ezAu8XwswCeK2PP
GwYPr/RE79+j4iiZMbcA3zM=
=ZOKP
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Ryan Hill wrote:
>> 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.
>
> Would they be considered Gentoo staff, with everything that involves (quiz, etc)?

No, they are only given permission for the project. Becoming a gentoo
developer is a separate step and involves a full recruiting.
However, they need to do the normal ebuild quiz with one of the project
devs to be allowed to commit to the project overlay on their own.

>> 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.
>
> Would it also be useful to also have a keyword to indicate that the Sunrise
> ebuild has reached the point where it could be migrated to the gentoo repo if a
> maintainer for it steps up? I'm thinking that would make it easy to get a list
> of all m-w ebuilds that are ready for the tree. Maybe a page listing these
> packages would also be a good idea.

Okay so leave a comment on the bug for now and later on we can follow
your idea here and provide a "ready to move over list" as well, which
seems quite a good idea :)

Greetz,
Jokey

Stefan Schweizer schrieb:
> Marius Mauch wrote:
>
>> On Sat, 10 Jun 2006 13:37:15 +0200
>> Markus Ullmann <jokey@gentoo.org> 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).
>>> 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.
>> One more rule I'd like to see (should be obvious, but better to write
>> it down):
>>
>> People who commit to a certain project/ebuild have to be on the CC
>> list of the relevant bug report(s) and any important commits should be
>> documented on the bugs (including the revision of/link to the commit).
> I have not made it a rule yet to prevent whitespacing and updates for minor
> changes, also I would like to leave things like that to the people to
> decide to prevent that too many rules lock us in.
> How far would you want to go? Update for "I have removed some quotes" for "I
> have made a version bump"?

Functional changes, bugfixes, etc. Let people use common sense there.
The intention is simply that people watching the bug don't have to track
the overlay as well to get notifications of important changes (like a
bugfix that prevented them from using the ebuild previously).
Certainly you wouldn't consider whitespace changes or coding style
updates as an *important*, would you?

Marius
--
gentoo-dev@gentoo.org mailing list

On Sun, Jun 11, 2006 at 06:53:51PM +0100, Stuart Herbert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Henrik Brix Andersen wrote:
> | However, as has been pointed out several times in this thread already,
> | back when the devloper community agreed to the overlays project it was
> | also agreed that projects similar to what is now known as Project
> | Sunrise was not be present on overlays.gentoo.org.
>
> Can you provide a reference to this, please? I've been through my -dev M/L
> archive several times, and cannot find an email where I agreed to this.

Perhaps not in those exact words, I admit. But the general consensus
in my eyes, and I'm not alone with this view according to other
replies to this thread, was that the purpose of overlays.gentoo.org
would be to provide a common place to host project and developer
overlays - not a place to host Joe User's ebuild contributions (except
for users regularly contributing to specific teams/herds and
devs-in-spee). [1] [2] [3]

You could argue that Project Sunrise *is* a specific project. Fact is
that nobody at that time could predict that a small group of
developers would go ahead and create a project with the single goal of
providing Joe User's bugzilla-contributed ebuilds to end-users through
overlays.gentoo.org.

In my opinion, creating a new project with this purpose should not
have been allowed. I fear that perhaps creating the project was just
an attempt to circumvent the policy of overlays.gentoo.org, which
states that only project teams and individual Gentoo developers can
have an overlay on overlays.gentoo.org. It seems that the developers
who started Project Sunrise already planed to use overlays.gentoo.org
as a "free-for-all" overlay with no QA and policy checks back when the
idea of an official overlays project was discussed. [4] [5]

The security issues of having an official overlay of unsupported
ebuilds was also raised back then. [6] [7] [8] [9] [10] As was the
concerns about potential damage to the reputation of Gentoo as a
whole. [11] [12]

On the other hand, having team/herd specific overlays with commit
access from a select few end-users (as was written in the original
proposal) was seen as a good idea. [13] [14]

I've spent tonight reading through the entire thread that let to the
creation of the overlays project, and I still come out in the end with
the feeling that a consensus of having overlays.gentoo.org for hosting
the already existing developer and herd/team overlays in a central
place was reached. It also looks to me like the idea of having a
"free-for-all" or a user-contrib overlay hosted there would not be
acceptable due to security issues and risk of damaging the reputation
of Gentoo as a whole.

I know this doesn't provide solid evidence that this is how it was,
but truth is - we hardly ever see an email on the developers list
stating "This is what we agreed on". Due to the nature of the media we
tend to have a lot of input and discussion back and forth after which
a general consensus is found. This consensus, as I see it, is
reflected in the policy for overlays.gentoo.org. [15]

I urge people to read through the initial thread that fostered
overlays.gentoo.org as well - if only to refresh peoples memory on the
stuff that was discussed back then. You can start at
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09877.html

Sincerely,
Brix

[1]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09913.html
[2]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09921.html
[3]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09983.html

[4]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09962.html
[5]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09966.html

[6]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09918.html
[7]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09959.html
[8]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09884.html
[9]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09964.html
[10]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09963.html
[11]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09910.html
[12]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09946.html

[13]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09948.html
[14]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09972.html

[15]: http://www.gentoo.org/proj/en/overlays/policy.xml
--
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

On Sun, 2006-06-11 at 12:57 +0200, Jakub Moc wrote:
> Henrik Brix Andersen wrote:
> > On Sat, Jun 10, 2006 at 01:37:15PM +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.
> >
> > While I do think this proposal is much better than the previous
> > non-existing proposal, it still doesn't address the problem of having
> > the sunrise overlay hosted on a non *.gentoo.org address to make it
> > 100% clear to the public that it is unsupported.
> >
> > Regards,
> > Brix
>
> So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if
> you feel it will help anybody. I feel it's completely irrelevant, but
> that's just me.

Your feelings aren't really the question here. The relevance of this
request has been established by the users who have responded to this
thread and have mentioned how they feel about things on *.gentoo.org
infrastructure.

In this instance, it isn't a matter of the developers opinions.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

On Sun, 2006-06-11 at 07:33 -0400, Peter wrote:
> On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:
>
> > 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).
> >
>
> Um, there are numerous "new" not-in-portage-tree ebuilds submitted to bz
> which have been assigned to teams. However, they may still languish. They
> were assigned by the wranglers, and not improperly. Yet, for many reasons,
> the bugs wait. So, will there be a mechanism for a contributor to get an
> ebuild uploaded to sunrise in this circumstance?

No. If the ebuild belongs to a particular herd due to its function,
then the decision/responsibility should fully stay with the herd.

> One of the terrific benefits of sunrise will be the cleaning out of
> bugzilla. Nuking open bugs is an especially satisfying experience!

This project will not resolve a single bug. The bugs will remain open
until they are included in the main tree. As I have stated before, this
really solves nothing, it just migrates the "problem" to somewhere else
and causes a much larger support problem for developers.

> Lastly, what about user contributions? Will users require some kind of
> sponsorship in order to have their ebuilds posted? What will the procedure
> be (or did I miss it in one of the hundreds of emails)?

You missed it, though it really wasn't apparent anywhere. The project
will simple pick ebuilds that are "good enough" to go into the overlay.
They have made no mention of how this will occur, until the recent
posting of the "new" rules, which set the herd as the authority on what
goes into the overlay.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

On Mon, 2006-06-12 at 15:19 +0200, Stefan Schweizer wrote:
> All current contributors to the Sunrise overlay take effort to improve their
> ebuild skills and listen to our words closely. I would consider them all as
> devs-in-spee, I am personally planning to recruit some of them when they
> have reached a certain level of ebuild writing. They are all around in IRC
> (as noted in the [1]-mail by stuart you referenced).

Be sure you stay within the confines of the recruitment guidelines.
You've broken this one before, so I just want to point it out to you
again.

http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml#doc_chap2

Specifically, the last sentence of the second section...

"In addition, your project lead must be CC'd and must approve the bug
when it's filed to confirm that the project is accepting new
developers."

Example:
http://bugs.gentoo.org/show_bug.cgi?id=120232

Now, it happens that having Tupone on the team is a welcome (and
invaluable) addition to games, but we weren't ever really asked whether
we were recruiting. Nobody said anything, because we had already been
discussing internally on recruiting him, which you would have known were
you a member of the team at that time. Anyway, I'm just reminding you
to make sure that the team wants/needs help before you go recruiting
people for a team you're not even a member. It'll make things much
smoother and you'll get much less resistance.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

On Mon, 2006-06-12 at 15:19 +0200, Stefan Schweizer wrote:
> > 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.
> we are not doing this, because we do not want to put more work on teams that
> are overworked anyway. Everything that is assigned to maintainer-wanted in
> bugzilla means that it wants a maintainer and has no maintainer. If not, it
> would not have been assigned to maintainer-wanted. We are allowed to
> maintain packages that want a maintainer without asking anyone. Especially
> since we are removing the packages if any other herd shows interest.

This is actually factually incorrect. The maintainer-wanted alias has
become a dumping ground for any new package requests. In the past, the
packages were assigned via a "best guess" method to individual herds.

If it were possible to check the history of assignments easily in
bugzilla, you would see the very large numbers of bugs that get assigned
to maintainer-wanted that definitely belong to a specific team. A good
example is when someone posts a games-* ebuild to bugzilla, and it gets
assigned to maintainer-wanted. Now, the bug-wranglers catch most of
these and reassign them to us because we've requested it, but this isn't
the case for all of the teams/herds.

> > 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.
> There are teams that have made very clear that they are not interested in
> other people maintaining there packages. For example the games team does
> not assign any bugs to maintainer-wanted. It is obvious to every
> contributor that he cannot commit such packages, because they are not
> assigned to maintainer-wanted. However it is still possible to ask the games
> team to reassign the package to maintainer-wanted in order to get it into
> the sunrise overlay. Alternatively we help the contirbutor then to get the
> ebuild to quality so that the herd in question can commit it.

We don't do the assignments. We take them *from* maintainer-wanted
because we've found that maintainer-wanted is a dumping ground and
things get lost there.

I personally, not speaking for games anymore, think that
maintainer-wanted has been a failure and has contributed to the problem
more than it has helped. It was supposed to make things easier to
track. It hasn't.

I think a "middle ground" solution would be best. Assign the bug to the
herd/team that would most likely be the maintainer, and have
maintainer-wanted in CC. If the team doesn't want to maintain it, then
it gets assigned to maintainer-wanted and the team goes on CC. I'm not
saying that this doesn't happen. It does. It just doesn't happen
*consistently* which makes it less useful.

> I still do not get why there will be bugs generated?
> "Nevertheless the overlay ebuilds are mainly from users, thus being
> _unsupported_ and _experimental_"

A warning does not prevent bug reports. You should have been around
long enough by now to know that. ;]

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

Markus Ullmann wrote:
> 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.

A better solution is mentioned in the FAQ

--snip--
I want to see all the ebuilds in sunrise that affect my herd, is that
possible?

Yes, we have hacked up a script in scripts/create-stats.sh for the moment,
that will give you all packages, bugs and CC:

sys-auth/pam_skey - bug 55279 - on CC: jakub pam-bugs taviso
maintainer-wanted

You might want to run it with your herd or maintainer as argument to get
filtered output:

scripts/create-stats.sh pam-bugs

--snap--

If there is real interest in subdirs for other reasons than listing packages
by herds I would like to hear them. For the moment we are still discussing
everything as mentioned on the wiki:

"WARNING: This is currently under creation and review - fundamental changes
may still take place"

Please work with us in IRC to make it please everyone.

- Stefan

--
gentoo-dev@gentoo.org mailing list

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.

Nice, I think this is a great improvement.

> 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.

Would they be considered Gentoo staff, with everything that involves (quiz, etc)?

> 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.

Would it also be useful to also have a keyword to indicate that the Sunrise
ebuild has reached the point where it could be migrated to the gentoo repo if a
maintainer for it steps up? I'm thinking that would make it easy to get a list
of all m-w ebuilds that are ready for the tree. Maybe a page listing these
packages would also be a good idea.

--de.

Marius Mauch wrote:

> On Sat, 10 Jun 2006 13:37:15 +0200
> Markus Ullmann <jokey@gentoo.org> 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).
>
>> 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.
>
> One more rule I'd like to see (should be obvious, but better to write
> it down):
>
> People who commit to a certain project/ebuild have to be on the CC
> list of the relevant bug report(s) and any important commits should be
> documented on the bugs (including the revision of/link to the commit).
I have not made it a rule yet to prevent whitespacing and updates for minor
changes, also I would like to leave things like that to the people to
decide to prevent that too many rules lock us in.
How far would you want to go? Update for "I have removed some quotes" for "I
have made a version bump"?
Currently it is written down as follows:

http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit, point 6
--snip--
6) For later updates to the package in the overlay it is still considered
good style to update the bug and link to the changes, for exmaple:

I added some sed calls, it should build with --as-needed now
http://overlays.gentoo.org/svn/proj/sunrise/sys-apps/openguru/openguru-1.ebuild
--snap--
I think it should be at least changed from a suggestion to a "you need to
for updates of .."
So,, my question, how far do you want them to go here?

- Stefan


--
gentoo-dev@gentoo.org mailing list

On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote:

> 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).
>

Um, there are numerous "new" not-in-portage-tree ebuilds submitted to bz
which have been assigned to teams. However, they may still languish. They
were assigned by the wranglers, and not improperly. Yet, for many reasons,
the bugs wait. So, will there be a mechanism for a contributor to get an
ebuild uploaded to sunrise in this circumstance?

I would also suggest having some sort of review process for inclusion of
m-n/m-w bugs. Some may not have any relevance (i.e. the program is no
longer supported, or the upstream project has been incorporated into a new
one, or the version of dated). Doing a blanket import of m-w bugs could
make quite a mess of things IMO.

One of the terrific benefits of sunrise will be the cleaning out of
bugzilla. Nuking open bugs is an especially satisfying experience!

Lastly, what about user contributions? Will users require some kind of
sponsorship in order to have their ebuilds posted? What will the procedure
be (or did I miss it in one of the hundreds of emails)?

--
Peter


--
gentoo-dev@gentoo.org mailing list

Peter wrote:
> Um, there are numerous "new" not-in-portage-tree ebuilds submitted to bz
> which have been assigned to teams. However, they may still languish. They
> were assigned by the wranglers, and not improperly. Yet, for many reasons,
> the bugs wait. So, will there be a mechanism for a contributor to get an
> ebuild uploaded to sunrise in this circumstance?

You need to ask a team member then to move them to maintainer-wanted.
Usually the teams have no problem with moving bugs over to
maintainer-wanted because they know that they cannot maintain everything
themselves.


> I would also suggest having some sort of review process for inclusion of
> m-n/m-w bugs. Some may not have any relevance (i.e. the program is no
> longer supported, or the upstream project has been incorporated into a new
> one, or the version of dated). Doing a blanket import of m-w bugs could
> make quite a mess of things IMO.
This is volunteers work and usually volunteers are only moving over the
ebuilds they use themselves. We are not doing this in a general way, but on
a per-user per-package basis. We do not plan to run any importing scripts.
It will only be done if a user or developer is interested in it :)

> One of the terrific benefits of sunrise will be the cleaning out of
> bugzilla. Nuking open bugs is an especially satisfying experience!

Sorry, we are not doing this. We are assigning a bug to every sunrise ebuild
to make sure that it can be discussed there and is still easily searchable.
>
> Lastly, what about user contributions? Will users require some kind of
> sponsorship in order to have their ebuilds posted? What will the procedure
> be (or did I miss it in one of the hundreds of emails)?

see 5) from Markus' email. You just need to have a good ebuild contribution
that we can review with you, You will not gain full access but it is a
start.

- Stefan

--
gentoo-dev@gentoo.org mailing list

Dan Meltzer wrote:
> On 6/10/06, Markus Ullmann <jokey@gentoo.org> wrote:
>> 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.
>>
>
> If its unofficially part of a herd, then isn't it no longer a m-w/m-n
> ebuild?

I think you are right, see my answer to the threadstarter to find a solution
that works without subdirs.


> I think this is a much improved//thought out version of the proposal.
> From the looks of things sunrise should never make it to layman
> however, because as we all know, anything that makes things more
> easily accessible to users is going to be (mis)used by more of them.
> From what I understand, you see Sunrise as an overlay for users to
> improve their ebuilds because they are insufficient quality to be in
> the main tree. If they are of this poor quality, they should be no
> where near users hands, this doesn't make sense.

We will yet have to see if quality will be that bad. I want some more time
to see how the ebuild quality works out before we make it more publically
available.

> If on the other hand you saw sunrise as a way for more packages to be
> available to users due to there being a lack of maintainers, asking
> herds to check out ebuilds as part of the proposal seems
> counterproductive to the cause.

They do not have to. It is just nice to let us know that they would like to
see a package in sunrise.

> Maybe you should expand on the goal of the sunrise project, what
> exactly do you want it to do?
The Sunrise Project goals may change, it is not yet running long enough to
know about all the effects and the goals. Because of this, I cannot give
you an "exact" definition now, sorry.

our goals include for example:
- encourage users to write ebuilds
- get new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better

I think these are working out quite well currently, I hope it helps you.

Regards,
Stefan

--
gentoo-dev@gentoo.org mailing list

Thanks, I have worked in your ideas and made the +CC and bug-updates clear
in the HOWTO.

Kind regards,
Stefan

--
gentoo-dev@gentoo.org mailing list