Re: Release management and testing problems
#include <hallo.h>
Anthony Towns wrote on Sat Aug 03, 2002 um 02:02:55PM:
> > > 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_.
To be honest, I still have the impression that you use your get-a-clue
statement just to make uncomfortable persons shut up.
> 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.Sorry, but why should a new working/candidate branch needs such extensiv testing?
IMHO the working/candidate implementation could profit from your
experience and be implemented much faster. The pool structure is ready
now, "testing" control scripts exist as example.
> That's the way it works.
...it works FOR YOU. You are the release manager. You are the only
person with adequate experience and access to all required facilities.
Who CAN do the same thing? No, you do not offer your help when somebody
presents a concept not developed by you, you just tell anyone to make
everything in his own.
> > 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".
Testing is not comparable with a working/candidate tree. Testing depends
directly on Unstable. Did anyone consider automatical rebuilding of
packages (against Testing) if they do not get into Testing because of
dependencies on broken packages?
> 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.
I personally would help Buxy implementing a such thing if someone would
let us do it.
Gruss/Regards,
Eduard.
--
checking for the validity of the Maxwell laws on this machine... ok
checking if e=mc^2... ok
checking if we can safely swap on /dev/fd0... yes
(Ausgabe von "configure" bei kvirc 2.0)
Reply to: