Bug#723641: pu: package xen/4.1.4-5
On Wed, October 2, 2013 19:21, Bastian Blank wrote:
> On Tue, Oct 01, 2013 at 04:58:43PM +0200, Thijs Kinkhorst wrote:
>> On Mon, September 30, 2013 18:52, Bastian Blank wrote:
>> > I don't think this will work. The current security process ignores
>> > any communitation that is otherwise part of the NMU process. As long
>> as
>> > the security team does not have some policy to cummunicate first and
>> do
>> > later, especially if the maintainer is already in the loop or, worse,
>> > did it herself, I see not why this should work now.
>> I think you're confusing miscommunication that happened, with a policy
>> of
>> not communicating.
>
> Why are there no NMU diffs in the BTS as mandated by the developers
> reference? Why do people prefer doing stuff themself instead of
> communicating?
>
>> Something went wrong in the past, I don't know why, but there's
>> definitely
>> no process to ignore communication that should happen when working with
>> other people's uploads.
>
> It happened with different people, I remember three. This is called a
> pattern. Patterns leads to informal policies.
Alright. I cannot easily verify the specific cases, but I think we can
resolve that at least from now on, there's no intention nor informal
policy to not communicate with people that are preparing uploads. And I
think we could find many of your DD-collegues that communication indeed
happened around the uploads they proposed.
>> > My main problem are the missing mails on uploads. If the ftp-masters
>> > refuses to accept a patch---did they?---you have to do it by human
>> > relay.
>> We definitely do this by human relay. We missed one, there.
>
> The person explicitely handling this case missed it also.
It's a pity and shouldn't have happened. I will not say that communication
will always be perfect and that no issues will be dropped. I hope all
parties involved will remember the human factor, and that if they perceive
a communication problem they proactively enquire, they ping the other
party, even if the ball is not strictly 'in their court', to ensure it
doesn't run out of hand. I think we can expect that from all contributours
in our project.
>> All in all, I recognise that mistakes have been made but I do not think
>> that they are 'a policy' by the team. I'm confident that it's possible
>> to
>> work together in a way that works for both parties. Why not just give it
>> a
>> fresh new chance?
>
> Why do you ignore what I wrote in my original mail? This where the
> three points:
I thought I'd addressed it, but here we go.
> | - Fix dak to send mails, at least to the uploader and signer.
>
> Should be a small patch to dak. Did noone try it or was it rejected?
> If it was rejected, why was CTTE not involved? It is even listed as a
> bug somewhere.
I don't know all the history of this request, but have asked ftp-master
what they would think of it, so we get a fresh idea of where we stand.
> | - Push NMU-diffs to the BTS.
>
> This is a long-standing point. And I never got an answer why this is
> not done.
I'll discuss it in the team. Of course, the information is always
available from the archive, so it's there now, but I agree that a NMU diff
in the BTS makes things slightly easier on the maintainer. I left it out
initially because I thought we were discussing issues where the maintainer
was already involved, and in such issues, NMU diffs were not so relevant.
I'll let you know the outcome of this.
Cheers,
Thijs
Reply to: