Bug#723641: pu: package xen/4.1.4-5
On Mon, September 30, 2013 18:52, Bastian Blank wrote:
> On Mon, Sep 30, 2013 at 04:38:24PM +0200, Thijs Kinkhorst wrote:
>> Thanks. I've read them. My conclusion is that there are two problems:
>> 1/ On a previous upload, someone from the security team added extra
>> changes without coordination or reporting them back.
>> 2/ It took long to process the upload and there was no feedback on
>> problems.
>> Agreed?
>
> No. This are symptoms, not problems. The main problem is
> _communication_.
>
>> On the first point, although I don't know exactly what changes were
>> added
>> by whom, I fully agree that if such is the case that's not good and
>> understanding that it's annoying to you. I'm sure that we can agree that
>> this was a mistake and that this should not happen again.
>
> 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. There is no such policy and we communicate a lot with
maintainers that already work on the package on a daily basis. As with all
communication, this is never perfect and some side may accidentally make a
mistake.
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. Of course there's a bit more complication when
there's an embargoed issue, or when the issue is so critical that
immediate action is unavoidable, but for regular, unembargoed issues,
where the maintainer is already involved, we should not do anything to
change their package without consulting them.
>> The second point is indeed unfortunate, reading back it seems related to
>> two different problems with DAK.
>
> 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.
>> Given the limitations of tools and manpower and the large number of
>> issues
>> that we need to deal with, the process will probably never be perfect.
>
> If you lack manpower, why don't I remember any calls for help like the
> ftp-team or ctte did?
We have in fact on several occasions done so, and are adding new members
to the team from time to time; the source mostly being people that start
to work on the security tracker. We do try to make this starting point as
easy as possible. The influx of people that actually stick around for
longer is not very high. But we could probably indeed call for help more
often, you're right.
(The call for adding someone to the tech ctte does not seem to have had
any measurable effect to date, despite it being done over a year ago, so
I'm not sure that's a good example of how to call for help.)
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?
Cheers,
Thijs
Reply to: