When to move updates from testing to stable
Michael Schwendt
mschwendt at gmail.com
Thu Oct 30 18:54:11 CET 2008
On Thu, 30 Oct 2008 16:12:35 +0100, KH KH wrote:
> > On Thu, 30 Oct 2008 13:19:57 +0100, KH KH wrote:
> >
> >> I was suggesting to duplicate the buildsys (cvs builroot etc) to
> >> another repository as described here:
> >> http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/001507.html
> >> That's not a problem with following Fedora rules, but covering the users needs.
> >>
> >
> > Duplicating sounds like forking to me. Forking the project at several
> > points.
> This wording sounds like mixing the discution and decision, as nobody
> here wants to fork.
> At least a more correct wording would be "extending capabilities."
An additional build target for an additional repository would be possible
inside the _existing_ infrastructure by means of reconfiguration. It would
not be necessary to "duplicate the buildsys (cvs buildroot etc)".
The fork is due to the nature of alternatives, and due to the missing
guarantee that stuff from the experimental branch will find its way into
the next main tree. In other words, experimental packages published for
Fedora 9 might still be experimental or even unusable when Fedora 10 is
released. Upstream will work with upgrades, too, and it may be that you
cannot continue with building experimental pkgs for Fedora 9 at a point
when Fedora 9 is not new enough anymore. In either case, it wouldn't be
Fedora N + RPMFusion N (free<-nonfree) any longer, but a choice between
either
Fedora N + RPMFusion N
or:
Fedora N + RPMFusion N -Experimental-
Typically, you only run one, not both. And even if you run both, you spend
more time on one than the other one. Just like your primary desktop, which
you use day by day, is one specific version of Fedora and not many. Because
if you focus on Fedora N, you neglect Fedora N-1. Or you allocate some
time to look at Fedora N+1, as it may be more exciting, but that reduces
the time you spend on Fedora N and Fedora N-1.
With upgrades, try to target the latest Fedora N+1, and if the pkgs
don't work satisfactory to be included, it is not worthwhile to try
publishing them for an older Fedora release.
More information about the rpmfusion-developers
mailing list