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 [EMAIL PROTECTED], 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
