Announcing Fedora Activity Day - Fedora Development Cycle 2009

Bruno Wolff III bruno at wolff.to
Tue Jun 2 06:17:49 UTC 2009


On Tue, Jun 02, 2009 at 00:45:32 +0200,
  Kevin Kofler <kevin.kofler at chello.at> wrote:
> 
> I think it's a bad idea to delay the releases more than necessary for
> marketing reasons. IMHO we should release as soon as technically feasible.

I think the release is really a marketting event anyway. Assuming there
wasn't an install or driver issue affecting you, people could have been
running F11 since the preview without getting a much different experience
than what you'll get with the release. And even then the release is
going to be modified by the updates (there are around 900 updates available
in stable, testing and pending for F11).

> It means people can go from Rawhide to the release without service
> interruption. The way it is now, once the release is finalized, the mirror
> list redirect of the release tree to Rawhide gets turned off (because
> Rawhide moves on to the next release), but the Everything directory gets
> opened up only a few days later, on the official release day. That means
> people cannot install packages from the Everything repository (which can
> also affect updates because they can add dependencies) for a few days.

I agree that using the same pattern for development releases would make
transitioning between development and production. This helps those of
us that don't continously track rawhide, but often switch to it at some
point during the development cycle. It also makes working with mirror
scripts easier as you can base things off the release version and not
have to worry about the changes in mirror paths between releases and
rawhide that currently exists.

One downside would be people less familiar with Fedora accidentally grabbing
stuff from the develpoment trees not realizing that they were development
trees. But that seems like an unlikely path for people new to Fedora to
get started.

Another potential downside would be for people always wanting to track
rawhide. But this might be handled by having a symlink from rawhide to
the highest numbered release that gets changed everytime a new release
is branched.




More information about the devel mailing list