Follow Up from "Let's Discuss Interim Releases"

[Scott Kitterman]

On Saturday, March 09, 2013 08:31:09 PM Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/09/2013 03:09 PM, Scott Kitterman wrote:
> >> 2)  Rather than upload to raring, then freeze, then release
> >> raring as stable, change the model slightly so we have uploads
> >> going to the "unstable" release.  Then say, 3 months prior to the
> >> deadline for the new stable release, we open a new archive for
> >> that release, and copy the unstable release to it.  Then bugs
> >> would be fixed in the stable release, while new development can
> >> continue concurrently in unstable.
> > 
> > Your option two seems somewhat similar to the situation we end up
> > with now when just after release, we don't have a development
> > series and SRUs are uploaded to the current release and later
> > forward copied to the development version when it's ready.  This
> > can be a pretty labor intensive, error prone process.
> 
> No.  Under that option there would never be a time where we don't have
> a development release.  It would always exist and, I propose, be named
> simply "unstable".  Bugs found during the freeze would be first fixed
> in unstable, and the fix backported to stable, just as we do now with
> SRUs, though with more relaxed requirements since it wouldn't be a
> stable release yet.

There's still the requirement to keep things in sync.  That's what I was 
referring to.  Also, for many common targets for SRUs/late bug fixes that are 
actively maintained, the packages in the development release would quickly 
diverge and so you'd still have to do two sets of patches.  Except for reduced 
QA requirements, it doesn't seem to offer much over release and SRU and I'm not 
sure reduced QA is actually a feature.

Scott K