Re: Debian Debconf Translation: Compromise (was: Debian Debconf Translation proposal ( again ))
On Fri, Jan 09, 2004 at 12:44:21PM +0100, Dominique Devriese wrote:
> 4. The good old string freeze. I don't personnally understand
> Wouter's "Ha !" comment, but I'm sure he'll be willing to expand
> upon this ?
Hrm.
You mean a freeze where normal development can happen, as long as no new
messages that would need new translations are added, right?
I don't think that fits; we traditionally try to allow people to upload
anything to unstable at all times -- as long as they reasonably expect
to be able to fix any major problems in it in a timely fashion, and
that it'll be generally usable and so forth at any rate. This doesn't
even really change during a release -- either we manipulate testing to
ignore the stuff we don't want added, or we get people to upload the
stuff they think's ready for release to a different area.
The only way I can see to fit a "string freeze" into that model is to
do a full on freeze -- have every upload that's intended for release
go to "frozen" (or "testing" or whatever), and break testing off from
unstable completely.
Now, that's not impossible, but it's very costly: it requires someone
to review every change that's made. Which is a long way from "normal
development continues with minor exceptions".
Do we want a string freeze just for debconf templates, or for man pages,
info files, and descriptions? It might be reasonable to freeze templates
in unstable for a shortish period, but I don't think it'd be reasonable
to freeze documentation for any useful length of time.
I guess the alternative would be to setup something like:
Day 1: Cleanup freeze begins. No uploads that aren't approved
by RM team will make it into the next stable. Uploads
will be approved that fix security bugs, and translations
for packages that have been last uploaded less than four
weeks ago. Other uploads that include important fixes may
be accepted.
Day 15: Security freeze only. Uploads will only be accepted that
fix security issues.
Day 30: Release
This would mean the translation team would have to have someone collating
translations for packages and NMUing them, and that they'd have to be on
the ball enough to have already uploaded translations for things that
haven't changed in the past month, and to finish off everything in a
couple of weeks. It'd have to be NMUs in at least some cases, because
a couple of weeks probably isn't enough time to coordinate with all
maintainers. It'd have to be a couple of weeks, because without britney,
a separate distribution is just too much of a nuisance to maintain. And
it'd have to be limited to packages that have recently been uploaded
to ensure that we don't come across any unknown FTBFS problems due to
changes in the toolchain.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we can.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Reply to: