On Mon, Jun 02, 2008 at 02:07:57PM +0200, Frans Pop wrote: > On Monday 02 June 2008, Bas Wijnen wrote: > > > > No, I don't, I agree with you that this would be unacceptable. > > > > > > Right, and that is where our opinions _do_ differ fundamentally. > > > > You don't agree that I agree with you? > > OK, I misread that. Sorry.
No problem. :-) > The fundamental thing we disagree on is that you think creating a patch > and doing an immediate upload to DELAYED is an acceptable workflow for > any kind of issue. Yes. Not recommended, but certainly acceptable. With a long delay, of course. > I think that is unacceptable and I think I have made my arguments for > that clear enough by now. I still don't understand what the problem is that you have. I'd like to get this cleared up, otherwise we may continue to have misunderstandings. If I want to create a package, then I will do that. What would you recommend me to do? Tell you about the problem and hide the package for some time? What is so special about the DELAYED queue that makes a package in there different from a package on my local hard drive, waiting to be uploaded in case the maintainer doesn't reply (or accepts it)? What if I schedule an at job to upload it? Must I not tell you that the upload will (if needed) be done by atd, and suggest that I will personally come back to it? To avoid more misunderstandings, I'm very much opposed to hiding patches or information like "I will make sure an upload happens at that moment if you don't reply". The delayed queue is a tool which makes it possible to "make sure" of such a thing without manual intervention (unless it needs to be cancelled). You seem to want to forbid using this tool in some cases. I am asking you what the purpose of such a restriction would be. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature