On Mon, Jan 16, 2012 at 08:28:59AM +0100, Raphael Hertzog wrote:
> You're probably right that I should deal with them separately. But in
> truth, this part is the one where I see the most long term benefits for
> Debian because MIA tracking, knowing who is responsible of what, and
> what you can expect of everybody is a major problem in Debian. It's not
> normal that we have a so large number of release critical bugs.
Mostly agreed, yes.
> So while the benefit of the infrastructure to fix the information flow is
> nice, it's not a game changer IMO (although it's an important step to
> make collaborative maintenance the usual default within Debian). Whereas
> that second part could be (if well done).
<snip>
> Do you still think it will be an obstacle in this discussion and that I
> should separate both?
I gave it a bit more thought, but yes, I still think separation would be
better. Even if the infrastructure change would not be a game changer,
you can see it as a dependency of the role/commitment part.
I do understand why you don't want to go for the role/commitment part
without having the infrastructure part. But at the same time I don't
understand why you couldn't go for the infrastructure part *first* and
then for the role/commitment part. And given I see some risks in going
together (e.g. tarnishing the benefits of the infrastructure parts in
the eyes of those who disagree with the role/commitment part) I would
prefer to keep the two separate.
Anyhow, the above is just feedback. If you think the two could be
handled together and are willing to invest some time in trying, by all
means, go for it.
... and thanks again for raising these important topics.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature