[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [etch] Update about localechooser



Christian Perrier wrote:
> For avoiding confusion, localechooser is still kept in /people/bubulle
> in the SVN repository. The checkout command line is:
> 
> svn co svn+ssh://svn.debian.org/svn/d-i/people/bubulle/localechooser 
> 
> It will be moved to trunk/packages as soon as d-i RC2 (or whatever it
> may be called) is released. I will then upload a first vesion, wait
> for ftpmasters to accept it....and immediately change the
> installer/build/pkg-lists/<type>/common files for using it in daily
> builds.

Very nice job on localechooser. (One question: Have you looked into how
many places assume en_US is a sort of C locale, and would need to be
changed to support a real C locale? IIRC there are several.)

It does seem that we will soon want a branch in the repository for
developing things that won't be targeted at the sarge release. IIRC
Colin will show us the wonders of a d-i patch to swap out devfs for udev
soon. I've been thinking about how to set up the branch. The obvious
thing to do is to make a sarge branch and open trunk up for etch
development.

However, I'm leaning against this because I imagine that it could be a
while before sarge is released (hope not), and lots of interesting and
unstable things could be developed in the meantime. Or perhaps already
have been. If we throw all of these into trunk and into etch, right away
when sarge releases then we could leave etch without a working installer
for a while as the bugs get worked out.

Recall that sarge began as a copy of woody after woody's release and
gradually things filtered into it from unstable, it did not begin as a
copy of unstable with all the changes that had acumulated there in the
last months of woody's release cycle. Similarly, we may not want to
throw all the development code into etch and our etch branch right away,
and I assume the right "branch" to use for etch is trunk.

So I think we should split off an experimental branch and put
developmental things in there, keep trunk for sarge until sarge is
actually released, then make a sarge branch and trunk begins to be used
for updates, but only ones we know are reasonably safe and are ready to
upload to unstable and to etch.

This probably calls for some special experimental d-i images built from
the experimental branch to let us test what's in it. Perhaps we could
use udebs uploaded to the experiemental distribution for that (which is
why I'm calling the branch "experimental" too). Doing things with that
extra branch could result in more work if we have to merge fixes up from
trunk to experimental. But it seems worth it to have an installer for
etch (and an updated one for sarge!) that is always in working order.

-- 
see shy jo, who likes typing "etch" more than "sarge"

Attachment: signature.asc
Description: Digital signature


Reply to: