The description of Kevin is very precise. I am additionally thinking about
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
for this target.
Basically, this allows us to be one-step ahead and serve better as a system
development. Instead of reacting to branching from rawhide to stable, we
everything immediately stable. That's because COPR is a collection of
development projects. Projects that currently don't need the same kind of
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
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
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
On Wed, Oct 12, 2016 at 9:11 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Tue, 11 Oct 2016 19:14:34 +0200
> Pavel Raiskup <prais...@redhat.com> 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
> 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.
> devel mailing list -- email@example.com
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org