1 |
Daniel Ostrow wrote: |
2 |
>> 3) a yes from herds required, keeping a timeout to avoid bugspam |
3 |
>> |
4 |
>> after a comment has been placed on a maintainer-wanted bug in bugzie, |
5 |
>> there's a grace time of two weeks for herds to either leave a comment on |
6 |
>> whether they're fine with take over or not. When this time is over and |
7 |
>> it is assigned to maintainer-wanted, then and only then it is implied as |
8 |
>> an OK to keep it also in the sunrise project. |
9 |
> |
10 |
> I'm 100% against implicit acceptance. If someone from the sunrise |
11 |
> project wishes to add an ebuild to the overlay they should have to get |
12 |
> an explicit OK from the team in question. |
13 |
we are not doing this, because we do not want to put more work on teams that |
14 |
are overworked anyway. Everything that is assigned to maintainer-wanted in |
15 |
bugzilla means that it wants a maintainer and has no maintainer. If not, it |
16 |
would not have been assigned to maintainer-wanted. We are allowed to |
17 |
maintain packages that want a maintainer without asking anyone. Especially |
18 |
since we are removing the packages if any other herd shows interest. |
19 |
|
20 |
> The sunrise project could of |
21 |
> course keep a list of teams that have given a blanket OK and of those |
22 |
> that have totally opted out. |
23 |
There are teams that have made very clear that they are not interested in |
24 |
other people maintaining there packages. For example the games team does |
25 |
not assign any bugs to maintainer-wanted. It is obvious to every |
26 |
contributor that he cannot commit such packages, because they are not |
27 |
assigned to maintainer-wanted. However it is still possible to ask the games |
28 |
team to reassign the package to maintainer-wanted in order to get it into |
29 |
the sunrise overlay. Alternatively we help the contirbutor then to get the |
30 |
ebuild to quality so that the herd in question can commit it. |
31 |
|
32 |
> For those teams in between an OK per |
33 |
> package sought by the sunrise project's team members is needed. |
34 |
Sorry, I think you are trying to kill our project with red tape. I do not |
35 |
think it helps anyone to do more work. |
36 |
|
37 |
> I'm |
38 |
> sorry but the leg work to track this stuff and get acceptance has to be |
39 |
> 100% on your projects head. |
40 |
Yes, it is currently. We are not requiring anyone else to take any action! |
41 |
You are proposing to ask, that would generate a huge bugspam and require |
42 |
many people to take action. We do not want that, sorry. |
43 |
|
44 |
> Your proposal adds a need for me to actually |
45 |
> look at bugs for packages that I may have no interest in. |
46 |
no, absolutely not. You do not need to look at any bugs, in fact you are not |
47 |
required to do anything for sunrise. We are just proposing it might be good |
48 |
to give us a hint when you have a package that should be added to the |
49 |
sunrise overlay. |
50 |
|
51 |
> I don't pay |
52 |
> any attention to maintainer-wanted now I don't want to pay any attention |
53 |
> to a subset of that ever. |
54 |
That is good, and you do not need to. Why do you think that you would need |
55 |
to do that? |
56 |
|
57 |
|
58 |
>> 6) QA assurance |
59 |
>> |
60 |
>> Of course there are minor issues with the ebuilds, otherwise they could |
61 |
>> be committed straight forward. Important thing is that it only finds the |
62 |
>> way into overlaye if the trusted committers (project devs and users who |
63 |
>> are given permission explicitely, see above) are fine with it. |
64 |
>> Additional note on arch issues: initially, just ~x86 and ~amd64 may be |
65 |
>> set. The rest would need successful test reports for other ~arch |
66 |
>> keywords. Stable keywording isn't permitted at all, there will be some |
67 |
>> automated check to make sure no one does it (by accident) here. |
68 |
>> |
69 |
>> Additional note: we won't start adding this to layman and making it |
70 |
>> available easier until the QA checks have been implemented. |
71 |
> |
72 |
> Erm...no! See that is the thing about item #1 on my list...there is |
73 |
> nothing preventing Joe User from checking out the overlay and adding say |
74 |
> a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs |
75 |
> *will* be generated for arch teams for packages that are not in the |
76 |
> tree. |
77 |
I still do not get why there will be bugs generated? |
78 |
"Nevertheless the overlay ebuilds are mainly from users, thus being |
79 |
_unsupported_ and _experimental_" |
80 |
|
81 |
> Also note I'm not talking necessarily about the "Hey, I installed |
82 |
> ${package} and it broke." bugs because if ${package} isn't in the tree |
83 |
> bug-wranglers can catch it and off you go...the arch teams aren't |
84 |
> involved. What I am talking about is "Hey, my ppc64 started doing weird |
85 |
> things yesterday, ${daemons} are no longer working." having that bug |
86 |
> assigned to the arch team, and then spending a long time only to track |
87 |
> down that the user installed some random library from sunrise seven days |
88 |
> ago and there just happened to be upgrades to programs that took |
89 |
> advantage of said library in unexpected ways. |
90 |
Sorry, I think you are drawing a very unlikely situation here. If such thing |
91 |
ever happens (a library that can be used by in-tree ebuilds) we will of |
92 |
course add that to the tree. It is not our nor anyone else's intention to |
93 |
break the tree. |
94 |
Also the same can happen for in-tree libraries that are not ppc64 and even |
95 |
for libraries that are from a third party overlay not controlled by gentoo. |
96 |
It is far better to have as much as possible on gentoo hardware because |
97 |
breakages can be fixed there in contrast to third party overlays. Yes, I |
98 |
have been bitten by that before, I tried to contact a third party overlay |
99 |
but they did not answer and thus it still breaks or overwrites the tree. |
100 |
|
101 |
Reduce uncontrollable overlays by providing a controllable overlay! |
102 |
|
103 |
> The *only* way you can avoid dumping that sort of stuff onto the arch |
104 |
> teams is to have the expertise in house. Otherwise a VERY BAD habit will |
105 |
> form. Dev A looks at a bug, sees the sunrise overlay listed in emerge |
106 |
> --info and before looking even an iota further will assign it to the |
107 |
> sunrise project because who knows the problem *may* have come from some |
108 |
> unknown ebuild there and there is *no* way to know without a lot of |
109 |
> potentially wasted time. This *will* lower the quality of the |
110 |
> distribution as a whole. So...nope I don't accept the stipulation that |
111 |
> it will only be ~amd64 and ~x86 for now because there is no way you can |
112 |
> keep it that way once it hits the users machine. |
113 |
There is also no way for in-tree ebuilds to ensure that, sorry. We cannot fo |
114 |
farther than the tree. |
115 |
|
116 |
|
117 |
> I also strenuously object to the addition of other keywords without |
118 |
> someone on the sunrise project who can verify the reports validity. This |
119 |
> means by the way, having access to the arch yourself *and* having enough |
120 |
> understanding of the package and the arch to be able to keyword...for |
121 |
> the main tree we call this being an arch team member. |
122 |
Yes, your concerns are valid there. Upon import into the tree all keywords |
123 |
will be reset of course. Really, keywording is not that much a goal of |
124 |
sunrise, it should happen after the package has been added to the tree. |
125 |
|
126 |
> Above and beyond that until QA checks that meet or exceed the main |
127 |
> tree's standards are in place...don't bother. |
128 |
agreed. |
129 |
|
130 |
|
131 |
>> 9) Security |
132 |
>> |
133 |
>> In this early stage we have no security liaison on board yet. If one is |
134 |
>> willing to help out here, we'd be more than glad on welcoming him :) |
135 |
> |
136 |
> And until you do...don't bother. |
137 |
> |
138 |
> Thanks for going over what I put out there but there is still a good |
139 |
> ways to go. I hope you see from my statements above that part of what |
140 |
> I'm getting at is it'll take *many many* devs to do this right. |
141 |
We offer the best we have. Yes, doing this fully right with all the people |
142 |
you are talking about is hard, but doing something that is better than what |
143 |
we currently have, overlays all around in the web with absolutely no |
144 |
control of gentoo nor the ability to contact them, is needed. |
145 |
|
146 |
We are not claiming that we have all the security and QA in place. We just |
147 |
meet certain standards(repoman,dev-review) and we can be contacted easily |
148 |
and can react when there are problems. That makes us different from BMG. |
149 |
|
150 |
> At the |
151 |
> moment I know of you and genstef, and again not meaning this as a dig, |
152 |
> but that is nowhere near enough. |
153 |
we have the support in #gentoo-dev-help in place, and it is a good resource |
154 |
for ebuild questions and review. The channel is not only frequently visited |
155 |
by myself and jokey, there are also some other developers who care to help |
156 |
users with writing ebuilds. |
157 |
|
158 |
> The bugs are languishing because there are not enough devs to maintain |
159 |
> them and/or not enough interest in them. Making them more usable without |
160 |
> a nearly identical support structure to the main tree will not make the |
161 |
> social problem go away, it'll just introduce many new weird technical |
162 |
> problems into an already overburdened equation. |
163 |
They are already made more useable all around the web without any gentoo |
164 |
involvement. The point is to make them more useable with developer review, |
165 |
to control them and to make sure that there are no obvious bugs. I have |
166 |
seen reports in the forums about unofficial overlays, I think it is better |
167 |
to be able to fix breakage instead of exposing users to it. |
168 |
|
169 |
> I understand the desire to use this as a facility to "train-up" new devs |
170 |
> but I'm frankly flabbergasted that you seem to overlook the potentially |
171 |
> huge burden this will place on the rest of the developer community until |
172 |
> such time as each and every package in sunrise is in the main tree with |
173 |
> a maintainer. In the long run things may get a little better, in the |
174 |
> short run there is a very large potential for things to get *much* |
175 |
> worse. |
176 |
|
177 |
I do not see any burden we place on other developers. Sorry, I miss that |
178 |
point. I see it more easy to fix contributed packages and thus take away |
179 |
the burden of continual not-working reports from external overlays. |
180 |
|
181 |
Regards, |
182 |
Stefan |
183 |
|
184 |
-- |
185 |
gentoo-dev@g.o mailing list |