| 1 |
Rich Freeman:> On Sun, Jun 29, 2014 at 8:36 AM, hasufell |
| 2 |
<hasufell@g.o> wrote: |
| 3 |
>> This is still too vague for me. If it's expected to be short-term, then |
| 4 |
>> it can as well just land in ~arch. |
| 5 |
> |
| 6 |
> A package that hasn't been tested AT ALL doesn't belong in ~arch. |
| 7 |
|
| 8 |
Huh? That's exactly the place. However, if you mean "AT ALL" in the |
| 9 |
sense that no one ever tried to compile it, then the guy who comitted |
| 10 |
should not have commit rights. |
| 11 |
|
| 12 |
> Suppose the maintainer is unable to test some aspect of the package, |
| 13 |
> or any aspect of the package? Do we want it to break completely for |
| 14 |
> ~arch? In that event, nobody will run ~arch for that package, and |
| 15 |
> then it still isn't getting tested. |
| 16 |
|
| 17 |
In that event, you will get a bug report VERY soon. |
| 18 |
|
| 19 |
> I agree that masking for testing is like having a 3rd branch, but I'm |
| 20 |
> not convinced that this is a bad thing. |
| 21 |
|
| 22 |
I have to reiterate: |
| 23 |
* increases the workload, because we are effectively running 3 branches |
| 24 |
* decreases the amount of testing for that time period, because... it's |
| 25 |
masked |
| 26 |
* causes confusion (see this thread) |
| 27 |
* decreases the quality of our stable branch, because people suddenly |
| 28 |
expect the unstable branch to be ...stable and don't bother with filing |
| 29 |
stabilization requests anymore |
| 30 |
* makes the whole testing/stabilization iteration actually slower, |
| 31 |
possibly even causing unnecessary exposures to security issues |
| 32 |
* causes inconsistency, because not everyone actually agrees on the |
| 33 |
3-branches concept and it was never actually decided to be one |
| 34 |
|
| 35 |
> Sure, it could go into an overlay, but for that matter so could all of ~arch. |
| 36 |
|
| 37 |
Not at all. I made a clear distinction for that. Overlays have some good |
| 38 |
use cases, but even those get abused and we end up with projects not |
| 39 |
caring to import ebuilds to the tree anymore. |
| 40 |
|
| 41 |
To make the situation even worse, a lot of people don't mask broken |
| 42 |
packages if they have ever been in ~arch, as if this is a one-way road |
| 43 |
from hardmask->keywordmask->stable. No, it isn't. |
| 44 |
|
| 45 |
> I guess the question is, what exactly are we trying to fix? Even if |
| 46 |
> occasionally a maintainer drops the ball and leaves something masked |
| 47 |
> for a year, how is that different from a maintainer dropping the ball |
| 48 |
> and not adding a new release to the main tree for a year? Would we be |
| 49 |
> better off if Docker 1 wasn't in the tree at all? If it happened to |
| 50 |
> have a known issue would ~arch users be better off if some other dev |
| 51 |
> came along and helpfully added it to the tree unmasked no realizing |
| 52 |
> that somebody else was already working on it? |
| 53 |
|
| 54 |
Trying to fix |
| 55 |
* workflow |
| 56 |
* user experience |
| 57 |
* quality of stable branch |
| 58 |
|
| 59 |
Inconsistent usage of hardmasks is only one problem here, but it is one. |
| 60 |
|
| 61 |
|
| 62 |
So, from my POV hardmasks are reasonable for these use cases: |
| 63 |
* package was imported to ~arch, turned out broken, bugs are difficult |
| 64 |
to fix, no improvement upstream |
| 65 |
* package has security issues, but we don't want it removed (happens a |
| 66 |
lot for games) |
| 67 |
* package is known to be broken, but we want it in the tree (like |
| 68 |
googleearth) |
| 69 |
* package is a library and is either known to or expected to break more |
| 70 |
than half of it's consumers |
| 71 |
|
| 72 |
The last 3 points can, depending on the actual situation, be a good use |
| 73 |
case for an overlay. Some already do it, including for non-trivial |
| 74 |
libraries. |
| 75 |
|
| 76 |
|
| 77 |
To make a blunt statement here: many commits in profiles/ cause trouble |
| 78 |
for the user in one way or another. Some people on the forums already |
| 79 |
told us they want to switch, because they are sick of dealing with world |
| 80 |
updates since they seem get more and more complicated. For multilib we |
| 81 |
have been abusing profiles/ a lot, since there is only one alternative |
| 82 |
way which is almost impossible to carry out given the large scale of |
| 83 |
these changes: a parallel branch which gets imported in one blow. |
| 84 |
|
| 85 |
Profile hackery has to get less. It's not improving user experience. |
| 86 |
Users are switching to ~arch, because people tell them on IRC and |
| 87 |
elsewhere that it's "almost stable" and that arch is too slow. That |
| 88 |
makes the situation even worse. |
| 89 |
|
| 90 |
|
| 91 |
In addition, we should make the most important arch testing |
| 92 |
points/techniques part of the quizzes and allow maintainers to carry out |
| 93 |
stabilization on major arches if they have access to them (that doesn't |
| 94 |
mean they have to, they can still request help from the dedicated arch |
| 95 |
teams). |
| 96 |
|
| 97 |
Having no clear release scheme can be neck-breaking for a project. |
| 98 |
Rolling release or not. |
| 99 |
|
| 100 |
But I doubt we will come to any conclusion here. This thread will get |
| 101 |
some bikeshed and if someone really cares, he will bring it up to the |
| 102 |
council which will basically say "we encourage foo, but allow bar as |
| 103 |
well and leave anything else up to the maintainer", neither deciding on |
| 104 |
a real 3rd branch, nor declining it (because if they would decide on a |
| 105 |
3rd branch, they would actually have to come up with a PMS addition that |
| 106 |
is sane and not ambigous like hardmasks which are used for all random |
| 107 |
sorts of things... and don't tell me hardmask messages can be used as an |
| 108 |
API). |
Archives