Re: Copr && Rawhide -- no "rolling updates" workflow
Dne 13.10.2016 v 09:37 Neal Gompa napsal(a): > On Thu, Oct 13, 2016 at 3:11 AM, Michal Novotnywrote: >> The description of Kevin is very precise. I am additionally thinking about >> implementing >> user option to rebuild all project packages for a new target when added. So >> when f27 is added, user could click one button to launch rebuild of all his >> packages >> for this target. >> >> Basically, this allows us to be one-step ahead and serve better as a system >> for rapid >> development. Instead of reacting to branching from rawhide to stable, we >> just consider >> everything immediately stable. That's because COPR is a collection of >> relatively small >> development projects. Projects that currently don't need the same kind of >> release system >> as Fedora has. >> >> I hope, I am explaining this correctly cause these "high-level" explanations >> are always >> a bit fuzzy. For me, the great advantage is that this upgrade alleviates us >> from launching >> rawhide_to_release script, which takes all user projects and copies >> everything from the >> rawhide targets into the newly branched targets. For me, the alternative of >> user-invoked >> explicit rebuilding into a new target when added is much cleaner solution >> that I can >> imagine to work well even for projects that do not even have rawhide targets >> enabled. >> > (Sorry about the Mageia spillover, but as I work in both distros and > this affects both of them...) > > I can see the advantages of this, but the COPR plugin for DNF will > need to be adjusted for this case. It currently treats systems > detected as "Fedora Rawhide" or "Mageia Cauldron" as a special case > where it will check for fedora-rawhide-* or mageia-cauldron-* chroots, > respectively. > > If you change it to always be release versions, then this will > completely break, as there will be no more "rawhide" or "cauldron" > targets. Instead, we'd have Fedora 26 and Mageia 7 (assuming Cauldron > has become Mageia 7, which it hasn't yet). > > At least from the Fedora point of view, such a change might be > somewhat painless, since right after branching, we increment the > release version. Historically Copr lagged behind after Fedora branching (e.g. after F26 was branched, it too several days until the F25 was enabled in Copr unless I am mistaken), that would mean that during the mean time, my Rawhide updates will get broken, since my Fedora will release will be bumped to 27, but there won't be repositories for F27 on Copr ... Unless this is handled somehow automatically by infrastructure during Fedora branching, I don't like this proposal. Vít > So the COPR plugin would merely need to have the > conditional removed and the COPR backend will need to have fake Fedora > 26 targets that link to the current Rawhide ones. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr && Rawhide -- no "rolling updates" workflow
On Thu, Oct 13, 2016 at 3:11 AM, Michal Novotnywrote: > The description of Kevin is very precise. I am additionally thinking about > implementing > user option to rebuild all project packages for a new target when added. So > when f27 is added, user could click one button to launch rebuild of all his > packages > for this target. > > Basically, this allows us to be one-step ahead and serve better as a system > for rapid > development. Instead of reacting to branching from rawhide to stable, we > just consider > everything immediately stable. That's because COPR is a collection of > relatively small > development projects. Projects that currently don't need the same kind of > release system > as Fedora has. > > I hope, I am explaining this correctly cause these "high-level" explanations > are always > a bit fuzzy. For me, the great advantage is that this upgrade alleviates us > from launching > rawhide_to_release script, which takes all user projects and copies > everything from the > rawhide targets into the newly branched targets. For me, the alternative of > user-invoked > explicit rebuilding into a new target when added is much cleaner solution > that I can > imagine to work well even for projects that do not even have rawhide targets > enabled. > (Sorry about the Mageia spillover, but as I work in both distros and this affects both of them...) I can see the advantages of this, but the COPR plugin for DNF will need to be adjusted for this case. It currently treats systems detected as "Fedora Rawhide" or "Mageia Cauldron" as a special case where it will check for fedora-rawhide-* or mageia-cauldron-* chroots, respectively. If you change it to always be release versions, then this will completely break, as there will be no more "rawhide" or "cauldron" targets. Instead, we'd have Fedora 26 and Mageia 7 (assuming Cauldron has become Mageia 7, which it hasn't yet). At least from the Fedora point of view, such a change might be somewhat painless, since right after branching, we increment the release version. So the COPR plugin would merely need to have the conditional removed and the COPR backend will need to have fake Fedora 26 targets that link to the current Rawhide ones. From the Mageia perspective, this is a problem. At this time, the workflow is to increment the release version for Cauldron only *after* release, because SVN makes things a bit annoying for juggling more than one release with a package. A move to Git is in the cards after Mageia 6 is released, and I suspect after that, we can more-or-less adopt Fedora's dist-git workflow, which would make such a change less painful. Thus, right now, Cauldron and Mageia 6 are identical, but after Mageia 6 releases, that won't be true. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr && Rawhide -- no "rolling updates" workflow
The description of Kevin is very precise. I am additionally thinking about implementing user option to rebuild all project packages for a new target when added. So when f27 is added, user could click one button to launch rebuild of all his packages for this target. Basically, this allows us to be one-step ahead and serve better as a system for rapid development. Instead of reacting to branching from rawhide to stable, we just consider everything immediately stable. That's because COPR is a collection of relatively small development projects. Projects that currently don't need the same kind of release system as Fedora has. I hope, I am explaining this correctly cause these "high-level" explanations are always a bit fuzzy. For me, the great advantage is that this upgrade alleviates us from launching rawhide_to_release script, which takes all user projects and copies everything from the rawhide targets into the newly branched targets. For me, the alternative of user-invoked explicit rebuilding into a new target when added is much cleaner solution that I can imagine to work well even for projects that do not even have rawhide targets enabled. clime On Wed, Oct 12, 2016 at 9:11 PM, Kevin Fenziwrote: > On Tue, 11 Oct 2016 19:14:34 +0200 > Pavel Raiskup wrote: > > > FYI: > > https://bugzilla.redhat.com/show_bug.cgi?id=1381790 > > > > Seems like the `fedora-rawhide-x86_64` chroot is not going to exist > > from now, which is IMO unnecessary change ... but what could be other > > than those "obvious" consequences for both Copr repo maintainers and > > users? Does this sound like acceptable change? > > Well, its a bit confusing actually, but if I understand it right I > guess it should be ok. > > My understanding is that there will no longer be a 'rawhide' > target/repos. Instead right now they will all become 'f26' ones. Then, > when we branch f26, those will follow the branch and new f27 ones will > appear. > > Whats not at all clear is when/if there's going to be any mass adding > the new branch and rebuilding on it, or if that is up to the user? > > Personally, I would say we shouldn't do any mass rebuilding. > If a project gets to the point where it has no builds for any active > targets we could move it to a 'archive' or just delete it as it would > indicate no one is driving/caring for the software. > > kevin > > > > ___ > 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
Re: Copr && Rawhide -- no "rolling updates" workflow
On Wed, Oct 12, 2016 at 01:11:42PM -0600, Kevin Fenzi wrote: > Personally, I would say we shouldn't do any mass rebuilding. > If a project gets to the point where it has no builds for any active > targets we could move it to a 'archive' or just delete it as it would > indicate no one is driving/caring for the software. I'd love to see non-active COPR projects automatically archived. I have some that should be. :) -- Matthew MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr && Rawhide -- no "rolling updates" workflow
On Wed, 12 Oct 2016 14:50:08 -0500 Bowen Wangwrote: > So it means that there will be no longer Rawhide version of Fedora, or > it is just a change of repo/target name. This is only about what/how copr is going to build against rawhide. Fedora rawhide is not going anywhere but onward. ;) kevin pgpteq4ptPboC.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Copr && Rawhide -- no "rolling updates" workflow
So it means that there will be no longer Rawhide version of Fedora, or it is just a change of repo/target name. Bowen On Wed, Oct 12, 2016 at 01:11:42PM -0600, Kevin Fenzi wrote: > On Tue, 11 Oct 2016 19:14:34 +0200 > Pavel Raiskupwrote: > > > FYI: > > https://bugzilla.redhat.com/show_bug.cgi?id=1381790 > > > > Seems like the `fedora-rawhide-x86_64` chroot is not going to exist > > from now, which is IMO unnecessary change ... but what could be other > > than those "obvious" consequences for both Copr repo maintainers and > > users? Does this sound like acceptable change? > > Well, its a bit confusing actually, but if I understand it right I > guess it should be ok. > > My understanding is that there will no longer be a 'rawhide' > target/repos. Instead right now they will all become 'f26' ones. Then, > when we branch f26, those will follow the branch and new f27 ones will > appear. > > Whats not at all clear is when/if there's going to be any mass adding > the new branch and rebuilding on it, or if that is up to the user? > > Personally, I would say we shouldn't do any mass rebuilding. > If a project gets to the point where it has no builds for any active > targets we could move it to a 'archive' or just delete it as it would > indicate no one is driving/caring for the software. > > kevin > > > ___ > 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
Re: Copr && Rawhide -- no "rolling updates" workflow
On Tue, 11 Oct 2016 19:14:34 +0200 Pavel Raiskupwrote: > FYI: > https://bugzilla.redhat.com/show_bug.cgi?id=1381790 > > Seems like the `fedora-rawhide-x86_64` chroot is not going to exist > from now, which is IMO unnecessary change ... but what could be other > than those "obvious" consequences for both Copr repo maintainers and > users? Does this sound like acceptable change? Well, its a bit confusing actually, but if I understand it right I guess it should be ok. My understanding is that there will no longer be a 'rawhide' target/repos. Instead right now they will all become 'f26' ones. Then, when we branch f26, those will follow the branch and new f27 ones will appear. Whats not at all clear is when/if there's going to be any mass adding the new branch and rebuilding on it, or if that is up to the user? Personally, I would say we shouldn't do any mass rebuilding. If a project gets to the point where it has no builds for any active targets we could move it to a 'archive' or just delete it as it would indicate no one is driving/caring for the software. kevin pgpa2BSFCjY8F.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Copr && Rawhide -- no "rolling updates" workflow
FYI: https://bugzilla.redhat.com/show_bug.cgi?id=1381790 Seems like the `fedora-rawhide-x86_64` chroot is not going to exist from now, which is IMO unnecessary change ... but what could be other than those "obvious" consequences for both Copr repo maintainers and users? Does this sound like acceptable change? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org