| 1 |
On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> This is still too vague for me. If it's expected to be short-term, then |
| 3 |
> it can as well just land in ~arch. |
| 4 |
|
| 5 |
A package that hasn't been tested AT ALL doesn't belong in ~arch. |
| 6 |
Suppose the maintainer is unable to test some aspect of the package, |
| 7 |
or any aspect of the package? Do we want it to break completely for |
| 8 |
~arch? In that event, nobody will run ~arch for that package, and |
| 9 |
then it still isn't getting tested. |
| 10 |
|
| 11 |
I agree that masking for testing is like having a 3rd branch, but I'm |
| 12 |
not convinced that this is a bad thing. ~arch should be for packages |
| 13 |
that have received rudimentary testing and which are ready for testing |
| 14 |
by a larger population. Masking should be used for packages that |
| 15 |
haven't received rudimentary testing - they might not have been tested |
| 16 |
at all. |
| 17 |
|
| 18 |
Sure, it could go into an overlay, but for that matter so could all of ~arch. |
| 19 |
|
| 20 |
I guess the question is, what exactly are we trying to fix? Even if |
| 21 |
occasionally a maintainer drops the ball and leaves something masked |
| 22 |
for a year, how is that different from a maintainer dropping the ball |
| 23 |
and not adding a new release to the main tree for a year? Would we be |
| 24 |
better off if Docker 1 wasn't in the tree at all? If it happened to |
| 25 |
have a known issue would ~arch users be better off if some other dev |
| 26 |
came along and helpfully added it to the tree unmasked no realizing |
| 27 |
that somebody else was already working on it? |
| 28 |
|
| 29 |
Rich |
Archives