|Subject:||Re: [Dolibarr-dev] Dolibarr 3.7 freeze|
|Date:||Wed, 5 Nov 2014 00:13:37 +0100|
Raphael thank you for this synthesis
There actually is a problem of manpower for testing and probably more time will not change. It prevents many of us to look after our customers and finaly run out of time to work on the core.
This is due that we stay between developers, or Dolibarr users must be more implicated on the development phases and particulary the test.
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.
Maybe create a job of relationship (R2D2 ;-P ) between developers and users is a good way
3.7 is on the way, do not bother to stop, but take the time to ask the right questions for the next release,
- LTS or not
- asking the users of priority new feature
- Test period with user more implicated
http://www.benke.fr - 0637056117
Sorry I'm a little late to the party, i was taking vacations :D
Dolibarr release cycle is … well … a release cycle. There is no right or wrong way, only infinite possibilities in between.
What we should account for first, IMHO, is the size of the manpower we have driving the main development. Looking at the numbers (git shortlog -sne 3.6.0..develop) , we're not that much. I get 71 different committers (based on email addresses so a few dups). eldy being the main man (More than 50% of the commits kudos to him!) and second man being at a mere 8% (!). The core team is composed of 15 people at most. Numbers are pretty much the same for the previous cycle. But for maintenance release (git shortlog -sne 3.6.0..3.6), only 20 committers with again eldy almost hitting 50%.
This means two things:
- First, developers seem to have no interest in maintaining the code. So having longer integration periods will, as said eldy, only make things worse.
- Second, we don't have much resources so we must keep things as streamlined as possible and use them wisely.
I have a feeling that maintaining 3 versions (n, n-1 & n-2) is already a _huge_ effort.
Of course, we could use a LTS scheme but someone need to step up to spec and lead the project.
Although I very much like the idea, I'm not volunteering, I'm already unable to make a friggin' release (yeah, shame on me, but I spec'd it already).
I also like the "Release often, release early" mantra often used in free software communities so we should keep going.
Shifting the release dates may have some advantages for commercial users, I kind of like the idea but you can't make everybody happy.
Some things stroke me though:
- Updating looks like a pain for our users. Maybe it's time for some "Automatic" (read Assisted) upgrade mechanism. Could make a nice bounty, I'd certainly pay for that.
- Some bugs stay unfixed between versions. Maybe we should try putting up some events like "bug squashing day" or whatever, once a month with some nice rewards (Thanks email, a wiki and/or forum badge, a hug. Yeah, resources are pretty scarce these days but you get the idea) as an incentive to get developers and users interested in maintenance. (I'm guilty not being.)
- Updating breaks external modules. Well that's very unfortunate they're external… (Sorry, couldn't resist)
We can't guarantee a stable API without some heavy burden on our Yodas and I don't think they'd like it. Also, if you're a module developer, it's your responsibility to make the modifications needed in the integration period ! You're doing two things at once doing it there. Make sure your module works with the new Dolibarr and that Dolibarr is bug free on release. Does it sound nice or what. Also, unlike proprietary software, the code is available early so you really have no excuses. Incompatible changes are often very well documented in the ChangeLog. But feel free to contribute some core code that'll make your life easier (Better API, looser coupling, your module…).
Anyway, my 2 cents,
2014-11-01 22:42 GMT+01:00 <address@hidden>:
If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing
Having more time to test will not change anything. If you have more time, you will have also more regression and motre things to test.
Directeur technique (CTO)
+33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10
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
|[Prev in Thread]||Current Thread||[Next in Thread]|