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

Re: buildd administration



Anthony Towns <aj@azure.humbug.org.au> wrote:

> On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote:
>> > No, that would be "unsuitable for release". Which is a problem that
>> > should either be fixed quickly, or means you're trying to make a big
>> > enough change that you should be working out how to get it done without
>> > breaking other packages in a separate area, such as experimental.
>> It's been in experimental for more than half a year.  
>
> Err, that's kind of absurdly long too.

Yes, I had a three months no-Debian-work-at-all break, and slow progress
due to real-life issues after that, too.

>> We could have tried to install and use every depending, and build every
>> build-depending package.  But that is simply not feasible with the
>> manpower, time and machine power that's available to the teTeX
>> maintainers. 
>
> Six months is a lot of time; and experimental should provide you with
> the space and machine power to handle the rebuilding. 

I don't know of any autobuilders that build packages from sid against
build-dependencies in experimental.  

> I don't know how
> many source changes are necessary to do the rebuilding, though.

None for the bugs found so far.  The library issues will have to be
handled later.

>> Of course, in principle, we could have created our own
>> "compatible_with_teTeX-3.0" repository and uploaded fixed packages
>> there, and do all the testing there.  But then I don't understand what
>> unstable is for...
>
> Generally, experimental fits the above role. Unstable's for uploading new
> development of packages that will hopefully work, but might turn out not
> to. In particular, though, they need to be fixed pretty quickly -- six
> months in experimental, and another two so far in unstable isn't quickly.

There are no real RC bugs in tetex, and haven't been most of the time.
The RC bugs are in the large number of packages that depend on tetex,
and sometimes break tetex-bin's installation, sometimes only themselves.

> "A far-east document is typeset in a certain encoding" doesn't sound like
> an RC bug; and therefore not something that should hold up transitioning
> to testing. 

The package with the RC bug is debian-reference, which builds documents
in different languages from sgml source for its binary packages.  If
this package fails to create one of its documents, this is a FTBFS and
of course RC.

>> > A year before sarge's release, we were at around 400 RC bugs in testing,
>> > and 600 in unstable; 
>> Err, that should read "3 months before everybody thought sarge would be
>> released. 
>
> Uh, no, it shouldn't. Next December is when sarge will be released,

A year before sarge's release was June 2004, and at that time all
unenlightened DDs believed we would freeze on August 1st (or something
around that date) and release in September + x.  For that very reason I
handled teTeX much more conservatively than I had done had I known that
I had one year left[1], and had I known the truth I would have made
changes (namely upload the betas of the upstream version now in
discussion) that would have raised the RC bug count for a while.
Instead I was *extremely* careful (and did lots of duplicate work).  I
expect that others had acted similar.

That doesn't mean that I will now act as if etch would be released with
a 1-year-delay, too - on the contrary, just as I did with sarge.

> That's true; the idea isn't to let it rot in experimental, it's to have
> a quick pass through experimental that catches the most obscene bugs,
> then to put it in unstable where you catch a few more, then to let
> things progress to testing naturally, if necessary by having the RMs
> remove tetex related packages that aren't getting updated to the latest
> version in a timely or successful fashion.

That sounds all very nice.  But currently, I didn't even have time to
build a lists of packages we filed RC bugs on, and track whether they
have been properly fixed.  Before that I can't judge whether it should
proceed to testing, or which packages would need to be removed.

I (and some others) manage teTeX as a volunteer in my free time.  If
Debian thinks that this is not enough, it should either help us with
manpower or drop teTeX and depending packages.  Just ranting at how we
handle the package doesn't help us, our users or the release process.

Regards, Frank


[1] and I have no indication that the RC bugs count had any influence on
the sarge delay between summer 04 and march 05.
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer



Reply to: