On Tue, Jul 29, 2025 at 10:04:18AM -0700, Adam Williamson wrote:
> On Tue, 2025-07-29 at 09:58 -0700, Kevin Fenzi wrote:
> > On Tue, Jul 29, 2025 at 09:37:44AM +, Frantisek Krenzelok wrote:
> > > First of all apologies for this mess.
> > > I have thought this would be actually a good way to do
Dne 30. 07. 25 v 13:35 Michael J Gruber napsal(a):
Kevin Fenzi venit, vidit, dixit 2025-07-29 19:04:31:
I think this is all too big a hammer.
There's lots of cases where people make small changes and don't think
it's worth doing a new build, but expect it will get picked up in the
next one.
S
On Wed, Jul 30, 2025 at 8:51 PM Adam Williamson
wrote:
> If the system doesn't handle this scenario sensibly:
>
> * Submit a PR to libfoo that bumps its soname
> * Submit a PR to bar-app to rebuild it against the new libfoo soname
> * ???
> * Profit
>
> then it cannot be viable for Fedora. Broadl
On Tue, Jul 29, 2025 at 4:58 PM Kevin Fenzi wrote:
> I'm all for documenting this better, but where?
>
> We could perhaps add something to the reminder about the mass rebuild
> coming up (which is supposed to be a week before I think?).
We get an email when the mass rebuild
has started (and fini
On Wed, 2025-07-30 at 13:53 -0400, Stephen Gallagher wrote:
> On Wed, Jul 30, 2025 at 1:01 PM Kevin Fenzi wrote:
> >
> > On Wed, Jul 30, 2025 at 03:44:05PM +0200, Miro Hrončok wrote:
> > >
> > > Let's have draft builds like in CentOS Stream?
> > >
> > > A pull request is scratch built anyway. L
On Wed, 2025-07-30 at 13:35 +0200, Michael J Gruber wrote:
> Kevin Fenzi venit, vidit, dixit 2025-07-29 19:04:31:
> > I think this is all too big a hammer.
> >
> > There's lots of cases where people make small changes and don't think
> > it's worth doing a new build, but expect it will get picked
On Wed, Jul 30, 2025 at 1:01 PM Kevin Fenzi wrote:
>
> On Wed, Jul 30, 2025 at 03:44:05PM +0200, Miro Hrončok wrote:
> >
> > Let's have draft builds like in CentOS Stream?
> >
> > A pull request is scratch built anyway. Let it build as draft build and when
> > the PR is merged, promote the draft b
On Wed, Jul 30, 2025 at 03:44:05PM +0200, Miro Hrončok wrote:
>
> Let's have draft builds like in CentOS Stream?
>
> A pull request is scratch built anyway. Let it build as draft build and when
> the PR is merged, promote the draft build to a real one (in a side tag if
> needed).
Are there any d
On 30. 07. 25 13:35, Michael J Gruber wrote:
Kevin Fenzi venit, vidit, dixit 2025-07-29 19:04:31:
I think this is all too big a hammer.
There's lots of cases where people make small changes and don't think
it's worth doing a new build, but expect it will get picked up in the
next one.
So, perh
On Wed, Jul 30, 2025 at 1:35 PM Michael J Gruber wrote:
> Is there any valid reason to push a commit to rawhide dist-git without
> building it?
To simply save resources.
I don't disagree with what you described. There might be perks in
having Rawhide built automatically.
But in that case I'd li
Kevin Fenzi venit, vidit, dixit 2025-07-29 19:04:31:
> I think this is all too big a hammer.
>
> There's lots of cases where people make small changes and don't think
> it's worth doing a new build, but expect it will get picked up in the
> next one.
>
> So, perhaps a more targeted approach might
I think this is all too big a hammer.
There's lots of cases where people make small changes and don't think
it's worth doing a new build, but expect it will get picked up in the
next one.
So, perhaps a more targeted approach might work? Say a week before the
mass rebuild, add a comment to all 'st
On Tue, 2025-07-29 at 09:58 -0700, Kevin Fenzi wrote:
> On Tue, Jul 29, 2025 at 09:37:44AM +, Frantisek Krenzelok wrote:
> > First of all apologies for this mess.
> > I have thought this would be actually a good way to do it, unaware of the
> > full process..
> >
> > I think we should make t
On Tue, Jul 29, 2025 at 09:37:44AM +, Frantisek Krenzelok wrote:
> First of all apologies for this mess.
> I have thought this would be actually a good way to do it, unaware of the
> full process..
>
> I think we should make this at least an exemplary case and document this as I
> have not
On Tue, Jul 29, 2025 at 7:17 AM Florian Weimer wrote:
>
> * Adam Williamson:
>
> > On Mon, 2025-07-28 at 15:33 -0500, Chris Adams wrote:
> >> Once upon a time, Adam Williamson said:
> >> > Please, *always*, only land significant changes when you are ready to
> >> > build and submit them as regula
* Adam Williamson:
> On Mon, 2025-07-28 at 15:33 -0500, Chris Adams wrote:
>> Once upon a time, Adam Williamson said:
>> > Please, *always*, only land significant changes when you are ready to
>> > build and submit them as regular updates. In general, the delta between
>> > what is currently in R
First of all apologies for this mess.
I have thought this would be actually a good way to do it, unaware of the full
process..
I think we should make this at least an exemplary case and document this as I
have not encountered anything discouraging me from this decision(that my be
just me not l
On 29. 07. 25 1:08, Adam Williamson wrote:
(I suspect there would also be some awkward cases where there are hard-
versioned inter-package dependencies produced by some kind of macro
which would result in the individual updates failing tests).
But they should fail in that case, so we don't end
On Tue, Jul 29, 2025 at 3:08 AM Adam Williamson
wrote:
>
> It's the same question as Chris asked, effectively. If you can identify
> the packages to revert them, you could just as easily skip them
> instead. The answer is 'maybe, but it's not trivial'.
>
> Note the correct requirement is not just
On Tue, 2025-07-29 at 02:33 +, Gary Buhrmaster wrote:
> On Mon, Jul 28, 2025 at 6:46 PM Adam Williamson
> wrote:
> >
> > Hey folks! I figured a wider heads-up about this might be useful.
> >
> > The owner of the "Dropping of cert.pem file" Change[0] committed the
> > change to dist-git but d
On Mon, Jul 28, 2025 at 6:46 PM Adam Williamson
wrote:
>
> Hey folks! I figured a wider heads-up about this might be useful.
>
> The owner of the "Dropping of cert.pem file" Change[0] committed the
> change to dist-git but did not build it, instead leaving it to be built
> as part of the mass rebu
On Tue, 2025-07-29 at 00:49 +0200, Miro Hrončok wrote:
> On 28. 07. 25 20:46, Adam Williamson wrote:
> > Mass rebuild changes bypass automated testing and gating
>
> This begs the question: Should we stop doing it that way?
>
> What if we let all the builds from mass rebuild go trough bodhi? One
On 28. 07. 25 20:46, Adam Williamson wrote:
Mass rebuild changes bypass automated testing and gating
This begs the question: Should we stop doing it that way?
What if we let all the builds from mass rebuild go trough bodhi? One by one.
Would Bodhi + OpenQA handle the load?
--
Miro Hrončok
-
On Mon, 2025-07-28 at 15:33 -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson said:
> > Please, *always*, only land significant changes when you are ready to
> > build and submit them as regular updates. In general, the delta between
> > what is currently in Rawhide and what the mass r
Once upon a time, Adam Williamson said:
> Please, *always*, only land significant changes when you are ready to
> build and submit them as regular updates. In general, the delta between
> what is currently in Rawhide and what the mass rebuild will build
> should be *as small as possible*. Any unbu
Hey folks! I figured a wider heads-up about this might be useful.
The owner of the "Dropping of cert.pem file" Change[0] committed the
change to dist-git but did not build it, instead leaving it to be built
as part of the mass rebuild[1]. This, unfortunately, was a really bad
idea.
Mass rebuild c
On Tue, Nov 27, 2018 at 7:59 AM Owen Taylor wrote:
>
> A lot of discussion about improving the compose process seem to end up
> with a "reality check" - that ideas have already been tried but don't
> work because of requirements a) b) c) d). You can't have the pony, but
> maybe if a lot of effort
t; work because of requirements a) b) c) d). You can't have the pony, but
> > maybe if a lot of effort is put into it, you can have a faster rocking
> > horse.
> >
> > If want to fundamentally improve the Fedora workflow we need compose
> > ponies, we can&#x
ut
> maybe if a lot of effort is put into it, you can have a faster rocking
> horse.
>
> If want to fundamentally improve the Fedora workflow we need compose
> ponies, we can't just have rocking horses!
>
> Perhaps it would make sense to leave the current 8-10 hour compose
On Tue, Nov 27, 2018 at 10:12 AM Stephen John Smoogen wrote:
> Define what a compose is? Currently it is a word which covers a
> multitude of different processes and reasons for those processes. We
> can't 'fix' or even 'replace' or parallel them without actually
> knowing why someone duct taped t
, but
> maybe if a lot of effort is put into it, you can have a faster rocking
> horse.
>
> If want to fundamentally improve the Fedora workflow we need compose
> ponies, we can't just have rocking horses!
>
> Perhaps it would make sense to leave the current 8-10 hour compo
king
horse.
If want to fundamentally improve the Fedora workflow we need compose
ponies, we can't just have rocking horses!
Perhaps it would make sense to leave the current 8-10 hour compose in
place for the forseeable future, and work on a new system in parallel
where the primary const
thanks! ;)
> Kevin Fenzi hat am 2. Februar 2018 um 18:49 geschrieben:
>
>
> On 02/02/2018 06:51 AM, inderau...@arcor.de wrote:
> > leave
>
>
> If you are trying to unsubscribe, please mail the unsubscribe address below:
>
> > __
On 02/02/2018 06:51 AM, inderau...@arcor.de wrote:
> leave
If you are trying to unsubscribe, please mail the unsubscribe address below:
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email
leave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
36 matches
Mail list logo
