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
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
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.


On Wed, Oct 12, 2016 at 9:11 PM, Kevin Fenzi <> wrote:

> On Tue, 11 Oct 2016 19:14:34 +0200
> Pavel Raiskup <> wrote:
> > FYI:
> >
> >
> > 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 --
> To unsubscribe send an email to
devel mailing list --
To unsubscribe send an email to

Reply via email to