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

Re: Is Sid for broken stuff? Is it too much to ask for testing the packages?

On Wed, Dec 11, 2002 at 07:35:33PM -0600, Steve Langasek scribbled:
> On Thu, Dec 12, 2002 at 01:08:37AM +0100, Marek Habersack wrote:
> > Going back to postgres - apparently the maintainer "has no time" to
> > test upgrades from earlier formats of the database to the latest
> > format. If the upgrade isn't tested by the maintainer and isn't tested
> > now - when is it going to be tested and on whose data?  Ours? Our 
> > users's in 6 months when a broken package hits stable? At least last 3
> > Debian releases of the postgresql packages were broken - the database
> > format upgrade from 7.2 to 7.3 seems to be broken upstream, is it too much
> > to ask the maintainer to test at least such things before uploading packages
> > to Sid? We, developers, are supposed to use Sid machines - they are our
> > working environment - and if they are broken because of somebody not doing
> > their job, something's definitely going wrong somewhere...
> Developers are expected to build their packages against unstable, and
> also to test to make sure they work in unstable; this does not mean they
> are expected to trust their important data to unstable.  Whether or not
I don't trust any important data and it's not my concern. I expect that
there might be bugs in the software that's in unstable, and that's fine. But
if the packages break or don't work because the maintainer is lazy or
doesn't have time to install _and_ test their package, then I'm getting mad.

> you think "this is unstable" comments help, it's not fair for you to be
> mad at maintainers who HAVE done what they can to test packages before
Do you think mozilla-snapshot was installed by the maintainer before he
uploaded it? Or do you think that the postgres maintainer checked whether
upgrade from the 7.2 format to the 7.3 format works? If he installed the
package, he would have tested that functionality since I suppose he had 7.2
data on his disk before. I named postgresql as the example, because that
happened to be what triggerred my mail, that's it - no other reason. And,
again, I'm not mad about lost data (although I lost some data, not important
though) - I'm mad about recklessness and laziness of some maintainers.

> uploading them.  If maintainers were capable of doing all the necessary
> testing themselves and could guarantee that the software was free of RC
> bugs before uploading, why would we NEED a distribution called
> 'unstable'?
I'm sorry, but to my best knowledge the packages I mentioned weren't tested
- and I hope it's obvious, since they broke for everybody who installed

> If the possibility of eat-your-system bugs in unstable could cost you
> important data or lead to expensive downtime, *don't run unstable on
> those systems*!  Being a developer and helping turn unstable into stable
> doesn't mean letting bugs affect your work.
Steve, I'm sorry, but you seem to be missing my point. I don't mind bugs in
unstable, I don't mind fixing bugs I can fix (and I've done so quite a few
times), but if the bug results from laziness or the fact that the maintainer
didn't care to install the package on his system, then I do mind such bugs -
especially that many of them waste my time, and time is a very precious
resource. Take for example this thing:

trap "mail -s "$MAILSUBJECT" root@localhost < ${MAILFILE}; rm -f $MAILFILE"

Do you honestly think that the maintainer installed script with that code
and that the code worked for him? 

> In the case of Postgres, the maintainer did make it clear that he had
> installed the packages on his system to test them before uploading.
Then he must be running a different shell as /bin/sh than I do (I ran bash
and dash as /bin/sh).

> Now, if you're not happy with the amount of testing he's done, you
> really only have three choices:  you can help him test the package more
> extensively; you can accept that the package may be buggy when uploaded;
I agree with you completely, but read the notes I wrote above.

> or you can tell the maintainer how bad of a job he's doing, which will
> likely lead to the package being orphaned.  You can't force the
> maintainer to dedicate more time to testing the package.  If everyone
> spent two days *testing* their packages by installing and uninstalling
> them, when would anyone have time for actually fixing bugs?
Again, I agree - but we're talking about different kinds of bugs, really.
And, believe me or not, I do test my packages (as little importand as they
are, but I test them). So I don't accept the excuse. Installing a package is
a trivial matter and should be _required_ before uploading the package.

> > because it is getting serious with the constant stream of untested 
> > packages pouring in Sid in the recent times.
> "untested" is not the same as "not tested to your satisfaction".
Steve, please, take a closer look at the cases I mentioned (there were more
of them) and tell me honestly whether those packages could have been tested
on the maintainer's system and then break in such way on some other system
(or rather systems).

thank you,


Attachment: pgpU_x5ac7nmS.pgp
Description: PGP signature

Reply to: