[gentoo-dev] Project Sunrise -- Proposal

[gentoo-dev] Project Sunrise -- Proposal

[Markus Ullmann]

[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]

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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Stefan Schweizer]

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

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Dan Meltzer]

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

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

[Daniel Ostrow]

[-- Attachment #1: Type: text/plain, Size: 8746 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Stefan Schweizer]

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

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

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Peter]

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

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

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Stefan Schweizer]

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

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

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Stuart Herbert]

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

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

[Stefan Schweizer]

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

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

[Markus Ullmann]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Marius Mauch]

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

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

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

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

[Stefan Schweizer]

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

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Stefan Schweizer]

Daniel Ostrow wrote:
>> 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. 
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.

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

> For those teams in between an OK per 
> package sought by the sunrise project's team members is needed. 
Sorry, I think you are trying to kill our project with red tape. I do not
think it helps anyone to do more work.

> I'm 
> sorry but the leg work to track this stuff and get acceptance has to be
> 100% on your projects head. 
Yes, it is currently. We are not requiring anyone else to take any action!
You are proposing to ask, that would generate a huge bugspam and require
many people to take action. We do not want that, sorry.

> Your proposal adds a need for me to actually 
> look at bugs for packages that I may have no interest in. 
no, absolutely not. You do not need to look at any bugs, in fact you are not
required to do anything for sunrise. We are just proposing it might be good
to give us a hint when you have a package that should be added to the
sunrise overlay.

> I don't pay 
> any attention to maintainer-wanted now I don't want to pay any attention
> to a subset of that ever.
That is good, and you do not need to. Why do you think that you would need
to do that?


>> 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.
I still do not get why there will be bugs generated?
"Nevertheless the overlay ebuilds are mainly from users, thus being
_unsupported_ and _experimental_"

> 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.
Sorry, I think you are drawing a very unlikely situation here. If such thing
ever happens (a library that can be used by in-tree ebuilds) we will of
course add that to the tree. It is not our nor anyone else's intention to
break the tree.
Also the same can happen for in-tree libraries that are not ppc64 and even
for libraries that are from a third party overlay not controlled by gentoo.
It is far better to have as much as possible on gentoo hardware because
breakages can be fixed there in contrast to third party overlays. Yes, I
have been bitten by that before, I tried to contact a third party overlay
but they did not answer and thus it still breaks or overwrites the tree.

Reduce uncontrollable overlays by providing a controllable overlay!

> 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.
There is also no way for in-tree ebuilds to ensure that, sorry. We cannot fo
farther than the tree.


> 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.
Yes, your concerns are valid there. Upon import into the tree all keywords
will be reset of course. Really, keywording is not that much a goal of
sunrise, it should happen after the package has been added to the tree.

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


>> 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. 
We offer the best we have. Yes, doing this fully right with all the people
you are talking about is hard, but doing something that is better than what
we currently have, overlays all around in the web with absolutely no
control of gentoo nor the ability to contact them, is needed.

We are not claiming that we have all the security and QA in place. We just
meet certain standards(repoman,dev-review) and we can be contacted easily
and can react when there are problems. That makes us different from BMG.

> At the 
> moment I know of you and genstef, and again not meaning this as a dig,
> but that is nowhere near enough.
we have the support in #gentoo-dev-help in place, and it is a good resource
for ebuild questions and review. The channel is not only frequently visited
by myself and jokey, there are also some other developers who care to help
users with writing ebuilds.

> 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.
They are already made more useable all around the web without any gentoo
involvement. The point is to make them more useable with developer review,
to control them and to make sure that there are no obvious bugs. I have
seen reports in the forums about unofficial overlays, I think it is better
to be able to fix breakage instead of exposing users to it.

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

I do not see any burden we place on other developers. Sorry, I miss that
point. I see it more easy to fix contributed packages and thus take away
the burden of continual not-working reports from external overlays.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

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

[Stefan Schweizer]

Henrik Brix Andersen wrote:
> 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]
I think you misunderstand the Sunrise Project. I will tell you why the
Sunrise Project in fact complies to all these rules.

It only hosts ebuilds that have been reviewed by Gentoo developers or
directly committed by "regular contributors" that have taken the ebuild
quiz, we name them "trusted committers". We have not yet fleshed out how it
works, but believe me we are watching the quality of the overlay and we
certainly will not let it rot.
You believe we do not have the manpower for this as you have stated in many
other threads. But currently we are coping well with the ebuild submissions
we get. Additionally #gentoo-dev-help is of big help for us.
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).

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

