Re: Pre-release feature freeze for trunk

Am Donnerstag, 15. Juni 2006 07:34 schrieb Benjamin Schieder:
> Stefan Fiedler wrote:
> > Hi all,
> >
> > here's my first proposal for an official feature freeze of trunk as a
> > preparation for the next release:
> >
> > <quote>
> > When preparing source releases, the core developers set a Feature Freeze
> > on the core parts of trunk, which means that
>
> Core parts meaning anything not flagged CORE as well as scripts/ misc/
> architecture/ and so on?

I'd describe core parts as: anything flagged CORE as well as scripts/,  misc/, 
architecture/, and bootdisk and Crystal targets.

Or, with the wording of the Mission Statement:
- the framework, tools and basic packages, and 
- the Bootdisk and Crystal ROCK Targets 

>
> > * only bug and security fixes are applied until trunk is found stable and
> > well-tested enough for a new release.
> > * Package updates can be applied if they contain bug fixes only, or
> > security fixes - adding features should be avoided, to prevent
> > introducing new bugs (in other places).
>
> Sounds good.
>
> > Source releases are named by their respective revision numbers. Official
> > binary releases are based on source releases and created by core
> > developers.
>
> What's the naming scheme here?

You mean for official binary releases? I think some textual description will 
do, like the target built, the revision (source release) it's based on and 
the non-default config options used (e.g. architecture, optimization)...

>
>
> What tests should be conducted? What must work for a release? What doesn't
> need to work?

For now I've meant to apply the same test procedure as already mentioned in 
the mission statement.

>
> - target/* ?

Bootdisk and Crystal targets are first candidates for official releases. As an 
option, core developers may decide to create official releases of other 
targets, if e.g. the target maintainer doesn't do that already...

> - x86? alpha? sparc? x86_64?

Nothing said about architectures yet. I'd like to see binary releases for 
many, but we'd need developers with the required hardware first. Cross-builds 
of bootdisk and build-bootstrap are possible, but would still require some 
real hardware (or good emulator) to test them.  I.e. "We do Crystal ROCK and 
other Binary Releases as we see fit."

>
> What about maintaining releases? Security fixes and stuff.

Currently there's only: "We issue Security Advisories and maintain Errata 
Documents." 
I'm not sure on how to maintain errata documents yet, but that's another 
topic :) This is about the feature-freeze (pre-release) phase and what are 
source and binary releases.

> What about gem repositories for Crystal releases?

Releasing binary packages for updating would be cool, esp. if we had an 
automated build server that did most of the work. But first we'd need a place 
to upload gem repositories to...
Afaik the build-bootstrap packages will be available for download as single 
packages. But I didn't want to make that mandatory (yet).

I'm very reluctant to make promises that probably cannot be kept (e.g. because 
of lack of time, resources, man-power, or developer interest).

After all my text is only a first proposal, and can and should be changed as 
appropriate.

With best regards,
	Stefan Fiedler

>
>
> Greetings,
> 	Benjamin
>
> --
> Benjamin 'blindCoder' Schieder
> Registered Linux User #289529: http://counter.li.org
> finger blindcoder-1k+CIuW/[email protected] | gpg --import