[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 Thu, Dec 12, 2002 at 06:54:31PM +0100, Marek Habersack wrote:
> > It's unfair to demand that a maintainer of a complex package test every
> > possible situation prior to uploading.  That could take literally weeks for
> Testing this particular thing would take a couple of minutes. Conducting all
> simple tests before uploading the package would leave only the non-trivial
> bugs to deal with. 

And no time with which to deal with them.

> > Just because you can take out an individual component and hold it up as "not
> > complex" does not mean that the sum of thest "not complex" components is
> > not itself complex.
> OK, but what's wrong in my suggestion to test the code that was added to
> handle simple and trivial situation? Is what you're saying that the
> complexity of package means that it should not be tested at all by the
> maintainer but simply uploaded to unstable for others to test it?

You're still trying to suggest that a complex system is a sum of non-complex
parts.  Fine.  That doesn't mean that the system isn't complex.

And stop the red herring arguments.  I am NOT saying that a packages should
not be tested at all.  I AM saying that Postgres was tested, and that you
should stop being a prick because a package in UNSTABLE was -- shock --
unstable!

And furthermore, that you don't even know enough about Postgres to be able
to comment intelligently on just what the upgrade process requires, so you
should stop criticizing Oliver until you can.

> > > As for the upgrade process itself - keeping a chunk of a database in the
> > > previous format is not that complicated either. A single script which copies
> > 
> > And you are purposely glossing over the facts.
> > 
> > The Postgres that the new .debs install can NOT handle the previous format.
> You are glossing over the facts now. The deb contains a script to upgrade

I'm glossing over nothing.  The fact is, Postgres 7.3 can NOT handle
Postgres 7.2 data directly.

> the previous format to the new one. The upstream contains code to perform
> that upgrade which is used by the mentioned script. Both the script and the
> upstream software failed to upgrade the data from the previous format to the
> new format. That makes the package unusable, because what's the use of
> database software which cannot handle your data? 

So you're saying that the lack of an AUTOMATIC upgrade procedure makes
Postgres worthless as a modern SQL server?  This just gets weirder and
weirder.

I submit that there are plenty of things that do not have automatic upgrade
procedures that remain useful.

> And that's what failed in this case.

Which is all irrelevant.  I wasn't trying to nitpick on the internals, just
to point out that they are more complex than you allege.

> > It is not the domain of every maintainer to exercise superhuman perfection
> > when writing code.
> No, of course, that's why the code has to be tested, no? In your $$ work -
> do you write some code and never compile it before handing it over to your
> co-workers?

And that is another red herring.  Oliver obviously compiled his package,
otherwise there would be no .deb.  He also performed some testing himself.

> > Sometimes I am stunned by ignorance.  No, this has nothing to do with
> > anything in /var.
> I beg your forgiveness for not knowing every damned thing. I'm not the

If you are going to go insult someone's character, call them an
irresponsible maintainer, and demand that they do certain things, you damn
well better be right.  Sometimes this might be called for.

You, however, are wrong.

> maintainer of postgres, remember? I'm pretty much positive I would be

I do remember.  So since you do not know enough about Postgres to understand
what the upgrade procedure is, how can you presume to know better than
someone that actually DOES know the procedure?

In other words, if you've never driven a car before, you better not be
teaching driver's education classes.

> stunned by your ignorance if I asked you how does Pike handle native code in
> the dumped modules. 

I am not making wild, unsubstantiated, incorrect, and insulting comments
about Pike like you are making about Postgres.  So this is irrelevant.

> > dump out its database, and then to change it so that the new version can
> > load the database from the dump.
> Do you need all that if you have a dump in the old format lying on your
> disk? Or whether in such case all you need to do is to simply import the

So you would have the script search your entire hard disk looking for
something that looks like a recent dump?

> existing dump? Again, _importing_ the dump failed with the 7.3 packages, not
> dumping.

Presumably this problem will not exist once the upgrader is fixed, and it is
just a relic from your particular failure.  Though you have given very
little detail for any of us to go on.

> > It's also a matter of preserving old binaries in /usr/bin, executing things
> > from paths that they are not normally executed from, etc.
> Again, is it needed when you have the dump ready?

And how do you intend to make that dump without the old binaries?

> > That's ludicrous.
> Yes, and this thread became ridiculous. I wish I have never posted anything.
> I should've learned that posting to debian-devel anything that's not in
> accordance with the popular opinion leads to a stupid flamewar.

I ask you: if you make an unsubstantiated post to -devel whining like a
little child about the fact that a couple of bugs exist in a very complex
system that is in unstable, and continue to make more and more outlandish
claims (like this was worse than the PAM breakage awhile back or the Perl
problems), then what do you expect?  You also make assertions that are at
best misleading, and based on incomplete or nonexistant knowledge of the
subject at hand.

Sometimes debian-devel does need a swift kick.  However, if you are going to
do that, you better be RIGHT and you better be INFORMED.  You are neither.

Had you calmly filed bugs, I suspect it would have been much easier.

> > I'd like to see you come up with a better way to do it.
> Me? Why me? You yourself said I'm ignorant. 

Because you claim that the current method is so terrible, yet you use your
own ignorance as a shield from having to provide anything better.  I'm sure
Oliver would be happy to accept patches to do these things in a better way.

> > Yes, and somebody else may have had just 7.1 installed, and someone else
> > just 6.5.  What makes "your" version special?
> That it was the PREVIOUS version coming from the same maintainer. That's
> what makes it special.

So are 7.1 and 6.5.

> "Childish whining". Why is everything you don't like a childish whining? I
> don't and didn't like your childish whining about non-free in Debian and so
> what?

Because you are just pissed that postgres didn't work like you thought it
should, so you decided to try to run somebody's character through the
wringer in public.

I did no such thing with my GR.

> > > I'm trying :) And I don't mind bugs, I mind stupid and silly bugs.
> > 
> > What other kind of bug is there?
> None. All are the result of my ignorance.

Ahh, there is hope for you yet :-)



Reply to: