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