On Sat, Apr 27, 2002 at 03:03:35PM +1000, Anthony Towns wrote: > On Thu, Apr 25, 2002 at 10:07:40AM +0200, Marcelo E. Magallon wrote: > > >> Anthony Towns <aj@azure.humbug.org.au> writes: > > > Unfortunately transparency requires having the time and desire to deal > > > with the mindless flamage that always results... > > That's fair. I sympathize with the argument "I don't have time to do > > this right now and I won't do something that will later require more > > time from me which could be better spent doing this and that". But > > then again, ftpmaster should also sympathize with the maintainer who > > spent time packaging something. If ftpmaster has a problem with a new > > package, then say so: "That license doesn't look free to me". Ignoring > > enquiries made after a reasonable ammount of time is wasting both > > ftpmaster's time and the maintianer's. > > Uh, the whole point of ignoring enquiries is that it wastes far less of > the ignorer's time than responding to them. It'd be nice if this were > otherwise, but it isn't. Take a look at this thread: Joey Hess gives > the reason why he wouldn't accept it, and is then followed up by: Yeah, you see how much time that wastes. If the ftpmasters (or somebody else) just responded saying apt-i18n is a bad idea when that was asked, > It's very easy to say "We should be more transparent! Yay for being > upfront and honest!", but, quite frankly it's *way* too time consuming > in practice. I don't think an organization with so many volunteers and without transparency works. > To take another example, back in potato's freeze when I > was culling the release critical bug list, I started off taking a fair > degree of care to include an explanation and to Cc the submitter so > they knew what was going on. About half the time it resulted in angry > messages from said submitter insisting that I was being stupid or lazy > or didn't care about good quality packages or whatever. After a couple > of exchanges of messages, it's usually possible to convince them that > you do know what you're talking about, but it just takes up way too much > time. These days, I just don't bother to Cc anyone. I think this is something different. Now we are talking about developer who has put hours of work into the package, not just about somebody who filed a bug. > And quite frankly, the only reason this package was ever uploaded in > the first place is because the submitter and everyone else who cares > couldn't manage to reach a consensus with Jason about what to do -- > that doesn't bode well for a productive discussion after a REJECT message. I don't see why you can't have a productive discussion. Saying nothing doesn't give you a productive discussion anyhow. And stopping the whole discussion at all isn't possible either, it will only happen later. If we would have the discussion 3 monts ago, we might have had i18n in apt at the moment. And now we don't have anything, because everybody just ignored the whole issue. > Besides this, people have been using the lack of many public messages from > Jason as an excuse for not bothering to do anything but criticise. Which > is all very well, and even has some merit, but you _really_ shouldn't > be so surprised about that either. If I'm right there weren't many private messages either. > Take a look back to the recent > "discussion" about more efficient downloading of Packages.gz files > in the "Debian's problems, Debian's future" thread for example. There > was actually some intelligent technical content in that and a fairly > impressive argument for making a change. But you'll be hard pressed to > find it because it's hiding amongst two or three times its weight in > general pointlessness. And you won't find any indication of what to > do next because it's just too hard to keep -devel threads rationally > focussed on a technical topic. If you look at it, you see that it's possible to have a normal discussion with good argument. We should continue doing so instead of stopping discussion at all, something you are trying to do. > If you really want to encourage transparency and open discussion, the > response to bringing this issue up on this list should be a bunch of > people looking at the patches and making sure that they're completely > mergable into apt, and posting any changes that ought to be made > for further analysis. Yes, no one's done anything remotely like > this. And how should that be done if the maintainers don't tell what's wrong with the patches? Other than that, you can't just add it to a frozen package. > Until that attitude gets fixed -- until this list and others get back to > focussing on developing useful high quality code, rather than bickering > about bureaucracy or trying to convince everyone that some patently > ridiculously newbie daydream is worth breaking every existing system -- > don't expect people to willingly poke their heads up and tell you what's > going on. Or maybe the maintainers should just fix their attitude and clearly say why a patch is rejected. Don't expect people to read the minds of the maintainer. Don't expect them to change something wrong if you don't tell them it's wrong. > And, quite seriously, if you're doing something useful, and you're doing > it at all sensibly and not being too whiny about it, it's remarkably > easy to get things actually done in Debian. And some people tell me just exactly the opposite, and looking at this case (and other examples they showed me) I tend to believe them. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgpD64op0H8gt.pgp
Description: PGP signature