Re: [T(A)ILS-dev] Freeze ->0.7?

Delete this message

Reply to this message
Autor: anonym
Data:  
A: The T(A)ILS public development discussion list
Assumpte: Re: [T(A)ILS-dev] Freeze ->0.7?
07/02/11 18:53, intrigeri:
> Hi,
>
> Now that all serious Squeeze-related regressions I know of have been
> fixed in our devel branch, I'd like to start stabilizing a 0.7 release
> based on Debian Squeeze.
>
> The main issue I have with this process is that work has been started
> not very long ago on two pretty interesting features (wipe memory on
> media removal, minimal bridges support); big parts of this work are
> done, but it seems these features still need some more care before we
> can dare announcing and supporting any of those. I would be delighted
> if these features could make it into 0.7, but I would prefer not to
> treat it as release blockers. Also, it seems to me both are somehow
> optional, i.e. users who don't actively do anything to use one of
> these will not suffer from it being not perfect
>
> => I think we should release 0.7 with these features in half-done
>    state in case their implementation / documentation lags behind the
>    rest of the stabilization and testing work.

>
> I therefore propose merging the current devel branch into the testing
> branch and partially freeze the testing branch; changes that may enter
> testing during the freeze period would be:
>
>   A. fixes for grave bugs
>   B. fixes for not-so-grave bugs when we are sure the fixes won't break
>      anything else
>   C. non-invasive enhancements of the two features I was talking of,
>      i.e. they must not touch areas that can break other stuff

>
> I propose this merging + freeze to happen at the end of the current
> week in order to leave a bit more time to work on the two
> aforementioned features.


This sounds like a pretty good approach to me. I'm in favour.

> Depending on the state of these features at the time of the release,
> we might or might not mention it in the announcement, or announce it
> as experimental and unsupported, or whatever we feel like is
> appropriate.


I'd say we don't mention anything about them before we're positive they
work properly (I don't think we want to risk getting a reputation of
shipping half-baked solutions). We'll see if time allows for that to
happen before the 0.7 release.

Cheers!