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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c6f733eecbcfa0eb42798f43b3b5c7a4.squir...@aphrodite.kinkhorst.nl
