Mailing List Archive

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

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

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

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.