But why don't you report bugs in your community forum? I mean, I am a moderator of dolibarr.es forum and end-users post there the problems they are having and I debug them and if I consider there is a bug I report it with all the details required.
Several months ago we talked about upgrading doliforge but it seems that it is no going to happen... Regards, *Marcos García* marcos...@gmail.com 2014-11-06 1:10 GMT+01:00 Francois Couque <fcou...@infimo.fr>: > Hi, > I consider myself as an end-user of Dolibarr and I have great respect for > the small team of developpers of this project. I test beta versions and > sometimes even git snapshots. I'm willing to help for tests but if you are > an end user and you want to report a bug, it's nearly impossible. > First , you need to look at the known or already reported bugs. That's not > easy to find where you have to look for that as there is no public access. > When you find what it seems the right place, you just cannot look at them > without an account. I found that very weird for an open source project. > Then you can submit a bug which will probably never be assigned or get > comments if you're not a developper. Even if the fix is described in the > bug report. I don't blame someone. I just describe the way it currently > works. Moreover if you just open an account which will needs days to be > validated just to look at the known bugs, your account will be closed after > a while. That's only my experience and I guess many others users have > probably given up like myself. > If you want more end users reporting bugs and testing beta/ RC versions, > just let them accessing the bugs databases freely , let them know the > process of submitting or commenting a bug, let them help as end users. Not > everybody can help as a developper. Listening to the end users , being able > to get their feedback could be also indeed useful. > There is probably a lot more end users than you think who are willing to > help and submit bug report if they think it can be usefull. > As a end user, 1 year seems way too much between 2 releases for me > especially when you're waiting for or need a new feature. "Stable" versions > will have old bugs and new bugs whatever the release cycle is anyway, I > know. It would be more easily accepted if the bugs database was more > exhaustive and public. > My €0.02 > Francois. > > Le 05/11/2014 10:56, Christophe Battarel a écrit : > > Not sure it will work but we can try... i dont know many end users who > tests beta versions; usually they wait for the "stable" release and they > report bugs at this time (look at the posts in french forums when 3.6 was > out...) > For what i understand from your RC stuff, if we take an example with 3.5.x > releases, 3.5.0 should have been the first RC and 3.5.5 the stable release ? > > Le 05/11/2014 10:24, Doursenaud, Raphaël a écrit : > > Agreed that testing on an ERP is no easy feat. > But I support the idea of a public RC. Advertised efficiently, it would > be a good way to get users into the pool. > After all an RC is supposed to be stable, it's what we want to release. It > has already passed the beta stages and we consider this should be the final > product so it shouldn't have any major defect. > Ideally consecutive betas and RCs should be published at a fixed rate, eg. > once a week so there is enough time between each to make some work. > Also, when done correctly, the final release _is_ the last RC. > > Cheers, > > 2014-11-05 0:40 GMT+01:00 Jacques PYRAT <jpy...@gmail.com>: > >> charles...@benke.fr a écrit le 05/11/2014 00:13 : >> >>> The establishment on an "visible" RC version (in the .fr and .org >>> website) will permit users (not necessarily developer) to test more in >>> depth version of this qualification and return faults detected. This is >>> probably also to us to "educate" our clients to back the bugs. everyone >>> will win. >>> >> Hi, >> >> I'm an end user of Dolibar. >> I'm here because I contribute to an other Open source Project (SPIP) >> And so, I use to read developpers discussion to anticipate future. >> >> With SPIP, testing RC is OK. >> But with Dolibarr, testing is dangerous ! >> I don't think that any en user would be confident testing RC given the >> risk to loose essential data ! >> >> My 2 cents, >> >> -- >> Jacques — www.pyrat.net >> >> >> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> Dolibarr-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> > > > > -- > *Raphaël Doursenaud* > Directeur technique (CTO) > Expert certifié en déploiement Google Apps > <https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> > +33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10 > > <http://gpcsolutions.fr> > http://gpcsolutions.fr > Technopole Hélioparc > 2 avenue du Président Pierre Angot > 64053 PAU CEDEX 9 > SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921 > > <http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions> > > > _______________________________________________ > Dolibarr-dev mailing > listDolibarr-dev@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > -- > Christophe Battarel > Responsable technique > sarl altairis > Informatique et Web en Grésivaudan > 33 Grande Rue > 38570 Goncelin > 09 52 71 70 96 (appel local)contact@altairis.frhttp://www.altairis.fr > > > > _______________________________________________ > Dolibarr-dev mailing > listDolibarr-dev@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > -- > Francois Couque > Directeur Associé > > Infimo > 1 Rue de la Justice > 91830 Auvernaux > > Tel: 01.60.88.30.41 > Mob: 06.27.08.37.70 > Fax: 01.70.24.76.87fcou...@infimo.fr > > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > >
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
