Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On Wed, Sep 16, 2020 at 4:08 PM Jonas Stein wrote: > > Hi, > > > When the latest release remains 'latest ~arch' for less than 3 days, > > stabilizing it after 30 days makes little sense. After all, people with > > frequent upgrade cycle will test it for no more than that, and people > > with infrequent upgrade cycle may miss the version entirely. > > > Do you have any suggestions how we could improve this? > > At first we need a strict definition of "stable" and "testing", then we > can discuss how to stabilize. > Not sure it is a definition issue so much that the concept doesn't fit with these sorts of packages. Normally the idea of stable is that you're willing to trade speed for quality. The problem is that in these sorts of packages you're often getting neither. For example, you're not going to have a more-bug-free experience with youtube-dl if you run a two month old version, because the APIs are all changing and you're just losing the cat and mouse game. IMO these sorts of packages probably shouldn't have stable versions at all. Then users will accept ~arch, and both know what they're getting into, and also not get stuck with old versions that give them suboptimal results. Now, if somebody can come up with a better interface for that which is cleaner than having to stick foo/bar in accept_keywords that would be nice. But that almost suggests another class of keyword entirely. These packages aren't really "stable" - so much as stable not being an option. -- Rich
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
Hi, > When the latest release remains 'latest ~arch' for less than 3 days, > stabilizing it after 30 days makes little sense. After all, people with > frequent upgrade cycle will test it for no more than that, and people > with infrequent upgrade cycle may miss the version entirely. > Do you have any suggestions how we could improve this? At first we need a strict definition of "stable" and "testing", then we can discuss how to stabilize. The list of requirements should be testable like if (old_enough AND no_bugs_with_security_tag AND all_deps_stable AND ... ) then stable We should have a vote which properties are required and stick to these more strictly in future. And a stabilization tool, which is part of gentoo and hosted at gentoo will check these properties. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On Tue, 15 Sep 2020 09:12:58 +0200 Toralf Förster wrote: > However this doesn't cover bugs filed a while ago and are not be fixed in > current stable. A mitigation would be it wouldn't file a stabilization req if there was already one open. Basically means as soon as there's one stable req, it reverts to "manual mode", as you either fix the problem that blocked stabilization, or you ship a new one and re-point the stabilization request to that instead. pgpFSehgOrpfp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On 9/15/20 8:42 AM, Michał Górny wrote: > Do you have any suggestions how we could improve this? A (naive) approach would be to have something like auto_stable_after_x_days=n somewhere and a bot which checks whether a bug was opened related to the last version. However this doesn't cover bugs filed a while ago and are not be fixed in current stable. -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On 9/15/20 9:42 AM, Michał Górny wrote: > Hi, > > The regular stabilization workflow works for the majority of packages. > However, it makes little sense for packages with frequent release > cycles. Examples of these are boto3/botocore (daily release cycle) or > hypothesis (upstream conflates commits with releases). > > When the latest release remains 'latest ~arch' for less than 3 days, > stabilizing it after 30 days makes little sense. After all, people with > frequent upgrade cycle will test it for no more than that, and people > with infrequent upgrade cycle may miss the version entirely. Isn't the 30 days just a recommendation, not a strict rule? > > In the end, we stabilize an entirely arbitrary version at an arbitrary > point in time, and even if users were willing to give it better testing, > they can't guess which version will be the next stable candidate. > > Do you have any suggestions how we could improve this? Just use maintainer's discretion on them. For example, see how youtube-dl and vivaldi are stabilized, both having frequent releases. In vivaldi's case the security updates make fast-stabilization a mandatory step pretty much and for youtube-dl you want to keep it compatible with "today". Anyway, that's one way. Not like every stable version in the tree works either. -- juippis signature.asc Description: OpenPGP digital signature
