Hello again!
There's been a lot of discussion on this thread, and some useful
feedback. Thanks!
I would like to make a clearer proposal about how gating in Rawhide
would work:
Multi-package update workflow
=
When a packager wants to update multiple interdependent pa
On Thu, Mar 29, 2018 at 10:47:50AM +0200, Nicolas Mailhot wrote:
> Le 2018-03-28 12:52, Pierre-Yves Chibon a écrit :
>
> Hi
>
> > With bodhi:
> > - Single package update
> > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png
> > - Multi-packages update
>
> Not terribly fond o
On Wed, Mar 28, 2018 at 09:09:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Mar 09, 2018 at 10:20:12AM +0100, Pierre-Yves Chibon wrote:
> > On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
> > > I would like to kick off a general discussion about how we might gate
> > > pack
Le 2018-03-28 12:52, Pierre-Yves Chibon a écrit :
Hi
With bodhi:
- Single package update
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png
- Multi-packages update
Not terribly fond of anything that offloads multi-build intellignece
coordination on packagers, forcing
Dne 28.3.2018 v 19:55 Pierre-Yves Chibon napsal(a):
> On Wed, Mar 28, 2018 at 07:34:51PM +0200, Vít Ondruch wrote:
>
>> And please rename this thread to "Gating packages in Fedora", because
>> Rawhide should be just Fedora.
> You do realize that there is already gating in place for stable release
On Fri, Mar 09, 2018 at 10:20:12AM +0100, Pierre-Yves Chibon wrote:
> On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
> > I would like to kick off a general discussion about how we might gate
> > packages in Rawhide. I think it would be nice to get something in place
> > for the Fedor
On 03/28/2018 12:46 PM, Vít Ondruch wrote:
> And if you can do chain build in Rawhide, I can't see any reason why it
> should not be possible for stable branch.
It's more that it's tricky and not that it's impossible, because of the
Koji buildroot. Packages built into Rawhide become part of the bu
On Wed, Mar 28, 2018 at 07:34:51PM +0200, Vít Ondruch wrote:
>
>
> Dne 28.3.2018 v 19:06 Pierre-Yves Chibon napsal(a):
> > On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote:
> >>Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is
> >>just subcase of multiple
Dne 28.3.2018 v 19:06 Pierre-Yves Chibon napsal(a):
> On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote:
>>Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is
>>just subcase of multiplepkgs process.
> And because it is just a subcase, it can be simplified.
>
On Wed, Mar 28, 2018 at 06:46:50PM +0200, Vít Ondruch wrote:
>Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is
>just subcase of multiplepkgs process.
And because it is just a subcase, it can be simplified.
>And if you can do chain build in Rawhide, I can't see
Why are you stressing MultiplePkgs vs single pkgs. Single pgk process is
just subcase of multiplepkgs process.
And if you can do chain build in Rawhide, I can't see any reason why it
should not be possible for stable branch.
IOW the process for Rawhide should be as close to stable version as
poss
On Wed, Mar 28, 2018 at 01:51:26PM +, Fabio Valentini wrote:
>On Wed, Mar 28, 2018, 15:47 Pierre-Yves Chibon
>wrote:
>
> On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote:
> >Â Â One example where running tests against a single-package update
> would be
On Wed, Mar 28, 2018, 15:47 Pierre-Yves Chibon wrote:
> On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote:
> >One example where running tests against a single-package update would
> be
> >nice IMO would be for toolchain and base packages, for example,
> updates to
> >ann
On Wed, Mar 28, 2018 at 01:39:34PM +, Fabio Valentini wrote:
>One example where running tests against a single-package update would be
>nice IMO would be for toolchain and base packages, for example, updates to
>annobin or binutils, where the answer to "Does this update break
>c
On Wed, Mar 28, 2018, 14:51 Pierre-Yves Chibon wrote:
> On Wed, Mar 28, 2018 at 11:16:35AM +, Fabio Valentini wrote:
> >On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon
> >wrote:
> > Based on the outcome of this discussion, I started trying to draw
> how
> > the
> > proc
On Wed, Mar 28, 2018 at 11:16:35AM +, Fabio Valentini wrote:
>On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon
>wrote:
> Based on the outcome of this discussion, I started trying to draw how
> the
> process to update a package in rawhide would look like with rawhide
>
On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon wrote:
> Good Morning Everyone,
>
Good morning!
> Based on the outcome of this discussion, I started trying to draw how the
> process to update a package in rawhide would look like with rawhide being
> gated
> on tests.
>
> There are currently two
Good Morning Everyone,
Based on the outcome of this discussion, I started trying to draw how the
process to update a package in rawhide would look like with rawhide being gated
on tests.
There are currently two proposals:
- one that does not involve bodhi updates
- one that does
Both proposals h
On Mon, Mar 12, 2018 at 06:05:22PM -0400, Randy Barlow wrote:
> On 03/09/2018 04:20 AM, Pierre-Yves Chibon wrote:
> > I had a different idea in mind, basically try to keep the experience as
> > close as
> > what it is now.
> > for single package:
> > - packager commit
> > - packager build
> >
On 03/15/2018 04:57 PM, Mohan Boddu wrote:
>> As one of the Bodhi contributors, I am inclined to suggest that we could
>> use Bodhi on Rawhide, similar to how we use it for our stable/branched
>> releases, with more relaxed rules (perhaps 1 day in testing or something
>> simple).
> We need a bette
> Greetings fellow Fedorans!
>
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.
>
> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi
On Mon, 2018-03-12 at 17:27 +0100, Pierre-Yves Chibon wrote:
> Does that sound right?
Hi,
yes, it does. Thanks.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.f
On 03/09/2018 04:20 AM, Pierre-Yves Chibon wrote:
> I had a different idea in mind, basically try to keep the experience as close
> as
> what it is now.
> for single package:
> - packager commit
> - packager build
> - build is tagged into a specfic koji tag
> - test are run on this tag
>
On 03/08/2018 10:53 PM, Kevin Kofler wrote:
> IMHO, this is highly impractical. Having to file Bodhi updates for every
> Rawhide build will make development cringe to a halt.
The proposal is to automate the filing of Bodhi updates, so in most
cases you would not really interact with them unless t
On 03/09/2018 04:06 AM, Pierre-Yves Chibon wrote:
>> To be fair, there was a suggestion that we show results in
>> pagure/src.fedoraproject.org, but to me, that definitely sounds like the
>> wrong place for such things. We want tests tied to a specific update,
>> not the entire package as a whole.
On Mon, Mar 12, 2018 at 12:44:39PM -0700, Kevin Fenzi wrote:
> On 03/12/2018 09:35 AM, Pierre-Yves Chibon wrote:
> > On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
> >> Pierre-Yves Chibon wrote:
> >>> Do note that the uniqueness constraint that koji has will mitigate things
> >>> the
On 03/12/2018 09:35 AM, Pierre-Yves Chibon wrote:
> On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
>> Pierre-Yves Chibon wrote:
>>> Do note that the uniqueness constraint that koji has will mitigate things
>>> there. For a package to be built for -liba and then -libb, the package
>>>
On 03/12/2018 04:48 AM, Milan Crha wrote:
> Hi,
>
> On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
>> On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
>>> On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
Sure, with this proposal you would:
* reque
On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > Do note that the uniqueness constraint that koji has will mitigate things
> > there. For a package to be built for -liba and then -libb, the package
> > will need to have its release field bumped twice.
>
On Mon, Mar 12, 2018 at 12:48:02PM +0100, Milan Crha wrote:
> Hi,
>
> On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
> > On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
> > > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > > > Sure, with this proposal you
Pierre-Yves Chibon wrote:
> Do note that the uniqueness constraint that koji has will mitigate things
> there. For a package to be built for -liba and then -libb, the package
> will need to have its release field bumped twice.
Sure, but that has not prevented conflicts in the past either, because
On Mon, Mar 12, 2018, at 5:32 AM, Pierre-Yves Chibon wrote:
> That would register in koji's DB the unique NEVRA which means, the PR can't be
> updated without bumping the release field.
Yep, that problem is exactly (along with the conflict-fest that is %changelog)
what holds back any big steps
Le lundi 12 mars 2018 à 14:51 +0100, Michael Šimáček a écrit :
> On 2018-03-12 12:19, Nicolas Mailhot wrote:
> >
> > Also current chain-build is too primitive to handle complex chains
> >
> > https://github.com/rpm-software-management/mock/issues/170
> >
>
> Koji chain-builds and mockchain are
On 2018-03-12 12:19, Nicolas Mailhot wrote:
Le 2018-03-12 12:10, Pierre-Yves Chibon a écrit :
On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
Hi,
On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wa
Hi,
On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote:
> On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
> > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > > Sure, with this proposal you would:
> > >
> > > * request a side tag
> > > * build a, wait for it
On Mon, 2018-03-12 at 12:12 +0100, Kalev Lember wrote:
> On 03/12/2018 11:33 AM, Milan Crha wrote:
> > I wanted to try whether chain-build with --target would make the
> > trick, it also used to work.
>
> It should work if you use '--target f28-gnome'
Hi,
yes, I know, that's why I wrote "
Le 2018-03-12 12:10, Pierre-Yves Chibon a écrit :
On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
Hi,
On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wait for it to be added to the repo, build
On Sat, Mar 10, 2018 at 04:09:41AM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > yeah, but you would have even better workflow with a side tag.
>
> The problem with a workflow relying entirely on side tags is that it is
> going to increase the risk of conflicts with concurrent changes (a
>
On 03/12/2018 11:33 AM, Milan Crha wrote:
> By the way, I just successfully ran chain-build from an f28 branch.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25654934
> That surprised me, I expected to be kicked of, as it used to do, but it
> didn't do it (it used to kick me off in the pas
On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote:
> Hi,
>
> On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> > Sure, with this proposal you would:
> >
> > * request a side tag
> > * build a, wait for it to be added to the repo, build b, etc.
> > You would not need to file o
Hi,
On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote:
> Sure, with this proposal you would:
>
> * request a side tag
> * build a, wait for it to be added to the repo, build b, etc.
> You would not need to file overrides, just build them in the right
> order with wait-repo between them
On Fri, Mar 09, 2018 at 06:48:56PM +0100, Mathieu Bridon wrote:
> On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote:
> > On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> > > We could take a hint from how we make software upstream these days:
> > >
> > > 1. submit a pull
Kevin Fenzi wrote:
> yeah, but you would have even better workflow with a side tag.
The problem with a workflow relying entirely on side tags is that it is
going to increase the risk of conflicts with concurrent changes (a
phenomenon already somewhat present where side tags are used, but using s
Kevin Fenzi wrote:
> On 03/09/2018 05:42 AM, Kevin Kofler wrote:
>
>> Because a broken dependency in ANY package included on ANY
>> release-critical deliverable now fails the ENTIRE compose process. It is
>> clear that this does not scale.
>
> That is not what is causing the broken composes. See
On 03/09/2018 05:42 AM, Kevin Kofler wrote:
> Broken dependency notifications are disabled because the scripts are broken:
> they still use yum, which does not support the boolean dependencies. It is
> sad that this was still not fixed after months. Instead of wasting their
> time on annoyances
On 03/08/2018 11:10 PM, Milan Crha wrote:
> On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
>> * CI/automated tests run on it, and if all is ok goes out in the next
>> rawhide compose.
>> * If not ok, you could wave the results or build more things/edit the
>> update until it passes.
>
>
On Fri, 2018-03-09 at 10:38 +0100, Pierre-Yves Chibon wrote:
> On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> > We could take a hint from how we make software upstream these days:
> >
> > 1. submit a pull request for the package in src.fp.o on the master
> >branch
> > 2. a C
Dne 9.3.2018 v 15:23 Colin Walters napsal(a):
> A more modern architecture would be something closer to pull requests on
> dist-git;
> tests report into the PR the same way github works today.
May be if we had all .spec files in single repository .
V.
>
> This would work *particularly* w
On Fri, Mar 9, 2018, at 9:23 AM, Colin Walters wrote:
> A more modern architecture would be something closer to pull requests on
> dist-git;
> tests report into the PR the same way github works today.
>
> This would work *particularly* well if it was easy to make a pull request
> across
> mult
A more modern architecture would be something closer to pull requests on
dist-git;
tests report into the PR the same way github works today.
This would work *particularly* well if it was easy to make a pull request across
multiple packages, which would be obvious and easy if we just one git repo
Pierre-Yves Chibon wrote:
> I had a different idea in mind, basically try to keep the experience as
> close as what it is now.
Your proposal makes sense, it sounds like how I would do it too. If we want
gating at all, it should be done that way.
Kevin Kofler
_
Kevin Fenzi wrote:
> To be fair, there was a suggestion that we show results in
> pagure/src.fedoraproject.org, but to me, that definitely sounds like the
> wrong place for such things.
I think they should be displayed in Koji on the build info page for the
particular build that was tested. That
Milan Crha wrote:
> so it looks like you are going to remove chain-build from fedpkg,
> right? It's kind of pain it doesn't work for stable, but if you want to
> get rid of it for rawhide too, or add some unnecessary obstacles for
> its usage, then it's a downgrade like the kerberos usage (it's a p
Martin Kolman wrote:
> That would be really nice! There are often cases where a fix or
> enhancement needs to land in at least two components at once (in our cases
> usually pykickstart & anaconda and/or blivet & anaconda) and the only
> "atomic" way of doing that is doing a chainbuild, which, fran
On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
> On 03/08/2018 11:11 AM, Richard Shaw wrote:
> > What about making side tags easily available to packagers directly? I could
> > build my package that includes an ABI breaking update and rebuild the
> > dependencies within that side tag and the
Dne 9.3.2018 v 11:24 Pierre-Yves Chibon napsal(a):
> On Fri, Mar 09, 2018 at 10:52:27AM +0100, Vít Ondruch wrote:
>> I had a different idea in mind, basically try to keep the experience as
>> close as
>> what it is now.
>> for single package:
>>- packager commit
>>- packager build
>>
On Fri, Mar 09, 2018 at 10:52:27AM +0100, Vít Ondruch wrote:
> I had a different idea in mind, basically try to keep the experience as
> close as
> what it is now.
> for single package:
>- packager commit
>- packager build
>- build is tagged into a specfic koji tag
>- test are r
Thanks for starting this discussion and I really want to thank you for
offering Bodhi to handle the Rawhide. It would be really sad I some
other system was used for Rawhide then for stable versions.
Dne 9.3.2018 v 10:20 Pierre-Yves Chibon napsal(a):
> On Thu, Mar 08, 2018 at 01:00:32PM -0500, Ran
On Fri, Mar 09, 2018 at 10:12:37AM +0100, Mathieu Bridon wrote:
> We could take a hint from how we make software upstream these days:
>
> 1. submit a pull request for the package in src.fp.o on the master
>branch
> 2. a CI automatically builds this package in Koji
> 3. merge the pull request i
On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.
I was waiting to have some more time to work on it to kick
On Fri, 2018-03-09 at 10:06 +0100, Pierre-Yves Chibon wrote:
> On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> > On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > > Randy Barlow wrote:
> > > > It may be possible to automate the process a bit to make it
> > > > less heavy
> > > > for de
On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > Randy Barlow wrote:
> >> It may be possible to automate the process a bit to make it less heavy
> >> for developers, though there is some complication for multi-package
> >> updates
> >
>
On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
> * CI/automated tests run on it, and if all is ok goes out in the next
> rawhide compose.
> * If not ok, you could wave the results or build more things/edit the
> update until it passes.
Hi,
so it looks like you are going to remove ch
On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> Randy Barlow wrote:
>> It may be possible to automate the process a bit to make it less heavy
>> for developers, though there is some complication for multi-package
>> updates
>
> Some automation would help, sure. But if we are going to do things
> au
Randy Barlow wrote:
> As one of the Bodhi contributors, I am inclined to suggest that we could
> use Bodhi on Rawhide, similar to how we use it for our stable/branched
> releases, with more relaxed rules (perhaps 1 day in testing or something
> simple).
IMHO, this is highly impractical. Having to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2018-03-08 at 13:00 -0500, Randy Barlow wrote:
> Greetings fellow Fedorans!
>
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in
> place
> for the Fedor
On 08/03/18 19:25, Mattia Verga wrote:
Il 08/03/2018 20:11, Richard Shaw ha scritto:
What about making side tags easily available to packagers directly? I
could build my package that includes an ABI breaking update and
rebuild the dependencies within that side tag and then submit when
everythi
On 03/08/2018 11:11 AM, Richard Shaw wrote:
> What about making side tags easily available to packagers directly? I could
> build my package that includes an ABI breaking update and rebuild the
> dependencies within that side tag and then submit when everything is
> complete.
Yes, teaching bodhi a
Il 08/03/2018 20:11, Richard Shaw ha scritto:
What about making side tags easily available to packagers directly? I
could build my package that includes an ABI breaking update and
rebuild the dependencies within that side tag and then submit when
everything is complete.
+1
Maybe something
What about making side tags easily available to packagers directly? I could
build my package that includes an ABI breaking update and rebuild the
dependencies within that side tag and then submit when everything is
complete.
Richard
___
devel mailing lis
Il 08/03/2018 19:00, Randy Barlow ha scritto:
As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, similar to how we use it for our stable/branched
releases, with more relaxed rules (perhaps 1 day in testing or something
simple).
Rawhide is a place wher
On 03/08/2018 10:00 AM, Randy Barlow wrote:
> Greetings fellow Fedorans!
>
> I would like to kick off a general discussion about how we might gate
> packages in Rawhide. I think it would be nice to get something in place
> for the Fedora 29 timeframe.
I was hoping we could come up with a more det
On 03/08/2018 01:32 PM, Michael Cronenworth wrote:
> Why must the process change? It seems every bit of Fedora in the past
> year has been changing... for the sake of change.
We've had extreme issues with stability in Rawhide lately that could
have been prevented with automated testing. These issu
On 03/08/2018 12:00 PM, Randy Barlow wrote:
If you have other suggestions on how we might gate packages in Rawhide
that are wildly different than the above, please feel free to share!
Why must the process change? It seems every bit of Fedora in the past year has been
changing... for the sake o
Greetings fellow Fedorans!
I would like to kick off a general discussion about how we might gate
packages in Rawhide. I think it would be nice to get something in place
for the Fedora 29 timeframe.
As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, simi
75 matches
Mail list logo
