Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Pierre Habouzit a écrit :
> On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote:
>> On a personal note, in my experience the most effective way of working
>> with James and Ryan is to trust that they generally know what they're
>> doing and more or less leave them to get on with making things better on
>> their own rather than hassling them for status reports or similar.
>
> Well, that leave one obvious question then, are they the best people
> for the job ? because I'd really prefer people that work 10% less, to
> communicate what they do in the other 90% of their task, so that
> everyone knows what's going on, and can plan their own job decently.
>
> My point is, many tasks in debian depend on what DSA/DAM/... do and
> especially when. Event if (for the sake of the argument) I admit that
> things get eventually done, the unknown time part _is_ generating a
> _lot_ of frustration.
>
>> "Just leave them to their own devices" isn't something you'll see
>> recommended in management books, but when people are doing stuff that
>> they care about for fun, it's worth considering.
>
> This is just handwaving: letting them in their dark corner because
> they work faster like that, is not related to the issue that is debated:
> no one says james or ryan are lazy, the problem is almost nobody know
> what and when they are doing it.
>
>> A downside is that it makes it hard to know how to help,
>
> We're far beyond trying to help them, at least for me, I just want to
> have ETA's and communication because this is how people work together.
> Their work (or absence of, or delays of, or ...) are impacting the work
> of every single DD out there, and that sucks.
>
> Do you want a Simple example ? For almost 4 or 5 months (if not more)
> there is no Alpha machine available to developers, one being restricted,
The machine is locked since the compromise in July 2006. So that's
almost *8 months*.
> the other in lock down, waiting for a setup I guess (<-- did you remark
> the I guess ? I mean I don't know what's going on, and nobody knows
> afaict). The "problem" is, I'm now helping packaging the glibc, and we
> have a couple of alpha-only bugs. Things really stupid like headers
> problems, that would almost take a full minute to be fixed. BUt that bug
Well the glibc in testing/unstable is not really a problem as it is
currently frozen (though it would have been possible to release Etch
without those bugs).
The problem now concerns glibc 2.5 (or later) which will be the glibc
for Lenny. I think the easiest solution is simply to *not* consider
alpha as a release architecture for Lenny from the glibc point of view,
and ignore bugs (but accept patches). After all this architecture fails
one release criterion.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: