1 |
On Thu, Feb 11, 2016 at 3:15 PM, Patrick Lauer <patrick@g.o> wrote: |
2 |
> |
3 |
> Please, next time someone has the brilliant idea of changing stuff just |
4 |
> to change it (I still don't see a reason why we had to change |
5 |
> metadata.xml?), it should be required that support tools are fixed |
6 |
> *before* the change, and working versions released. This avoids grumpy |
7 |
> people and makes it harder for those that change things to head-in-sand |
8 |
> and claim everything works as expected when it obviously doesn't. |
9 |
> |
10 |
|
11 |
A few comments: |
12 |
This change has been a long time in the making, with plenty of notice. |
13 |
It even went through the formal GLEP process. It isn't like there |
14 |
wasn't ample notice. |
15 |
|
16 |
If we didn't allow anybody to make any change without taking upon |
17 |
themselves the responsibility to fix any tool anybody had created that |
18 |
would be affected, then nobody would change anything, and we'd be |
19 |
reduced to bitrot. If anything I think the rate of change in Gentoo |
20 |
is probably a bit low. I don't propose changing things for the sake |
21 |
of change, but contributors should feel free to propose changes and |
22 |
not expect that they will have to shoulder 100% of the burden of |
23 |
completely supporting those changes. |
24 |
|
25 |
It is far more reasonable to provide notice of change, and then the |
26 |
onus is on those who want specific tools to work to fix them. If |
27 |
there is a concern that more time is needed/etc this could be raised |
28 |
with the council before the change. I'm sure if the eudev maintainers |
29 |
had raised a concern at any point the council would have worked with |
30 |
them. |
31 |
|
32 |
Ultimately, the only way anybody can be assured that their favorite |
33 |
Gentoo tool will work in a year is if they're maintaining it. It |
34 |
sounds like nobody was really paying attention to it, which is why |
35 |
nobody noticed that it was going to break. |
36 |
|
37 |
-- |
38 |
Rich |