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
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
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,
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
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
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