| 1 |
On Wed, May 15, 2013 at 2:11 PM, Tom Wijsman <TomWij@g.o> wrote: |
| 2 |
> On Wed, 15 May 2013 13:25:11 -0400 |
| 3 |
> Rich Freeman <rich0@g.o> wrote: |
| 4 |
> |
| 5 |
>> In any case, there really isn't any "decision" to make here. |
| 6 |
> |
| 7 |
> Then for what purpose is this discussion still going on? |
| 8 |
> |
| 9 |
|
| 10 |
No comment on that... |
| 11 |
|
| 12 |
Maybe another way of saying things is that really the onus is on those |
| 13 |
who want others to change their behavior to explain why they should |
| 14 |
change. So, if you're seeking a change in behavior be up-front about |
| 15 |
what change you want. If you're not seeking a change in behavior, |
| 16 |
then there really isn't much point in going on unless it is to resist |
| 17 |
a proposed change. |
| 18 |
|
| 19 |
Personally I think a reasonable balance is: |
| 20 |
|
| 21 |
1. Maintainers do not have to take initiative to create systemd |
| 22 |
units. (status quo) |
| 23 |
2. Maintainers should accept contributed units from the community, |
| 24 |
even if they can't personally test them. This can be done at their |
| 25 |
convenience. (slight addition in work for maintainers) |
| 26 |
3. Maintainers can ask users to contribute units upstream if not |
| 27 |
already done. I don't think this should be a hard requirement (ie |
| 28 |
accepting a non-upstreamed unit is not a QA violation). If upstream |
| 29 |
makes this difficult this should not be an excuse for marking bugs |
| 30 |
invalid. The goal is to work with upstream, not harass them. (some |
| 31 |
more work for bug submitters and maintainers). |
| 32 |
|
| 33 |
Bottom line - maintainers don't have to go out of their way to support |
| 34 |
systemd, but they should be friendly facilitators when others are |
| 35 |
willing to do the work. This is no different from accepting desktop |
| 36 |
entries and such even if you don't use a Freedesktop-compatible |
| 37 |
environment. |
| 38 |
|
| 39 |
Rich |
Archives