Re: Log from the November 16th 2009 D-I team meeting
On Thursday 19 November 2009, Christian Perrier wrote:
> Quoting Frans Pop (elendil@planet.nl):
> > On Monday 16 November 2009, Christian Perrier wrote:
> > > The attendance was low (Otavio, Marc Hymers, "blindvt"...mostly
> > > lurking, and me) but we could put in light the current blockers for
> > > the release: mips kernel udebs that need NEW processing, plus
> > > cdrom-detect and di-utils builds and transition to testing.
> >
> > I'm very surprised that the fact that the graphical installer is
> > completely broken is apparently not considered a release blocker.
>
> You're right. Apparently nobody is currently caring about the
> graphical installer. Up to the point where we even forgot to talk
> about it during that meeting. :-(
>
> I agree this can be considered a release blocker, but do we still have
> one person currently able to even *identify* where problems are? If we
> don't, then we should maybe conclude that we are currently unable to
> maintain g-i. That will make an 'interesting' announcement to
> make....("D-I team announecs the intent to drop support for NN
> languages by dropping the graphical installer").
The problem is not "able". The real problem is that the "release management
team" simply does not seem to care about such issues.
I can tell you the cause of the regression without even having looked at
it: the upgrade of one of the libraries (gtk, cairo or directfb; my guess
would be the first in this case).
The problem would likely already have been solved if someone had even
bothered to identify which upgrade caused the regression after the first
report by a user, and had reported the problem to the library maintainers.
And all that needs is doing a few local builds using previous library
version (while they probably are still available in testing).
The real problem is that the regression has been completely and utterly
ignored by the "release management team". There has not been a single mail
to this list mentioning the issue; there has not been a single call for
help; it has not even been listed on the D-I today page.
How do you (not you personally, but you as a team) expect others (like the
library maintainers) to jump in and help if you (the team) don't *ask* for
such help?
These issues do get more difficult to solve the longer you wait. Why?
Because it gets harder to identify what package caused the regression.
Because other maintainers won't care as much if its an older regression
You have been reading the old mailing lists. Remember coming across mails
from the previous RMs alerting the team in general to such issues and
trying to get people who worked on such issues previously to help out?
Remember previous RMs repeatedly reminding people that "hey, we have a
serious issue here; please someone look into it otherwise we won't be able
to do a release"? The fact that the current "release management team" is
not keeping track of issues and making an effort to get others to help
solve them is the main reason of things regressing so badly.
This is not a difficult problem. This is a release management and team
leadership fail.
And if you're talking about "able", then I would guess that Otavio would be
able to identify the problem. But you won't hear me say that he should
necessarily do the work. This is not about solving problems, the is about
*getting* problems solved.
Release managers have to be proactive about getting regressions identified
and solved. Moaning that "apparently nobody's able to do anything"
*months* after a problem first occurs without having made any effort to
get help to solve an issue is a gross negligence of your own duty as RMs.
Just my opinion of course.
BTW, remember #543590? I don't think that's the cause of the issue
(directfb 1.4.1 is still in experimental), but that bug is still open.
I took the trouble of testing that new version and repporting it. It was
also announced on this list. Were you (the RM team) even still aware of
that BR? It's part of the job of release management to keep track and
follow up on such things.
Reply to: