Bug#113850: mhonarc: New upstream available
On Sun, Sep 30, 2001 at 11:43:45PM +0200, J?r?me Marant wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > I think that's a very black-and-white view. Some things are less safe in
> > beta than others: libraries are the standard example. On the other hand,
> > I doubt that anyone cares that trn4, say, is still in beta; in practice
> > it's probably never going to get a stable release due to development
> > being stagnant, but I'd take it over the stable trn (3.6) any day.
>
> It is not a black-and-white view. With that argumentation, you are just
> opening doors to abuses. I'm just talking about Quality Assurance,
> there's nothing new.
I was trying to say "it depends on the package", but maybe I wasn't
clear enough about that. QA isn't a mechanical process that you can
apply in the same way across the board.
> I have at least two examples in mind:
>
> - I was very happy with using Konqueror 2.1, it was stable then Ivan
> Moore decided to ship beta versions of kde libs 2.2 and it suddenly
> crashed and no more kde app could stay in memory more than 30 seconds.
> - the current version of mp3blaster is a beta version and there are
> regressions in functionalities since some features are missing but
> were present in the previous version.
Then obviously neither of those should have been packaged.
> As I said before, there are many means of installing applications,
> people can download the tarball and break there systems it they
> want. When you distribute a beta version in debs, you have the
> risk to get bloated by BTS bugs about an application you know not
> to be fully debugged.
That's not always what "beta" means. In the case of trn4, for instance,
the only reason it hasn't been declared stable is insufficient
documentation. There was even less documentation in trn 3.6, so trn4's
is an improvement. Furthermore, when upstream has slow development
cycles, packaging a known-to-be-pretty-solid "beta" release may well be
better for the users (i.e. result in fewer open bugs sooner) than
waiting for a "stable" release which is some way off. Packaging a shoddy
beta release will obviously lead to problems, in the same way as
packaging a shoddy stable release would.
Please let's stop worrying about some blurry, exaggerated distinction
between "beta" and "stable" releases which isn't applied even vaguely
consistently anyway across different upstream developers, and instead
concern ourselves with the actual stability of the software. Jeff says
in his bug report that there have been no reports on the MHonArc mailing
list about 2.5.0b2; do you have evidence or concrete concerns that it
isn't stable?
In short, I fully agree that we shouldn't package buggy software.
However, I disagree that upstream designations of releases are a
universally reliable way of deciding whether a release is better and
more stable for our users.
(Jeff, please shout if you'd rather be left out of this discussion. :))
> > Davide Salvetti offered to adopt mhonarc last October. I e-mailed him
> > about it in early August and never got a response, so I think I'll
> > change its state back to orphaned and see if anybody else is interested
> > in it.
>
> I already contacted him some times ago and it seems he is no longer
> interested in adopting it.
Ah, none of that discussion was copied to the bug report (#68829), so I
didn't know about that. I've marked it orphaned.
> As I'm packaging a mailing list manager which requires mhonarc, I
> might adopt it.
Great!
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: