RFC : in-development flag for packages

Stephen John Smoogen smooge at gmail.com
Wed Feb 25 18:14:34 UTC 2015

On 25 February 2015 at 06:41, Stephen Gallagher <sgallagh at redhat.com> wrote:

> On Mon, 2015-02-23 at 17:03 +0200, Yanko Kaneti wrote:
> > On Mon, 2015-02-23 at 14:39 +0000, Petr Pisar wrote:
> > > On 2015-02-22, Yanko Kaneti <yaneti at declera.com> wrote:
> > > > Introduce an "in-development" flag for packages in Fedora.
> > > >
> > > I like the confession that no in-developemnt code gets magically
> > > stable after
> > > half year of sitting in the Rawhide.
> >
> > Indeed that was part of my thinking.
> >
> > In-development packaging that might never reach maturity is a fact
> > of life and the idea was for us to embrace it and manage it in the
> > same place where we manage everything else.
> >
> > Thanks for the feedback.
> I'm somewhat of the opinion that code should never land in Rawhide
> that isn't stable upstream (or expected to be within that Fedora
> release cycle). Code that isn't ready and won't be ready in time
> belongs in a COPR.

I have a couple of questions.

1) Does this change how most (or a sizable group of) developers see what
rawhide is meant for?
2) To what extent does the COPR process need to be made more production
ready and integrated into the build system to make those developers want to
use it?

The COPR code is well done, but the resources it relies on are not. The
cloud it runs on is a "this is something we work on when we have free 10
minutes" versus a "Saturday through Sunday 24/7/365" utility that we treat
the main builders. As long as we aren't treating the COPR builders at that
level, most developers are going to do builds on the main builders on the
off chance that something is wrong or worse yet slooow. They will then just
push to rawhide since it is an easy workflow.

Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150225/34e88b52/attachment-0001.html>

More information about the devel mailing list