Does anyone actualy read mails from the release-team?

| 3 Comments | No TrackBacks

Yesterdays statistic from debian-devel-changes:

17x "New upstream release" with only 2 packages actualy fixing bugs!

5x "Initial Release"!

Guys, that close before the release, use experimental, that is what it is for. And it gets autobuilded for almost all architectures (1 buildds (s390) currently down).

Thanks for helping to get the release out in time.

Share this blog post:   

No TrackBacks

TrackBack URL: http://blog.zobel.ftbfs.de/cgi-bin/tb.cgi/44

3 Comments

For some values of "upstream" and "release", a new upstream release might be a nice bundle of bug fixes that would really be good to be getting into etch. The kernel comes to mind, even that far in the release process.

And you also have the balance the "initial releases" going through with the impredictability of NEW.

Beside, and IMO, one feature of the testing migration system is to allow continuous development.

But you've got a point in that efforts should not be directed at preparing major new upstream releases now, but at stabilizing etch.

Aurel, some archs currently have weak-no-autobuild set for glibc. I will try to remove that now.

One problem with the experimental autobuilders is that i386 isn't autobuilt at all. As I'm uploading experimental packages on amd64, it means someone with a i386 box has to rebuild them.

Another problem is the broken build-dependencies parsing, which requires overly-long build-dependency lines specifiying each experimental binary package which appears in the dependency tree. When you're building nautilus or epiphany, that makes the task virtually impossible.

Leave a comment

March 2014

Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31