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

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)



On Fri, 30 May 2008, Richard Hecker wrote:
> In years past, I would route all email through an employment
> account (I basically lived there anyway and it was the best option
> to assure timely reception and response ;-). In this environment,
> it was common to remind people that vacations could last a week
> or two. It was amazing how often people were inclined to push
> the panic button because they had waited a few days for a
> response.

We do have a process for maintainers so that they can mark themselves as
beeing in vacation. We do also encourage since quite some year
co-maintenance so that if one maintainer is absent, there's still someone
else around.

Please come back in 2008! ;-)

You speak as an "elder" that doesn't want to move forward and you have
failed to explain why mailing the BTS doesn't achieve the same results
than mailing the maintainer.

You could have told that you have different filtering for BTS mails and
direct mails. This is something we can understand, as such we could decide
to put a direct CC to the maintainer to the mail that is sent to the BTS
in order to resolve your concern.

But no, you prefer to not explain your problem... this is no way to
participate in such a discussion. Don't be opposed to something if you
can't come up with a rationale of why it's bad.

> DEP1 reminds me of those days. If you eliminate the goal of
> contacting the maintainer first, you can easily push through the
> NMU via one of the DELAYED queues. We are left to rehash all
> those old arguments about how long is too long and why
> someone needs such a long vacation. Although it may seem
> like a dirty word to you, I do suspect that these arguments were
> worked out when the developers reference was first put
> together.

And times changes... as one of the people who maintained/maintains the
developers-reference, I totally agree that this DEP is welcome
and that we should reword the developers-reference in that regard
because the practice of NMU changed a lot since the release team
created the 0-day NMU and so on. And not all NMU are of equal importance.

> I just do not see the value when some Johnny-come-lately decides that
> all the decisions need to be reworked.

Please stop this pissing contest... I can claim a longer history of
participation than you, but this doesn't bring anything to the discussion.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


Reply to: