Bug#507288: mails to $pkg@p.d.o should also be send to Uploaders:
On Sat, 14 Jan 2012, Stefano Zacchiroli wrote:
> > I expect that the most difficult part will be to decide how to deal with
> > the "commitment tracking" part. What should we log? What sort of
> > relationships should be defined and what should they imply (in terms of
> > default set of information provided, and of associated commitments)? Etc.
>
> This is the part that puzzles me the most.
>
> Although I was also looking forward for your proposal on keeping track
> of people commitments, I don't see the benefit of discussing the two
> aspects together into an organic proposal. They seem to be quite
> orthogonal, with very different scopes: one mostly technical /
> infrastructural, the other on the definition of maintainership and the
> (moral) requirements to be entitled to it. I can imagine some synergies
> among the two, but not that many.
>
> Considering the fact that the "commitment tracking" part might be harder
> to reach consensus upon, I fear that joining the two together might sink
> also the other part, that taken alone might have an easier way forward.
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.
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).
I would like to note that this part of the service will be entirely
optional and as such we're looking for reasonable default behaviour
in terms:
- default commitments for each role
- associated auto-prodding rules
But people should be able to opt-out from the auto-prodding part or tweak
the variables (what to notify, delays/frequency, etc.). Or even change
their commitments.
Do you still think it will be an obstacle in this discussion and that I
should separate both?
The reason why I linked both is because this infrastructure somewhat moves
the definition of is who is the (real/effective) maintainer in the
database of this infrastructure. When looking from this angle, tracking
commitments is just the continuation of that change because the binary
view "is maintainer" does not fit the reality of how we are dealing with
packages we maintain (e.g. for some packages, I will look at all the bugs,
for other I will only care about RC bugs because I just want to ensure it
stays in Debian, etc.).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: