| 1 |
On Wed, Sep 16, 2020 at 4:08 PM Jonas Stein <jstein@g.o> wrote: |
| 2 |
> |
| 3 |
> Hi, |
| 4 |
> |
| 5 |
> > When the latest release remains 'latest ~arch' for less than 3 days, |
| 6 |
> > stabilizing it after 30 days makes little sense. After all, people with |
| 7 |
> > frequent upgrade cycle will test it for no more than that, and people |
| 8 |
> > with infrequent upgrade cycle may miss the version entirely. |
| 9 |
> |
| 10 |
> > Do you have any suggestions how we could improve this? |
| 11 |
> |
| 12 |
> At first we need a strict definition of "stable" and "testing", then we |
| 13 |
> can discuss how to stabilize. |
| 14 |
> |
| 15 |
|
| 16 |
Not sure it is a definition issue so much that the concept doesn't fit |
| 17 |
with these sorts of packages. Normally the idea of stable is that |
| 18 |
you're willing to trade speed for quality. |
| 19 |
|
| 20 |
The problem is that in these sorts of packages you're often getting |
| 21 |
neither. For example, you're not going to have a more-bug-free |
| 22 |
experience with youtube-dl if you run a two month old version, because |
| 23 |
the APIs are all changing and you're just losing the cat and mouse |
| 24 |
game. |
| 25 |
|
| 26 |
IMO these sorts of packages probably shouldn't have stable versions at |
| 27 |
all. Then users will accept ~arch, and both know what they're getting |
| 28 |
into, and also not get stuck with old versions that give them |
| 29 |
suboptimal results. |
| 30 |
|
| 31 |
Now, if somebody can come up with a better interface for that which is |
| 32 |
cleaner than having to stick foo/bar in accept_keywords that would be |
| 33 |
nice. But that almost suggests another class of keyword entirely. |
| 34 |
These packages aren't really "stable" - so much as stable not being an |
| 35 |
option. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives