Colin Watson <[EMAIL PROTECTED]> writes:
> 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 understood correctly that "it depends on the package". I only want
to point out that when you open doors like that, they are more risks
that stories like those I described below happen.
We are both responsible persons and we can take care of this. But how
many of the 800 developers are aware of this?
> >
> > - 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.
I agreed on this point.
>
> 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
At least, we talked about this problem. It was just "the latest straw
that breaks the camel's back" since I consider myself as a victim
of such bad behaviour from unresponsible developers over the last months.
Of course, MhOnArc is not that critical.
The subject should be publicly discussed, in my opinion.
Cheers,
--
Jérôme Marant <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