The Sunrise overlay hosts many ebuilds that do not have a herd in CC. It
also hosts ebuilds for herds that do not have their own overlay or are not
interested in recruiting new contributors. Herds who wish to work with the
contributor in a different way are already doing that, and we encourage
people to use existing herd/team-specfic infrastructure if there is one.

Quote from the FAQ
--Can I commit everything I like to the overlay?--
Herds could also have a better official overlay for herd related packages.
For example you should not add packages from the PHP overlay or concerning
PHP to the Sunrise overlay, rather ask for access to the PHP or Webapps
overlay and talk to those herds first, depending on where you feel your
package should go.
-------
The Sunrise project catches all ebuilds that a specific herd does not have
the resources or interest in catching. We make sure that contributions have
a certain level of QA and are not ignored. As soon as a specific herd/team
wants to work on the ebuilds themselves we remove the ebuild from the
Sunrise overlay.

Our single goal is not to provide Joe User's ebuilds, we have more goals:
- provide a central home for contributed ebuilds that do not (yet) find a
place in the portage tree
- encourage users to write ebuilds
- find new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better
Those are also mentioned on our Project Page[1] 

> In my opinion, creating a new project with this purpose should not
> have been allowed. 
In what other form should we do something like this in your opinion. Should
we be recruiters or mentors? I think creating a project and listening to
and working in the many comments on the mailing lists was a good idea.

> 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.
Sorry, how are we circumventing the policy? We want an overlay where more
than one person (me and jokey and the users) work together on improving
ebuilds. This is not sensible to do in a developer overlay. We need a
project overlay.

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

You are making two assumptions("free-for-all" and no QA) that are no longer
true. Those may have been true with the initial announcement but we have
seen that the Gentoo developer community has good points and that it
actually works better when we educate people and have all ebuilds reviewed
by Gentoo developers. It is only accessible for people who want to commit
something and it is only fully accessible when they have taken the ebuild
quiz. Sure everyone can come and help, but I see this policy as being more
strict and quality-assuring than what is currently done in the project
overlays currently.


> 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]
These comments mostly ignore the fact, that we have QA in place now,
everything must be reviewed by gentoo developers. And that the ebuild is
_not_ free-for-all, it is only open to people who stick to the rules. We
are just actively encouraging people to help and improve their ebuild
skills by helping, not giving access out blindly.

> 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]
Yes, we are giving commit access only to people who have something to
contribute! In fact we are no different from any other herd/team overlay
just that we have QA (review), good HOWTOs and actively encourage people to
come to us and get our advice and offer their help.


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

The overlay has been running for some days and I have not seen any "security
issues" or damage to our reputation. I am always checking the changes to
the overlay and reviewing user ebuilds. Sorry, that needs to be proven. I
am argueing that this is not the case with our current review process.

But you have a valid security point and I am thinking about putting up
signed tarballs of a revision where all commits are reviewed.

> 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]
That is what Stuart meant in his mail - it is not forbidden to create a new
project just for recruiting and supporting new people that are eager to
help. I think this helps gentoo as a whole and in fact helps our reputation
as a community distribution which is open for new developers.

> 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
just the project page from me :)

[1] http://www.gentoo.org/proj/en/sunrise

Really I appreciate your effort, but it could be much more wisely used in
pointing out to us what is not sensible in our goals and policies. I would
really love to make this project a success and acceptable to you, and
throwing the same arguments at each other won't help in making it
successfull.
Please, please work with us instead of against us - really, working together
is one of the essential parts of Gentoo and I fear it is forgotten more
often recently.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 3318 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Stefan Schweizer]

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

Chris Gianelloni wrote:
> On Mon, 2006-06-12 at 15:19 +0200, Stefan Schweizer wrote:
> You've broken this one before, so I just want to point it out to you
> again.
The bug was of course discussed in IRC with the games team and the lead in
advance. I wonder why no one of the recruiters insisted in this important
step and added the team lead to CC. Anyway, I am sorry for not adding the
team lead explicitly to CC, my excuses, this breach of policy was not
intended.

> 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.
Thank you very much :)
But imo contributors who aim to join a specific team are usually recruited
within that team. Usually there are specific project overlays then.
Currently it looks like sunrise-users would join without becoming part of a
team.

Very valuable comment indeed, thanks. I will take that into account when I
file my next recruiting-bug.

- - Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEjYdONJowsmZ/PzARAr01AKCE9DJPPfd65W4zCFjmXYUw1KGIqgCZATFg
5IoKFUahr3E+DHAyDGju9a0=
=aN5C
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Marius Mauch wrote:

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

Could this be automated through a post-commit hook in SVN?  I'm thinking of
something like the GCC bugzilla, which adds a comment to the relevant bug
whenever a checkin is made.

eg. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601

--de.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]