[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release management and testing problems



On Sat, Aug 03, 2002 at 12:30:42AM +0200, Raphael Hertzog wrote:
> Le Sat, Aug 03, 2002 at 12:31:04AM +1000, Anthony Towns ?crivait:
> > > But I can give some figures based on the actual update_output.html.
> > I can give you some figures too: 33, 42, 978, 9.376. Numbers aren't any
> > value unless they're actually informative.
> I have to retain myself to not insult you.

Imagine that.

> I have followed all your advices, and the only thing you're telling me
> now is "please go play somewhere else".

No, I'm telling you to _get a clue_.

Did you realise that I'd been testing "testing" for about a year before
it made it anywhere near the actual archive? Without any special access
to anything of any sort, or any effort by anyone else to make things
work better for me?

If you want to experiment, do it on your own time. That's the way
it works.

> I don't need you to repeat me "go and try". I can't. I have no way
> to impose anything to hundreds of developers. That's why we discuss, we
> try to see if a little experiment is possible and worth it.

Yes. That's right. I have no way to impose things on hundred of developers
either: they do what they want, I do what I want. That's why testing
works whether people care about it or not. If you ran stable or unstable
before testing came into existance -- and there wasn't a choice then,
so I know you did -- you can keep running it, and not be concerned that
this new testing thing exists. Likewise, if you don't want to care about
testing when you're maintaining your packages, you generally don't have
to do that, either -- the only real problem that's come up is that some
people would rather not have a full ten day break between uploads anytime
in the year.

> For this precise "problem" I don't have any idea of how we could
> experiment it to see if it brings anything to us. 

Monitor testing and update_excuses for a few months. Understand the
issues affecting all the packages that get delayed, and how possible
alternatives would've affected them. Look at the packages that weren't
affected by the delays and any RC bugs that were found, and see how
possible alternatives would've affected them. Make up a summary, so that
you can legitimately say "If we did things <this way>, then we'd have 10%
less delay on delayed packages, with possibly 5 additional RC bugs/month
making it into testing without being caught".

> By the end of the week, you might well understand what collaboration
> means.

I understand what it often means on this list: "You have all the power,
therefore I have none, and you must do whatever I want."

> > Worse, though, your posts are completely useless as a lead in to any
> > useful discussion on this. So, again, please _stop it_. If you want
> Your followups are not better, really. And you're taking a malicious
> pleasure to try to make funny of myself.

*shrug* I've told you how to continue productively: do the research. Yes,
yourself. I have some experience in getting this sort of thing done,
you know.

If you want something done any time soon, you make sure it doesn't affect
anyone. If you want something large done, make sure that it really,
demonstrably, is as important as you think. You're breaking both those
rules -- you want to affect just about everyone, and you're not even
able to say for sure that it's a particularly serious problem yourself.

You don't want to be insulted or have puns aimed at your throat? Then
stop being a twit.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Attachment: pgpyiB73YZ6Sb.pgp
Description: PGP signature


Reply to: