On Sat, Nov 26, 2022 at 05:27:30PM -, Mattia Verga via devel wrote:
> @kevin I've announced on Bodhi matrix channel that I was planning to draft
> the new release, but since I received no response I've pushed out Bodhi 7.0.0.
>
> I have followed the SOP at [1] and bodhi-* RPMs are now
@kevin I've announced on Bodhi matrix channel that I was planning to draft the
new release, but since I received no response I've pushed out Bodhi 7.0.0.
I have followed the SOP at [1] and bodhi-* RPMs are now available in both
f37-infra-stg and f36-infra-stg. Tests run smoothly in F37, so I
On Fri, 2022-11-18 at 08:10 +, Mattia Verga via devel wrote:
> Il 17/11/22 18:10, Adam Williamson ha scritto:
> > On Wed, 2022-11-16 at 17:37 +, Mattia Verga via devel wrote:
> > > Kevin, the PR for Bodhi is nearly finished, it will add support for
> > > using the 'frozen' release state to
On Fri, Nov 18, 2022 at 08:10:56AM +, Mattia Verga via devel wrote:
> Il 17/11/22 18:10, Adam Williamson ha scritto:
> > On Wed, 2022-11-16 at 17:37 +, Mattia Verga via devel wrote:
> >> Kevin, the PR for Bodhi is nearly finished, it will add support for
> >> using the 'frozen' release
Il 17/11/22 18:10, Adam Williamson ha scritto:
> On Wed, 2022-11-16 at 17:37 +, Mattia Verga via devel wrote:
>> Kevin, the PR for Bodhi is nearly finished, it will add support for
>> using the 'frozen' release state to avoid pausing the push cron job and
>> avoid direct pending to stable push
On Wed, 2022-11-16 at 17:37 +, Mattia Verga via devel wrote:
>
> Kevin, the PR for Bodhi is nearly finished, it will add support for
> using the 'frozen' release state to avoid pausing the push cron job and
> avoid direct pending to stable push of updates when the release is frozen.
>
> I'll
On Wed, Nov 16, 2022 at 02:09:47PM +0100, Kevin Kofler via devel wrote:
>
> Kevin Fenzi is currently a member of FESCo (see
> https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for
> years. So pushing the blame off to "someone else" is not going to work.
You're welcome to
On Wed, Nov 16, 2022 at 05:37:07PM +, Mattia Verga via devel wrote:
>
> Kevin, the PR for Bodhi is nearly finished, it will add support for
> using the 'frozen' release state to avoid pausing the push cron job and
> avoid direct pending to stable push of updates when the release is frozen.
Il 10/11/22 21:49, Kevin Fenzi ha scritto:
> On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
>> Il 10/11/22 01:58, Kevin Kofler via devel ha scritto:
>>> Kevin Kofler via devel wrote:
>>>
Mattia Verga via devel wrote:
> with the current workflow, Bodhi doesn't know
Stephen Smoogen wrote:
> On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Kevin Fenzi wrote:
>> > I think we are going to just have to agree to disagree here.
>> >
>> > I think we have had this discussion a number of times now and aren't
>> >
On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Kevin Fenzi wrote:
> > I think we are going to just have to agree to disagree here.
> >
> > I think we have had this discussion a number of times now and aren't
> > going to convince the other.
>
> So
Kevin Fenzi wrote:
> I think we are going to just have to agree to disagree here.
>
> I think we have had this discussion a number of times now and aren't
> going to convince the other.
So Bodhi will continue to become more and more unmaintainable due to piling
up more and more complicated
On Mon, Nov 14, 2022 at 11:54:32PM +0100, Kevin Kofler via devel wrote:
...snip...
I think we are going to just have to agree to disagree here.
I think we have had this discussion a number of times now and aren't
going to convince the other.
kevin
signature.asc
Description: PGP signature
Kevin Fenzi wrote:
> For a few years I was keeping track of updates that caused big problems:
>
> https://fedoraproject.org/wiki/Updates_Lessons
That is also very anecdotal evidence though. And with only one exception
(the broken dependency in celt), the updates in the above list above are
For a few years I was keeping track of updates that caused big problems:
https://fedoraproject.org/wiki/Updates_Lessons
The orig "very bad" update was a dbus update that broke everything.
In any case I have seen our current updates system working and blocking
tons of harmfull updates over the
Gary Buhrmaster wrote:
> Interesting. I have never seen such analysis results
> shared (either the part about why maintainers do it,
> or the pushes being the common causes of bad
> updates), and of course, anecdotal experience does
> not lead to a supportable conclusion. Where was
> that
On Sat, Nov 12, 2022 at 7:19 PM Kevin Kofler via devel
wrote:
> (E.g., many maintainers
> enable automatic pushes because they need to wait so long to be allowed to
> push an update to stable that they would forget to push it manually. But
> automatic pushes are the most common source of bad
Stephen Smoogen wrote:
> Pretty much every one of those bodhi requirements is because either
>
> * a developer did not use that wonderful organ for some reason, and people
> said 'that should never happen again.'
> * what the developer decided was not liked by other developers enough that
> it
On Fri, 11 Nov 2022 at 10:19, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Stephen Smoogen wrote:
> > You can only refactor it when you have a steady set of requirements. The
> > code has been 'refactored' at least 4 times but what happens is that you
> > will get into about
Stephen Smoogen wrote:
> You can only refactor it when you have a steady set of requirements. The
> code has been 'refactored' at least 4 times but what happens is that you
> will get into about 1/3rd of the way into it and find you have now to add
> a bunch of new requirements.
Sounds like
On Fri, 11 Nov 2022 at 02:34, Demi Marie Obenour
wrote:
> On 11/10/22 21:02, Gary Buhrmaster wrote:
> > On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen
> wrote:
> >> On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote:
> >>>
> >>> I sympathize greatly here. It was a pain to wire up "logout" to the
On 11/10/22 21:02, Gary Buhrmaster wrote:
> On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen wrote:
>> On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote:
>>>
>>> I sympathize greatly here. It was a pain to wire up "logout" to the
>>> "relogin" property in updateinfo (the field had been in bodhi for
Neal Gompa wrote:
> Bodhi is an unusually difficult codebase for what it does.
IMHO, the main reason the Bodhi code is so complex is because of all the
policy that it enforces: karma (counting), update policies (minimum
karma/time), critical path, autopushes, gating (automatic QA), …
If we
On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen wrote:
>
>
>
> On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote:
>>
>> I sympathize greatly here. It was a pain to wire up "logout" to the
>> "relogin" property in updateinfo (the field had been in bodhi for a
>> decade and nobody wired it up to the
On Thu, Nov 10, 2022 at 18:55 Neal Gompa wrote:
> On Thu, Nov 10, 2022 at 3:49 PM Kevin Fenzi wrote:
> >
> > On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> > > It shouldn't be too hard, it's just that Bodhi code is
> > > sometimes so contorted that by making a simple
On Thu, Nov 10, 2022 at 3:49 PM Kevin Fenzi wrote:
>
> On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> > It shouldn't be too hard, it's just that Bodhi code is
> > sometimes so contorted that by making a simple change it's easy to break
> > something else... moving
On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> Il 10/11/22 01:58, Kevin Kofler via devel ha scritto:
> > Kevin Kofler via devel wrote:
> >
> >> Mattia Verga via devel wrote:
> >>> with the current workflow, Bodhi doesn't know when a release is freezed.
> >>> There is
Il 10/11/22 01:58, Kevin Kofler via devel ha scritto:
> Kevin Kofler via devel wrote:
>
>> Mattia Verga via devel wrote:
>>> with the current workflow, Bodhi doesn't know when a release is freezed.
>>> There is support for a "Freeze" state, but it was never used.
>> How do we prevent then that
Kevin Kofler via devel wrote:
> Mattia Verga via devel wrote:
>> with the current workflow, Bodhi doesn't know when a release is freezed.
>> There is support for a "Freeze" state, but it was never used.
>
> How do we prevent then that pushes to stable actually move forward? If
> rel- eng just
Mattia Verga via devel wrote:
> with the current workflow, Bodhi doesn't know when a release is freezed.
> There is support for a "Freeze" state, but it was never used.
How do we prevent then that pushes to stable actually move forward? If rel-
eng just hits a different button / runs a different
The problem is
> !can_push(stable))
>
with the current workflow, Bodhi doesn't know when a release is freezed.
There is support for a "Freeze" state, but it was never used.
Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Adam Williamson wrote:
> Yeah, this is a good point, though I'm not sure how easy it is to fix.
if (state == pending && request == stable && !can_push(stable))
push(testing);
else
push(request);
Kevin Kofler
___
devel mailing list --
Maybe push them to both, if they've never been to testing? In other
words, never skip testing.
Sure, there will be some duplication of packages for a cycle or two,
but eventually, they anything that's already in stable will be kicked
out of testing, right?
--
Bojan
On Tue, 2022-11-08 at 07:52 +1100, Bojan Smojver via devel wrote:
> Quick question about direct to stable updates in bodhi, such as FF
> 106.0.4 and kernel 6.0.7 that are lined up for F37 right now. Such
> updates often end up being in nowhere land for quite some time, because
> they
Quick question about direct to stable updates in bodhi, such as FF
106.0.4 and kernel 6.0.7 that are lined up for F37 right now. Such
updates often end up being in nowhere land for quite some time, because
they skip testing to go to stable directly, but the push to stable
cannot happen
35 matches
Mail list logo
