Re: what about the mldonkey package?
On Fri, May 23, 2003 at 08:49:00PM +0200, Sylvain LE GALL wrote:
> On Fri, May 23, 2003 at 08:47:52AM +0200, Sven Luther wrote:
> > On Fri, May 23, 2003 at 12:37:05AM +0200, Sylvain LE GALL wrote:
> > > ps : concerning upload to debian, i prefer to be sure of the quality of
> > > the 1st version of mldonkey to enter unstable, because, first user will
> > > judge mldonkey on this first package ( if i fail, i will lose all
> > > credibility for this package ).
> >
> > Notice that :
> >
> > 1) Once you upload the packages, you will have to wait a few weeks for
> > it to be read by James Troup or another ftp master and then added to
> > the override file, if there is no problems or such.
> >
> > 2) If it works and is lintian clean, what are you afraid with regard
> > to quality ? Anyway, you can always do some package checking during
> > the time the package is sitting in NEW, and upload a fixed version
> > once it has been accepted or even before that.
> >
>
> MLDonkey quality is not very stable. For example, 2.4.2 seems to crash
> from time to time ( i have just restarted one, because it just has
> crashed ).
Ok, it is a problem of upstream stability, not a problem of packaging.
Still i am a bit surprised, one of the strength of ocaml is that there
should be no runtime kind of errors, which should exclude any kind of
crash. But i suppose your crashes mean uncaught exceptions ? Or is it
compiled by default with unsafe arrays or something such ?
> So if the first version people try crash after one or two hour, guess
> how many people will stay on this software...
Well, i have been using rhythmbox even while it has been eating my
music lists regularly.
> I just want to find some release which are enough stable to be a good
> first experience... I intend to keep a small archive with really
> unstable mldonkey package ( CVS in other word ), to be tested by a few,
> in order to see if it is enough stable.
Mmm, speaks poorly of an ocaml program.
> > 3) The more people review the package, the more testing it will get,
> > and it may well give you an experience with the BTS you probably will
> > be needing for your NM application anyway.
> >
>
> That is another point. To my mind, there is some obvious bug in my
> script and in mldonkey whichcan be discover by a few. If the few which
> test it can't find any obvious bug, there is a chance to be tested by a
> more widely range of people who can report me bug which are less
> obvious.
>
> Taken the example of crash. I know 2.4.2 crash every 12/24 h. So i will
> wait to have a more stable version ( 2.4.3 was out on wednesday, i will
> probably packaged 2.4.4 next monday ). I run the test for a few people (
Mmm, how involved are you with mldonkey upstream ? What are their
opinion on this ?
> including me, wait for user experience on mldonkey_user@nongnu.org, see
> if it is a good release. The bug is obvious ( i have not yet track
> it, but i know there is a bug ). If i release it today, about 2000
> people will fill bug against mldonkey-server saying that it crashes
> often. I will send to upstream all the bug, and i will probably pass all
> my time to close and forward bug. Imagine, 2.4.4 is really more stable.
> No one will report the bug of crashing, and they can focused on other
> functionnality ( debconf should permit to configure this and this
> option... ). I think it will be more accurate.
Mmm, maybe you should upload to experimental in the mean time ?
> I am not "le lievre de Jean de la Fontaine", i am more a copy of "la
> tortue". I prefer to be slow but it is in order to be efficient.
Ok, no problem. Just a problem of communication, maybe you could fill an
ITP with this, or rename it if is already open, and then fill this
information or a regular status report or something such. As an example,
i filled an ITP for gnome-randr-applet, but added then the info that i
am waiting for official 4.3.0 packages.
> Off course, i am young and i have no real experience of software
> developping, so if is say to many dumb assumption, i hope you will
> correct me ;->
No problem, just that you don't need to be necessary over-shy or
something such.
> In fact, my first experience with mtink was a little disaster, i
> packaged it very fast, do what i think was good, my sponsor upload it
> believing in me ( i thanks him because i was very courageaous ), and
> then the problem come : many bug ( RC ). I remember that no other
> platform ( ppc, sh, mips, mipsel... ) can achieve to build it. That was
> my fault, i forget to check all the dependcy ( all the error a beginner
> made in fact ). I don't want mldonkey to be the same mess.
You should not have this kind of problems for ocaml packages, or if they
are, they are documented in the ocaml_packaging_policy, and remember
that this is what sponsors are for, to help you find problems, point
them to you, and help you evolve. Sure, i guess some sponsors don't do
their job and just quickly upload the package, but that is not really
your fault.
> My first serious bug was reported by Mr Zachirrioli ( excuse if i
> mispell the name ) : i depend on ocaml-native-compiler... Which is not
> available on all platform. It will be corrected soon, but it is very
> really a dumb thing (i should have read more precisely the ocaml
> packaging policy ).
Yes, exactly, but keep in mind that many maintainers had this kind of
problems at first (even me), so ...
> Thanks for all your advice, if some of you want to be warned when i
> release the next package ( monday or tuesday i think ) send me an email,
> i will add you to my list.
Why not write it to the debian-ocaml-maint list ? Surely there is
nothing confidential about the package, and i suppose anyone subscribed
here will be aware of the experimental nature of the package, especially
if you say so in the mail.
Friendly,
Sven Luther
Reply to: