Hi Mehdi,
On Wed, Apr 27, 2011 at 05:58:46PM +0200, Mehdi Dogguy wrote:
> Funny… reading your recent blogpost, you seem to not understand yet what
> you want to put into Rolling (and how). So, how can we comment on
> something that's not set or clearly described yet? Make a plan first, ask
> for questions later, please.
>
> There are certainly some ideas flowing here and there… but I can't find a
> document that describes clearly what that suite is!
I can try and more clearly describe what *I* was proposing, though I'm
not sure that it 100% matches up with what others have been discussing
concerning CUT and "rolling". To try to lower any ambiguity I'll
do my best at avoiding using those terms and instead stick with more
straightforward and boring terms:
* unstable always feeds to testing
* "release N" == "testing", until the "freeze".
* when "freezing" for "release N"
* "testing" is pointed at "release N+1", and no longer automatically
feeds "release N".
* a new RM controlled "release N proposed updates" area is opened, which
feeds into "release N".
* packages migrate from this area to "release N" in a manner
similar to how unstable would feed into testing during previous
freezes (i.e. soft-freeze, hard-freeze, etc, __entirely at the
discretion of RM's__).
* this area would autobuild only with itself and "release N"
build-deps.
* RM's can still choose to migrate packages from (not frozen) testing as
long as it's practical to do so.
* When deps/transitions/etc prevent testing migration, "release N
proposed updates" is used for one-off bin-NMU's and/or sourceful backports.
* at "release time" for release N
* remaining packages in "release N proposed updates" are either migrated
to release N or deleted.
* "release N proposed updates" is basically s-p-u at this point
What I see as the benefits of this:
* no more freezes, or periods where the fun new things slow down.
* releases can happen faster if we want them to, because "release N+1" has
been moving along all the time.
* no major earth-shaking changes to how the rest of the project works
Attempting to be self-critical, the problems that I see with this approach:
* developer share is splintered, some people might not be as interested in
helping prepare "release N" and focus only on unstable, or vice versa. this
is a given with any "paralellizing" solution though.
* user/tester share is splintered. likewise a given. most important would
be having enough people testing "release N proposed updates".
* parallel process means some (hopefully minimizable) overhead for the RM's
But I'd think that we could work past these problems. Of course I'm
not entirely objective so others may disagree or there may be further
shortcomings.
> For example: What would be Rolling's content right after a release?
> (comparing to testing, which starts from the stable just released). I
> guess you cannot merge because testng will be lagging behind a bit. You
> cannot just get what's in testing and restart from fresh, because there
> might be users that won't like it. If you continue, there will be no
> relation with testing anymore. The two suites will have their own set of
> problems, I guess.
I think the above should clarify this.
So maybe that could be taken as a starting point for further discussion?
sean
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110427175332.ga14...@cobija.connexer.com
