1 |
Alas, I couldn't attend the council meeting in-person, but it seems |
2 |
like council missed the point of my request RE commits against |
3 |
maintainer wishes (or maybe not - if so I'll happily shut up as far as |
4 |
persuading the council goes). That said, I expressed it as a general |
5 |
request in the hope to not have something systemd-specific, and it |
6 |
sounds like that is not desired. |
7 |
|
8 |
Picking just a single quote that I think gives the sense of the discussion: |
9 |
|
10 |
<11.06.2013 19:10> <@Betelgeuse> Still I don't think policies |
11 |
necessary need adjusting |
12 |
<11.06.2013 19:10> <@Betelgeuse> If you need something system wide |
13 |
with opposition then ask council on a case by case basis |
14 |
|
15 |
So, what we need system-wide with clearly stated opposition on -dev is |
16 |
permission to add unit files to individual packages when the package |
17 |
maintainer doesn't want this done. |
18 |
|
19 |
I'd ask that the council consider explicitly permitting this. If not |
20 |
you're just going to get an agenda item for specific exceptions for |
21 |
the 10 packages that the maintainer blocked adding units to that |
22 |
particular month. Either that or you'll see 10 new packages with |
23 |
co-maintainers where the two maintainers are in complete disagreement, |
24 |
or the one who actually cares about the package and not the unit file |
25 |
quits and the package stagnates as a result. Nobody needs council |
26 |
permission under the current policies to become a co-maintainer. I |
27 |
really see this as a case where lack of direction from above is just |
28 |
going to lead to a lot of fighting at the ground level. |
29 |
|
30 |
If the council isn't willing to make policy regarding adding units to |
31 |
packages, just where do they expect them to go? |
32 |
|
33 |
Rich |