Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
On Thu, Nov 6, 2014 at 9:51 AM, Marcos García marcos...@gmail.com wrote: 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. I think that forums is a bit outdated and un-professional for reporting bugs. To help the community in my opinion what Francois says is really a big problem in here. Having up and running a good bugzilla or whatever bugs managing software, is a big help to the development IMHO. It is just a matter of getting used to it. But all relevant things to a bug get spoken under that bug number. Not that reporting a bug in the forums is wrong, but imho it is wrong working on a certain bug from the forums. Several months ago we talked about upgrading doliforge but it seems that it is no going to happen... That is really a pity. Rgds Saxa 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Le 06/11/2014 12:51, Marcos García a écrit : But why don't you report bugs in your community forum? I mean, I am a moderator of dolibarr.es http://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. I've done that even if I think as well a forum should not be used to declare bugs. It will save a lot of time to moderators if users could check by themselves easily before posting on the forum if a bug is already known in a bug tracker and can add their comments. By the way, I've posted the fix in the forum as well but I guess nothing will happen. There is no history about this issue and another end user won't probably find the fix on the forum. Several months ago we talked about upgrading doliforge but it seems that it is no going to happen... I don't know if upgrading of changing the bug tracker is the solution. It should be a decision coming from the development team as it is probably a quite big work for limited resources. But for sure, the current process could be enhanced if developpers want to get feedback from end users. Best regards. Francois. Regards, *Marcos García* marcos...@gmail.com mailto:marcos...@gmail.com 2014-11-06 1:10 GMT+01:00 Francois Couque fcou...@infimo.fr mailto: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 mailto:jpy...@gmail.com: charles...@benke.fr mailto: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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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 list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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 mailto:jpy...@gmail.com: charles...@benke.fr mailto: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 http://www.pyrat.net ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org mailto: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 list Dolibarr-dev@nongnu.org https://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) cont...@altairis.fr http://www.altairis.fr ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
2014-11-05 10:56 GMT+01:00 Christophe Battarel christophe.batta...@altairis.fr: 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 ? No, not at all. We would have a RC cycle between the beta phase and the definitive release. The cycle would go that way : Beta(last)- RC(1) - RC(n) - RC(last) == Release(x.y.0) - Beta(last) After some betas, we consider the thing is stable enough and will not have any catastrophic behavior so we're confident users can go and test it without any major harm. - RC cycle We try to promote the RCs as much as possible so we have enough people testing with their actual workflow and data (This is the only way to iron out all the bugs). - RC(last) Once the reported _and_ fixed bugs is low enough or even better, zero. We know this is good for release so **we don't touch it**, just rename it to release x.y.0 The hotfix releases (x.y.n) will continue to come out when problems are found in the field after release. This is not rocket science and pretty much the proven standard in the industry. If you want to learn more: https://en.wikipedia.org/wiki/Software_release_life_cycle Cheers, -- *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 list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
On Wed, Nov 5, 2014 at 7:48 AM, Doursenaud, Raphaël rdoursen...@gpcsolutions.fr wrote: 2014-11-05 10:56 GMT+01:00 Christophe Battarel christophe.batta...@altairis.fr: 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 ? No, not at all. We would have a RC cycle between the beta phase and the definitive release. The cycle would go that way : Beta(last)- RC(1) - RC(n) - RC(last) == Release(x.y.0) - Beta(last) After some betas, we consider the thing is stable enough and will not have any catastrophic behavior so we're confident users can go and test it without any major harm. - RC cycle We try to promote the RCs as much as possible so we have enough people testing with their actual workflow and data (This is the only way to iron out all the bugs). - RC(last) Once the reported _and_ fixed bugs is low enough or even better, zero. We know this is good for release so **we don't touch it**, just rename it to release x.y.0 The hotfix releases (x.y.n) will continue to come out when problems are found in the field after release. This is not rocket science and pretty much the proven standard in the industry. If you want to learn more: https://en.wikipedia.org/wiki/Software_release_life_cycle Cheers, hi, my thoughts on this are that this is really how most of the OSS work, but at the end is just a matter of naming. I think that the real problem lies in the development forces and the coordination between them. This means that if everybody could be able to pick up an open bug and work on it, it would really speed up the things. Right now as you stated most of the bugs are fixed at the end by one developer. Immagine a way of how to assign bugs to various developers, would not that work much faster ? At the end the release is just a point in time of some code movement, therefore, nameing it 1 or x or RC doesnt really matter much, In my opinion the micro releases should be done in a faster way, rolling them out at each few bugs fixed, for example 5 or 10 bugs or even less. The major releases then would have more time to get baked well. Also remeber ERP software is something different from a drawing like software, you deal with peoples company data, or better yet, peoples money. In my company for example I preffer to use as much time the thing which works and tend not to upgrade the thing too fast or every release for example. Some other people would wait for some features and maybe have the necessity to update faster, but this is something you will never be able to make happy everybody. Important thing is that the upgrade goes as much as possible flawlessly. So to resume, my opinion is that having a major release 1 per year and done really well. And in the middle time a lot of micro releases. Of course the most important way is to make a TODO list and follow it. My 2c, Rgds Saxa PS: Raphael, I dont know why your e-mails always end in my spam box on gmail. Any idea ? -- *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 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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 mailto:jpy...@gmail.com: charles...@benke.fr mailto: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 http://www.pyrat.net ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org mailto: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 list Dolibarr-dev@nongnu.org https://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) cont...@altairis.fr http://www.altairis.fr
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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 - … Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Doursenaud, Raphaël Envoyé : lundi 3 novembre 2014 18:32 À : Posts about Dolibarr ERP CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Hi everyone, 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 charles...@benke.fr: If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing Maybe 6month it's a good frequency for the developer, but it's not for the users and our customers who don't want to upgrade his ERP every 6 month for only 50 new features each (ok 3.7 version have a little more) Another bad point is the timing of the January major release : many users are in installation and start using
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Hi everyone, 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 charles...@benke.fr: If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing Maybe 6month it's a good frequency for the developer, but it's not for the users and our customers who don't want to upgrade his ERP every 6 month for only 50 new features each (ok 3.7 version have a little more) Another bad point is the timing of the January major release : many users are in installation and start using Dolibarr who have just installed at the end of year My position is to change the planning and add a release candidate (RC) between the beta and the stable version. RC version is an official test version for customer We diffuse it on Dolibarr website download area between the stable and pre-release (Besides the alpha and beta version posted on the download area is 3.6 not 3.7) RC version will permit of dolibarr user (not only developer user to made more test) propose the following roadmap mai - Beta Release (version A.B.0 beta) (freeze) june - Release Candidate (version A.B.0 RC) August - Major Release (version A.B.0) September - Major Release (version A.B.1) october - Alpha Release (version A.B+1.0 alpha) with 8 month for development and 4 month for test Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto: dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : samedi 1 novembre 2014 21:14 À : Posts about Dolibarr ERP CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze 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. In fact, if time between 2 release is increased by 2, the time neeed to test
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
On Mon, Nov 3, 2014 at 2:32 PM, Doursenaud, Raphaël rdoursen...@gpcsolutions.fr wrote: Hi everyone, 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, Good observations Raphael. Rgds Saxa 2014-11-01 22:42 GMT+01:00 charles...@benke.fr: If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing Maybe 6month it's a good frequency for the developer, but it's not for the users and our customers who don't want to upgrade his ERP every 6 month for only 50 new features each (ok 3.7 version have a little more) Another bad point is the timing of the January major release : many users are in installation and start using Dolibarr who have just installed at the end of year My position is to change the planning and add a release candidate (RC) between the beta and the stable version. RC version is an official test version for customer We diffuse it on Dolibarr website download area between the stable and pre-release (Besides the alpha and beta version posted on the download area is 3.6 not 3.7) RC version will permit of dolibarr user (not only developer user to made more test) propose the following roadmap mai - Beta Release (version A.B.0 beta) (freeze) june - Release Candidate (version A.B.0 RC) August - Major Release (version A.B.0) September - Major Release (version A.B.1) october - Alpha Release (version A.B+1.0 alpha) with 8 month for development and 4 month for test Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto: dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : samedi 1 novembre 2014 21:14 À : Posts about Dolibarr ERP CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Having more time to test
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
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. In fact, if time between 2 release is increased by 2, the time neeed to test and upgrade a module is increased by 4 and time required for beta is also increased by 4 instead of 2 making finally less time to have a stable version to make quality tests. That's why more and more projects are making rolling released (so a released every month and even weeks). But I think 6 month is a good frequency to not have to wait to long to get new features. Also a roadmap must be followed as announced other wise it has no senses to have roadmap. 2014-10-27 0:55 GMT+01:00 charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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 -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
If we reverse your example of increasing time, the good way is to decrease time between 2 versions and finally made nothing Maybe 6month it's a good frequency for the developer, but it's not for the users and our customers who don't want to upgrade his ERP every 6 month for only 50 new features each (ok 3.7 version have a little more) Another bad point is the timing of the January major release : many users are in installation and start using Dolibarr who have just installed at the end of year My position is to change the planning and add a release candidate (RC) between the beta and the stable version. RC version is an official test version for customer We diffuse it on Dolibarr website download area between the stable and pre-release (Besides the alpha and beta version posted on the download area is 3.6 not 3.7) RC version will permit of dolibarr user (not only developer user to made more test) propose the following roadmap mai - Beta Release (version A.B.0 beta) (freeze) june - Release Candidate (version A.B.0 RC) August - Major Release (version A.B.0) September - Major Release (version A.B.1) october - Alpha Release (version A.B+1.0 alpha) with 8 month for development and 4 month for test Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : samedi 1 novembre 2014 21:14 À : Posts about Dolibarr ERP CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze 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. In fact, if time between 2 release is increased by 2, the time neeed to test and upgrade a module is increased by 4 and time required for beta is also increased by 4 instead of 2 making finally less time to have a stable version to make quality tests. That's why more and more projects are making rolling released (so a released every month and even weeks). But I think 6 month is a good frequency to not have to wait to long to get new features. Also a roadmap must be followed as announced other wise it has no senses to have roadmap. 2014-10-27 0:55 GMT+01:00 charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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 -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
I agree that users prefer stable versions over unstable and frequent ones. And I can tell that because of being a dolibarr.es forum moderator, where users complaint about finding a major version being released, updating and not finding their bug fixed. (And sometimes more bugs appear). I encourage board members of the association to discuss the current planning in the next meeting. Regards, *Marcos García* marcos...@gmail.com 2014-10-28 14:58 GMT+01:00 Christophe Battarel christophe.batta...@altairis.fr: Hello, As a module developer, i have the same reaction as Charles. I am just finishing to migrate my modules to 3.5, i have not even gave an eye to 3.6 and you are telling us about 3.7 ! Another point is the lack of visibility of what will come in new release before it's released, but that's another troll... In fact, i no more complain about all of this because the people behind it spend a lot of time in dolibarr evolution, and i cannot do the same so i shut up. Maybe if they go slower i will be able to help more, but still it's not the case, i cant. Once we told about a LTS release; maybe we should one day do more than talking. My two cents (en vrac) Christophe Le 28/10/2014 14:36, Maxime Kohlhaas a écrit : Hi everybody, I think that keeping this 2 major versions a year plan is a good way to keep the community dynamism. This does not prevent from doing quality developments (as many thiings in 3.7 has been done to uniformize and anglicize the code). Also, we saw that there's a lack of testing after developing new features. So having more new feature after a complete year of development will mean more testing... I know that today with a new release every 6 month, we focus on testing and bug fixing more often... Finally, there are a lot of customers asking for new features (they love open-source :) ) and telling them they have to wait a whole year to have it seems complicated to me. But that's only my opinion. Charles, can you share the pros and cons to support your opinion ? Bien cordialement, -- *Maxime Kohlhaas Consultant associé **ATM Consulting http://www.atm-consulting.fr* *+33 6 33 42 92 43 %2B33%206%2033%2042%2092%2043* *NOUVELLE ADRESSE* *ATM Consulting* Technosite Valence-Agglo 26 rue Barthélémy de Laffemas 26000 Valence 2014-10-27 0:55 GMT+01:00 charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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 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 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Propose a new planning Launch on febuary a release candidate (RC), with many RCx as necessary the stable release launch on august time for development of feature is increase (multiply by 2) Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de charles...@benke.fr Envoyé : lundi 27 octobre 2014 00:55 À : 'Posts about Dolibarr ERP CRM development and coding' Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Hi everybody, I think that keeping this 2 major versions a year plan is a good way to keep the community dynamism. This does not prevent from doing quality developments (as many thiings in 3.7 has been done to uniformize and anglicize the code). Also, we saw that there's a lack of testing after developing new features. So having more new feature after a complete year of development will mean more testing... I know that today with a new release every 6 month, we focus on testing and bug fixing more often... Finally, there are a lot of customers asking for new features (they love open-source :) ) and telling them they have to wait a whole year to have it seems complicated to me. But that's only my opinion. Charles, can you share the pros and cons to support your opinion ? Bien cordialement, -- *Maxime KohlhaasConsultant associé**ATM Consulting http://www.atm-consulting.fr* *+33 6 33 42 92 43* *NOUVELLE ADRESSE* *ATM Consulting* Technosite Valence-Agglo 26 rue Barthélémy de Laffemas 26000 Valence 2014-10-27 0:55 GMT+01:00 charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
The community does not need dynamic but stable, rendering uniform code is a good thing but the short duration of the development period can not get to the bottom of things Many customers ask for news OK, but the majority of ask for stability. · Maintain two versions per year demotivate developers who prefer to spend time to add new features to make it compatible with the latest version released · Maintain two versions per year demotivate users who do not need a new version when the version he uses is stable: for them it is a waste of time and money (especially when it to pay updates of modules but that's another subject). · Maintain two versions per year does not make a major update such as restructuring and renaming files according to a defined standard objects. All the more it comes to cosmetic editing (change ‘fiche' with 'card' which impacts heavily by developers changing modules). Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Maxime Kohlhaas Envoyé : mardi 28 octobre 2014 14:37 À : Posts about Dolibarr ERP CRM development and coding Objet : Re: [Dolibarr-dev] Dolibarr 3.7 freeze Hi everybody, I think that keeping this 2 major versions a year plan is a good way to keep the community dynamism. This does not prevent from doing quality developments (as many thiings in 3.7 has been done to uniformize and anglicize the code). Also, we saw that there's a lack of testing after developing new features. So having more new feature after a complete year of development will mean more testing... I know that today with a new release every 6 month, we focus on testing and bug fixing more often... Finally, there are a lot of customers asking for new features (they love open-source :) ) and telling them they have to wait a whole year to have it seems complicated to me. But that's only my opinion. Charles, can you share the pros and cons to support your opinion ? Bien cordialement, -- Maxime Kohlhaas Consultant associé ATM Consulting http://www.atm-consulting.fr +33 6 33 42 92 43 NOUVELLE ADRESSE ATM Consulting Technosite Valence-Agglo 26 rue Barthélémy de Laffemas 26000 Valence 2014-10-27 0:55 GMT+01:00 charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr mailto:dolibarr-dev-bounces%2Bcharles.fr =benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Hello, As a module developer, i have the same reaction as Charles. I am just finishing to migrate my modules to 3.5, i have not even gave an eye to 3.6 and you are telling us about 3.7 ! Another point is the lack of visibility of what will come in new release before it's released, but that's another troll... In fact, i no more complain about all of this because the people behind it spend a lot of time in dolibarr evolution, and i cannot do the same so i shut up. Maybe if they go slower i will be able to help more, but still it's not the case, i cant. Once we told about a LTS release; maybe we should one day do more than talking. My two cents (en vrac) Christophe Le 28/10/2014 14:36, Maxime Kohlhaas a écrit : Hi everybody, I think that keeping this 2 major versions a year plan is a good way to keep the community dynamism. This does not prevent from doing quality developments (as many thiings in 3.7 has been done to uniformize and anglicize the code). Also, we saw that there's a lack of testing after developing new features. So having more new feature after a complete year of development will mean more testing... I know that today with a new release every 6 month, we focus on testing and bug fixing more often... Finally, there are a lot of customers asking for new features (they love open-source :) ) and telling them they have to wait a whole year to have it seems complicated to me. But that's only my opinion. Charles, can you share the pros and cons to support your opinion ? Bien cordialement, -- /*Maxime Kohlhaas *Consultant associé //ATM Consulting http://www.atm-consulting.fr/ /+33 6 33 42 92 43/ / / /*NOUVELLE ADRESSE*/ *ATM Consulting* Technosite Valence-Agglo 26 rue Barthélémy de Laffemas 26000 Valence 2014-10-27 0:55 GMT+01:00 charles...@benke.fr mailto:charles...@benke.fr: Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 tel:0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr http://charles.fr=benke...@nongnu.org mailto:benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr mailto:dolibarr-dev-bounces%2Bcharles.fr=benke...@nongnu.org mailto:benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org mailto:Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org mailto: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 -- Christophe Battarel Responsable technique sarl altairis Informatique et Web en Grésivaudan 33 Grande Rue 38570 Goncelin 09 52 71 70 96 (appel local) cont...@altairis.fr http://www.altairis.fr ___ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Re: [Dolibarr-dev] Dolibarr 3.7 freeze
Freeze the develop branch to start beta in not a good idea : we need more time between 2 major versions (One year, not six month) to test and develop ours modules. If we maintain this crazy rate of two major releases per year, I will no more upgrade my modules for the February version. It's time to make quality more than quantity Bien cordialement, Charles-François BENKE http://www.benke.fr - 0637056117 -Message d'origine- De : dolibarr-dev-bounces+charles.fr=benke...@nongnu.org [mailto:dolibarr-dev-bounces+charles.fr=benke...@nongnu.org] De la part de Destailleur Laurent Envoyé : dimanche 26 octobre 2014 23:41 À : ML Dolibarr dev Objet : [Dolibarr-dev] Dolibarr 3.7 freeze Just a warning to remind everybody that we are reaching end of october: This means the freeze of develop branch to start beta 3.7 will be done in less than 7 days. -- Laurent Destailleur (alias Eldy) Social networks of my OpenSource projects: Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ Dolibarr Facebook: https://www.facebook.com/dolibarr Dolibarr Twitter: http://www.twitter.com/dolibarr AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ AWStats Facebook: https://www.facebook.com/awstats.org AWStats Twitter: http://www.twitter.com/awstats_project ___ 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
