| 1 |
On Sun, Jun 30, 2013 at 8:59 PM, William Hubbs <williamh@g.o> wrote: |
| 2 |
> Nothing is an absolute. I'm not saying that anyone who doesn't like |
| 3 |
> something a maintainer does should be able to force the maintainer to do |
| 4 |
> what they want. |
| 5 |
|
| 6 |
Ditto. I only want maintainers to not be able to get in the way of |
| 7 |
reasonable and well-supported projects and other teams. |
| 8 |
|
| 9 |
If a maintainer just hates having foo-1.2 in the tree because they put |
| 10 |
foo-1.3 in the tree yesterday, and foo-1.2 is stable on x86, we |
| 11 |
already require them to wait until 1.3 can be stabilized (perhaps |
| 12 |
rapidly if a security issue). Maintainers already must coordinate |
| 13 |
with other projects. |
| 14 |
|
| 15 |
In general I'm not in favor of forcing maintainers to do anything |
| 16 |
beyond fixing glaring QA issues. If a maintainer wants to have a |
| 17 |
non-upstreamed patch that doesn't cause issues that isn't a big |
| 18 |
problem IMHO. |
| 19 |
|
| 20 |
However, if another dev wants to co-maintain and make that |
| 21 |
non-upstream patch USE-dependent and support the work, the original |
| 22 |
maintainer must allow them to do so. If the x32 project wants to add |
| 23 |
a conditional patch to support their arch and they are willing to |
| 24 |
follow-through on support, the original maintainer must allow this. |
| 25 |
Non-maintainers must always collaborate with maintainers, but the |
| 26 |
intent of that isn't so that maintainers can block other projects. |
| 27 |
|
| 28 |
I've been in the place of having somebody come along and bump an EAPI |
| 29 |
on me or make other changes that I'd honestly have been more |
| 30 |
comfortable taking my time with. I understand that the job of a |
| 31 |
maintainer is easier if they can block outside changes entirely. |
| 32 |
However, we need to strike a balance. |
| 33 |
|
| 34 |
And on the other side of things I'm completely against scripted |
| 35 |
tree-wide changes without a great deal of care (honestly, I'd prefer |
| 36 |
that all scripted changes against the tree aside maybe from package |
| 37 |
renames be reviewed on -dev first unless they're confined to within a |
| 38 |
project's domain - such as the KDE team making a change to only KDE |
| 39 |
packages). I'm also against fly-by commits where a dev makes changes |
| 40 |
but isn't willing to stand behind them. I think that is what we need |
| 41 |
to protect against, not well-organized projects adding config files to |
| 42 |
daemons. |
| 43 |
|
| 44 |
Rich |
Archives