That's the point. Developers and integrators are interested in submitting new feature, but few of them spend time to test, report or fix opened bug. We must find a way to recruit mor help for such tasks...
Idea are welcome... 2015-10-19 9:05 GMT+02:00 Maxime Kohlhaas <max...@atm-consulting.fr>: > As I understand, from the customer side, .0 versions are not stable > enough, and from the developer side, .0 versions are released when there > are no more issues or feedback. > So the real problem is between the two sides, there are not enough beta > testers. > > Perhaps more communication when a beta version is released, or a direct > communication to recruit beta testers... > > Bien cordialement, > > -- > > * <http://www.atm-consulting.fr/>* > > *Maxime Kohlhaas* I *Consultant Associé* > 26 rue Barthélémy de Laffemas - 26000 Valence > max...@atm-consulting.fr > Tél : 06 33 42 92 43 > www.atm-consulting.fr > > <https://www.facebook.com/atmconsulting26> > <https://twitter.com/atm_consulting> > <https://fr.linkedin.com/company/atm-consulting-valence> > <https://www.youtube.com/channel/UCYAZ-SPhzg9R87uppAvem0Q> > > 2015-10-18 20:32 GMT+02:00 Sasa Ostrouska <cas...@gmail.com>: > >> >> >> On Sun, Oct 18, 2015 at 2:52 PM, Laurent Destailleur (aka Eldy) < >> e...@destailleur.fr> wrote: >> >>> I would like to clarify some things, a lot of wrong information was >>> related here on this post, probably due to a bug between sync between >>> GitHub and SF. >>> >>> * SF is the place used to store packages. It hosts only downloadable >>> packages. Not sources. So it provides mirrors to download installers >>> packages (some are large binary packages dedicated to an OS). Sources you >>> can see on SF are just (should just be) a real time mirror from github. >>> However it seems a bug between SF and github make sync failed since 13 >>> september 2015. This seems to creates confusion on how release are done. >>> To avoid confusion, i will try to restore the sync github -> SF. It it >>> fails (problem seems to be on SF side), I will just completely remove the >>> mirroring of sources. >>> >>> * Version .0 are not beta version but they are stable version dedicated >>> to users. Such stable version are scheduled not only by a date but also by >>> opened issues. So the date is just an estimated information. In most cases, >>> it just means "Will be release after this date, when everything is ready". >>> The real thing that trigger the release is: >>> Is there any feedback or issue that are critical still opened during or >>> before the beta period ? If yes, release wait features are stable and >>> issues are fixed. If no issue are known, if no warning are up, and date of >>> roadmap is past, release can be done. That's why release are sometimes >>> late, like it was for 3.7 version because of the critical bug in mysql >>> 5.5.40. >>> >>> * Release and tagging of version is already done automatically. >>> Packages, controls and tags of source are done by the same scripted >>> process, so human error should not happen. >>> >>> >>> Thanks for clarifying it. >> Rgds >> Saxa >> >> >>> 2015-10-15 16:24 GMT+02:00 Sasa Ostrouska <cas...@gmail.com>: >>> >>>> >>>> >>>> On Thu, Oct 15, 2015 at 8:11 AM, CF <cfois...@studelec-sa.com> wrote: >>>> >>>>> ahahah, i agre with most of your parts. >>>>> >>>>> Anyhow, the SF <--> Github differences should be adressed to avoid bad >>>>> version number (understand: differents). I also understand SF audience is >>>>> not negligeable so simply closing it seems an harsh option at this time. >>>>> >>>>> SF is a good place to host downloads in my opinion, the thing is to >>>> make a script which would take care of those issues. >>>> A script should do the tarball, the upload and the git tags. In that >>>> way we would not have anymore differences between the git tree and the >>>> uploaded tarball, of course if nobody then commits to the tagged tree. The >>>> script should also create a new tag+1 branch where all the bug fixes should >>>> enter until the script is run again. In other words automatization of the >>>> process is needed. Human make errors. >>>> >>>> >>>> Rgds >>>> Saxa >>>> >>>> >>>>> >>>>> Le 14/10/2015 18:13, Doursenaud, Raphaël a écrit : >>>>> >>>>> Ok, who's up for a software lifecycle and version numbering schemes >>>>> thesis? Maybe you can get a PhD out of it! >>>>> >>>>> Jokes aside, the thing is that NO software release cycle is perfect >>>>> because various audiences seek different things. >>>>> >>>>> FLOSS developers tend to prefer "release often, release early" and >>>>> "semantic versioning". >>>>> Perfectionists are going for "when it's ready" and "I only need to >>>>> increase one number since every release is just perfect". >>>>> Traditional corporate vendors usually prefer "Rush it out the door, we >>>>> need it for yesterday, just try to hide defects under the carpet and >>>>> colorful design" and "We don't care, give us the biggest number so >>>>> marketing can show off". >>>>> Integrators and users want "Something with all the bells and whistles >>>>> that works out of the box, forever" and "No new releases, they are a pain >>>>> to deploy, so give me all the features in this one". >>>>> To which I reply: "Not gonna happen!". >>>>> >>>>> The current process is designed around the need to get code out at a >>>>> regular pace with some predictability to it. >>>>> It gives a version (N-2) supported roughly 1 and a half year. >>>>> I don't think it's that great, but at least it's there! >>>>> >>>>> IMO The Dolibarr project's lifecyle is missing some key elements to >>>>> achieve better releases quality before even thinking about changing the >>>>> release periodicity or version numbering. >>>>> >>>>> Here's a non exhaustive list from the top of my head: >>>>> >>>>> - Standardized and enforced good commits content and messages. >>>>> - Formal code reviews for everyone including the project >>>>> maintainers. >>>>> - Continuous integration used properly. Ie. no one can bypass it. >>>>> Ever. >>>>> - The previous two boils down to: no one pushes directly to the >>>>> main repository. >>>>> - Proper stabilization branches. One example of this is git flow >>>>> but other strategies are out there. >>>>> - Proper tagging. Having releases in the wild that do not match >>>>> the repository tags is a waste of everyone's time. >>>>> - Proper pre-release test cycle. With multiple alpha, beta and RC >>>>> releases. All properly advertised to get people involved. >>>>> - Testing procedures and tooling. >>>>> - Automated building for all pre-releases. >>>>> - Formal testing both automated (Think unit tests, selenium, test >>>>> instances, fuzzing…) and manual. >>>>> - Final release should be exactly the same as the last RC. >>>>> - Long term commitment to lean toward modern coding practices >>>>> (refactoring, objectification, automate everything…) >>>>> - Bugs bissecting to fix them at the root, not only in the >>>>> reported versions. >>>>> - Encourage unit tests for critical bug fixes to prevent >>>>> regressions. >>>>> - Community driven design before coding. >>>>> - … >>>>> >>>>> As you can see, there's a lot of work and it can't be done by any >>>>> single individual. The whole community needs to get involved. >>>>> But for that to happen, there should be a strong commitment from the >>>>> maintainers and core developers to stick to it and make it happen. >>>>> >>>>> We've already made some good progresses since switching to GitHub. >>>>> Code is reviewed more often and bug reports are all assessed and >>>>> properly tagged (I devote some of my own time to that weekly). >>>>> >>>>> Keep in mind that all of that is a community effort, so the best thing >>>>> to do is step up to the plate, pick a task and do something ;) >>>>> >>>>> Looking forward to your contributions! >>>>> >>>>> 2015-10-14 8:23 GMT+02:00 Jean-François Ferry <jf.fe...@aternatik.fr>: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Le 13/10/2015 18:38, Charles Benke a écrit : >>>>>> >>>>>> This is not the right question to ask, >>>>>> >>>>>> The right question is "how to ensure that when there is the most >>>>>> download of dolibarr (September to March) the broadcast version (.2 like) >>>>>> is as stable as possible for novice users" >>>>>> >>>>>> To answer this question we must look at the proposed roadmap with : >>>>>> >>>>>> - .0 in april, >>>>>> >>>>>> - .1 in june-july >>>>>> >>>>>> - .2 in september >>>>>> >>>>>> We are doing wrong since a long time... Versions shouldn't be related >>>>>> to any date but to software structure. Please see http://semver.org/ >>>>>> :) >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> EMail: e...@destailleur.fr >>> Web: http://www.destailleur.fr >>> >>> ------------------------------------------------------------------------------------ >>> Google+: https://plus.google.com/+LaurentDestailleur/ >>> Facebook: https://www.facebook.com/Destailleur.Laurent >>> Twitter: http://www.twitter.com/eldy10 >>> >>> ------------------------------------------------------------------------------------ >>> * Dolibarr (Project leader): http://www.dolibarr.org (make a donation >>> for Dolibarr project via Paypal: cont...@destailleur.fr) >>> * AWStats (Author) : http://awstats.sourceforge.net (make a donation >>> for AWStats project via Paypal: cont...@destailleur.fr) >>> * AWBot (Author) : http://awbot.sourceforge.net >>> * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > -- EMail: e...@destailleur.fr Web: http://www.destailleur.fr ------------------------------------------------------------------------------------ Google+: https://plus.google.com/+LaurentDestailleur/ Facebook: https://www.facebook.com/Destailleur.Laurent Twitter: http://www.twitter.com/eldy10 ------------------------------------------------------------------------------------ * Dolibarr (Project leader): http://www.dolibarr.org (make a donation for Dolibarr project via Paypal: cont...@destailleur.fr) * AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: cont...@destailleur.fr) * AWBot (Author) : http://awbot.sourceforge.net * CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
