| 1 |
On Mon, Jul 1, 2013 at 5:32 AM, Chí-Thanh Christopher Nguyễn |
| 2 |
<chithanh@g.o> wrote: |
| 3 |
> Rich Freeman schrieb: |
| 4 |
>> If a maintainer just hates having foo-1.2 in the tree because they put |
| 5 |
>> foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we |
| 6 |
>> already require them to wait until 1.3 can be stabilized (perhaps |
| 7 |
>> rapidly if a security issue). Maintainers already must coordinate |
| 8 |
>> with other projects. |
| 9 |
> |
| 10 |
> I did not say that maintainers can ignore policy. The removal of ebuilds |
| 11 |
> must follow certain rules which are set in policy. |
| 12 |
|
| 13 |
IMO this really doesn't say anything at all. Of course maintainers |
| 14 |
have to follow policy. The question is what should the policy be? |
| 15 |
The original question was whether we should be forking or splitting |
| 16 |
packages over adding single files when the maintainer doesn't want |
| 17 |
them in the original package. Right now we have no explicit policy |
| 18 |
governing this. |
| 19 |
|
| 20 |
I don't think it necessarily needs to be written down, but if people |
| 21 |
are going to refuse to cooperate using the lack of something written |
| 22 |
down as an excuse and devrel feels that they can't do anything about |
| 23 |
it in the absence of a written policy, then we'll need a new policy. |
| 24 |
I think the policy should basically amount to requiring devs to |
| 25 |
coordinate with maintainers, but that maintainers can not outright |
| 26 |
block well-supported project-related work without Council approval. |
| 27 |
Also, policy would be that anybody can become a maintainer of any |
| 28 |
package, but they're responsible for their actions and maintainers |
| 29 |
must coordinate. |
| 30 |
|
| 31 |
I don't think we need rules for everything. However, if the lack of a |
| 32 |
policy is causing paralysis then a policy should be created. That |
| 33 |
said, this might be a moot issue - the only Dev to really be vocal |
| 34 |
about blocking such changes asked to retire a week or two ago over |
| 35 |
this very debate. I'd probably wait until a real issue comes up, but |
| 36 |
I would not take my time about dealing with it (announce an immediate |
| 37 |
case-by-case decision and then write up a GLEP/etc over the next few |
| 38 |
weeks). |
| 39 |
|
| 40 |
> |
| 41 |
> With x32 specifically, a number of people including some upstreams think |
| 42 |
> that the whole concept is a bad idea. A case could be made for patches |
| 43 |
> that #ifdef x32 and which compile to a no-op on other arches, but even |
| 44 |
> those must be maintained. What if the patch no longer applies after a |
| 45 |
> version bump? |
| 46 |
|
| 47 |
Well, since I'm only talking about WELL-SUPPORTED project-related |
| 48 |
work, just ask the project team to fix the patch. If they don't in a |
| 49 |
reasonable timeframe, then it isn't well-supported and the maintainer |
| 50 |
can do whatever they want with it. Project teams should only take on |
| 51 |
patches if they think they can sustain them. Most likely for |
| 52 |
something like x32 they'd only do it for strategic packages anyway |
| 53 |
(toolchain, etc). |
| 54 |
|
| 55 |
This is no different than requiring arch teams to operate in a timely |
| 56 |
manner/etc. If a project is getting out of hand Maintainers can talk |
| 57 |
to the lead, and bring it to Council if necessary. |
| 58 |
|
| 59 |
Honestly, I think an issue here is that some would like Gentoo to |
| 60 |
slowly transform into a retirement community where nobody wants cars |
| 61 |
driving on the road after 7PM. I see Gentoo as a place where people |
| 62 |
can do things that are new and exciting, and yet still run a |
| 63 |
traditional system. For end users I want to contain disruption, and |
| 64 |
for maintainers I want to coordinate disruption, but if we want to be |
| 65 |
a place where innovation happens, disruption is going to be there. |
| 66 |
Advocates for disruptive changes should be required to properly |
| 67 |
coordinate and support these changes, but they should not be at the |
| 68 |
mercy of individuals who want to block these changes. |
| 69 |
|
| 70 |
> |
| 71 |
>> I've been in the place of having somebody come along and bump an EAPI |
| 72 |
>> on me or make other changes that I'd honestly have been more |
| 73 |
>> comfortable taking my time with. |
| 74 |
> |
| 75 |
> That's great, and I encourage all developers to allow this too. But I am |
| 76 |
> against forcing anybody. |
| 77 |
|
| 78 |
I'm not going to force anybody to do anything they don't already have |
| 79 |
to do. I'm just not going to let them stand in the way. I think |
| 80 |
there is a balance, but right now we're moving too far in the |
| 81 |
direction of treating packages as the personal property of |
| 82 |
maintainers, and that needs adjustment. It is certainly possible to |
| 83 |
move too far in the other direction, and perhaps our current situation |
| 84 |
is the result of over-reaction to these kinds of problems in the past |
| 85 |
(devs running scripts against the tree and such). |
| 86 |
|
| 87 |
Rich |
Archives