On Mon, 2024-11-18 at 17:32 +, Mattia Verga via devel wrote:
> Il 18/11/24 16:34, Adam Williamson ha scritto:
> > On Mon, 2024-11-18 at 11:49 +, Zbigniew Jędrzejewski-Szmek wrote:
> > > If there is something that the policy text says that is stronger than
> > > what Bodhi requires, then we
Il 18/11/24 16:34, Adam Williamson ha scritto:
> On Mon, 2024-11-18 at 11:49 +, Zbigniew Jędrzejewski-Szmek wrote:
>> If there is something that the policy text says that is stronger than
>> what Bodhi requires, then we should update the policy text immediately.
> As of now there is not, becaus
On Mon, 2024-11-18 at 11:49 +, Zbigniew Jędrzejewski-Szmek wrote:
>
> If there is something that the policy text says that is stronger than
> what Bodhi requires, then we should update the policy text immediately.
As of now there is not, because in 8.2 I made the tool to implement
what the po
On Sun, Nov 17, 2024 at 10:12:58AM -0800, Adam Williamson wrote:
> On Sun, 2024-11-17 at 18:35 +0100, Kevin Kofler via devel wrote:
> > Kevin Kofler via devel wrote:
> > > PS: I suspect the documentation was actually just an attempt to document
> > > the previous broken Bodhi policy implementation.
Kevin Kofler via devel wrote:
> PS: I suspect the documentation was actually just an attempt to document
> the previous broken Bodhi policy implementation. (See
> https://github.com/fedora-infra/bodhi/issues/772 and
> https://github.com/fedora-infra/bodhi/issues/1033 – both got closed, but
> the is
On Sun, 2024-11-17 at 19:36 +0100, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > The situation in the old code was actually rather more complicated, and
> > weird, than "the non-settable threshold was fixed to the wrong value" -
> > there were multiple check functions that applied diff
On Sun, 2024-11-17 at 10:12 -0800, Adam Williamson wrote:
>
> So on the whole, I think you have a good point here, thanks for raising
> it. I will file a FESCo ticket and ask for them to consider the history
> here and decide if they want to make any changes based on this
> evaluation.
Filed http
Adam Williamson wrote:
> The situation in the old code was actually rather more complicated, and
> weird, than "the non-settable threshold was fixed to the wrong value" -
> there were multiple check functions that applied different logic to
> different operations, which is why you could sometimes p
On Sun, 2024-11-17 at 18:35 +0100, Kevin Kofler via devel wrote:
> Kevin Kofler via devel wrote:
> > PS: I suspect the documentation was actually just an attempt to document
> > the previous broken Bodhi policy implementation. (See
> > https://github.com/fedora-infra/bodhi/issues/772 and
> > https:
Kevin Kofler via devel wrote:
> When was this decided? I only remember FESCo ever having decided to
> require +2 for critpath updates, not for non-critpath ones.
>
> At some point, those values were written down in the documentation, but
> under what authority? Where was the FESCo decision for tha
Adam Williamson wrote:
> specifically, for releases past the Beta freeze point, *all* updates
> require +2 karma to be pushed stable before the minimum wait. That is,
> if you want your non-critpath update to go stable sooner than 7 days
> after it reached testing, it needs +2 karma. For critpath,
On Thu, Nov 07, 2024 at 11:55:20AM -0800, Adam Williamson wrote:
...snip...
> If folks believe allowing early push at +1 for non-critpath updates was
> appropriate, then the appropriate thing to do would be to lobby FPC to
> change the policy. I think Bodhi should always attempt to implement the
>
Bodhi 8.2.0 is now in production. This includes a big change I wrote a
while ago to how Bodhi handles various 'requirements' -
https://github.com/fedora-infra/bodhi/pull/5630 .
One big visible change is that the karma requirements now match what
the Updates Policy says, which they have not done fo
13 matches
Mail list logo
