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
