Re: Dolibarr-dev Digest, Vol 163, Issue 6

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Dolibarr-dev Digest, Vol 163, Issue 6

Hubert Andriolo
As user, i find this conversation quite sterile : 
2 points of view are debated here, but the end user is not taken in the judgement.
Both points of view are valid : 
One is : release fast, show dynamism, correct bugs faster, but lose consistency in satellite modules...
the other is : release once a year, adapt less quickyly, show users "reliability", but lose dynamism to correct bugs and adapt modules...
in the second case there is no "pro" arguments because anyway small companies of one or 2 devs will take 6 months to adapt their modules, compared to bigger teams that will take just 1 month...
even releasing less often, will have for consequence to report less bugs, less tests....

The point of view of the user is not revealed here, except Defrance that tries to tell us : 
Many of his users go on x.0 or x.1 versions to get as many bugs as possible in their ERP...

the solution is : don't let go your users on new versions, since you didn't adapt your modules !
If they chose a recent version, and want fast work, they have a big wallet, or they wait...

The communication seems not really bad when you follow github's pace of notifications about Dolibarr/Dolibarr... (Eldy always says : Prepare package 5.0, prepare 4.0.2... etc...
Maybe a digest a week would be better, because everyday it is a hassle to "pick" "read or delete"...

Why external modules don't "merge" in core after a period of time ?
- Not financed enough
-Sold as many times as versions appear
-abandonned ?

Why complaining Developpers don't "merge" the Dolibarr-Develop version in theirs "private-Dolibarr-module-forks" to adapt their modules little by little and see if there could be a problem ? Instead of waiting the package and then see a mountain of work ?

Please, once for all stop arguing about the rythm, this rythm lasts for years, 6 month in IT environment is quite long-term already.

And please take this time to find solutions to make external modules "accompany" the Develop version :

-Merge into Core when financed (Dolistore setup : when X sales of Y € has been reached, merge my module into develop)
-Advertise on module updates and price of these updates and time it could take. Or NO update guaranteed (STS)
-Make a private repo with all Dolistore modules merged into core develop to see compatibility issues.





Hubzzz

2016-10-19 14:37 GMT+02:00 <[hidden email]>:
Send Dolibarr-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dolibarr-dev digest..."


Today's Topics:

   1. Re: [Dolibarr-association]  Dolibarr 4.0.1 (Maxime Kohlhaas)
   2. Re: [Dolibarr-association] Dolibarr 4.0.1 ([hidden email])
   3. Re: [Dolibarr-association] Dolibarr 4.0.1 (Maxime Kohlhaas)


----------------------------------------------------------------------

Message: 1
Date: Wed, 19 Oct 2016 09:47:50 +0200
From: Maxime Kohlhaas <[hidden email]>
To: [hidden email]
Cc: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Subject: Re: [Dolibarr-dev] [Dolibarr-association]  Dolibarr 4.0.1
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi all,

Regarding the current release management, I (speaking also for ATM) think
that having 2 releases per year is a very good thing.
This shows community members that Dolibarr is very active, users that the
project is very much alive and that they don't have to wait for more than a
year to have a new functionality.

On the development side, we strongly think that short delays between
releases is the best because the beta stage is reduced and so are the
bugfix. The more new things you have to test and fix, the longer and harder
this will be. There's already a lack of testers and bugfixers, so having
more for them will be discouraging.

Finally, I don't see where the developer creativity is reduced with this
system.

Of course I (again we at ATM) are open to discussion, especially when you
will visit us in Valence on December 9/10/11 ;)

Bien cordialement,

--
*Maxime Kohlhaas* | Consultant associ?
------------------------------------------------------------------------------------
T?l : <a href="tel:06%2033%2042%2092%2043" value="+33633429243">06 33 42 92 43

2016-10-17 18:38 GMT+02:00 The mailing-list for Dolibarr foundation members
<[hidden email]>:

> Hello
>
> I agree with Charlie and not only for creativity reason.
> I think this point as to be debated to the next devcamp in Valencia.
>
> Regards
>
> Philippe Scoffoni
>
>
> Le 15/10/2016 ? 14:51, Charles Benke a ?crit :
>
> Hello,
>
> 10 years is a good year to change his use, be more adult ?
>
> 5.0 is a REAL major version IF they include as stable multicurancy and
> accountancy
>
> In other case they will be another disturbish version who decrease the
> number of sell in the Dolistore.
>
> 6 month between 2 major version freeze the creativity of developpers, We
> have waiting 3 years to have the accountancy stable in Dolibarr and without
> the crownfunding of darkjeff, I suppose that we have to wait 3 years more
> this major feature ?
>
>
>
> Once again I ask to change the scheduling of the major release to 1 by
> year and I propose to plan a vote for change the roadmap ASAP
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* Dolibarr-association [mailto:[hidden email]
> bounces+charles.fr=[hidden email]
> <dolibarr-association-bounces+charles.fr=[hidden email]>] *De la
> part de* The mailing-list for Dolibarr foundation members
> *Envoy? :* samedi 15 octobre 2016 11:47
> *? :* ML Dolibarr dev <[hidden email]> <[hidden email]>;
> ML Dolibarr Foundation <[hidden email]>
> <[hidden email]>
> *Objet :* [Dolibarr-association] Dolibarr 4.0.1
>
>
>
> Hi.
>
> Just a note to let you know that dolibarr 4.0.1 has been released.
> 4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues
> discovered just after release of the major version 4.0
>
> The current development branch should also be frozen soon to start the 5.0
> beta period. Goal is to release 5.0 in january as stated in the roadmap we
> follow from 10 years now (1 major version in january and 1 in july)
>
> Version can be downloaded from official portal https://www.dolibarr.org
>
>
> _______________________________________________
> Dolibarr-dev mailing listDolibarr-dev@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>

--
 <http://www.atm-consulting.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/b0762273/attachment.html>

------------------------------

Message: 2
Date: Wed, 19 Oct 2016 10:02:53 +0200
From: "[hidden email]" <[hidden email]>
To: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Cc: [hidden email]
Subject: Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
Message-ID:
        <CADneLzdshbLAx17bcZOE4dZS+w5sG8GJoSosOfX5ON=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi

I don't know if one, two or more releases each year is good. As user is
without interest.

The more important is to have an easier update. Actually I know only two
projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is
often broken or without maintenance. Also I don't try to propose PR or
patch, between two releases I'm sure to lost these changes. Actually it's
easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are
often forget in this list.

Km
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/73c3b05a/attachment.html>

------------------------------

Message: 3
Date: Wed, 19 Oct 2016 14:37:10 +0200
From: Maxime Kohlhaas <[hidden email]>
To: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Cc: [hidden email]
Subject: Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
Message-ID:
        <CAMn8xZeqUFQ3zi3VGF94vCzFpw=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll
have systematic annoucement when a major version is released, minor version
too, why not. A communication group has been started within the fundation
with the goal to better communicate with the community. We already are
present on social medias, but this dev mailing-list and the dolistore
customers are 2 audiences we poorly communicate with (not to say not at
all).

About your concerns around PRs and plugins, I'm sorry you feel that way.
PRs are usually correctly integrated and not lost. Plugins are the
responsibility of their developers. Personnaly, our plugins are upgraded
with the new releases

--
*Maxime Kohlhaas* | Consultant associ?
------------------------------------------------------------------------------------
T?l : <a href="tel:06%2033%2042%2092%2043" value="+33633429243">06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:

> Hi
>
> I don't know if one, two or more releases each year is good. As user is
> without interest.
>
> The more important is to have an easier update. Actually I know only two
> projects very nice to update : dolibarr and piwik.
>
> As developper, other aspects, I don't try anymore to use plugin, because
> is often broken or without maintenance. Also I don't try to propose PR or
> patch, between two releases I'm sure to lost these changes. Actually it's
> easier to maintain locals patchs and run a routine after each update.
>
> And dolibarr communication is poor, for example, release notification are
> often forget in this list.
>
> Km
>
> _______________________________________________
> Dolibarr-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>

--
 <http://www.atm-consulting.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/040e9f13/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


------------------------------

End of Dolibarr-dev Digest, Vol 163, Issue 6
********************************************


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Dolibarr-dev Digest, Vol 163, Issue 6

Christophe Battarel

hello,

just a few words to clarify some things from my point of view :

1) no more things to say about release rythm; i do not understand why dynamism is better than stability but i can admit it's the way the world works now (buzz rather than acts).

2) user point of view not revealed ? did someone ask them ?

3) merging of external modules into core ? i thought that Laurent said once he does not want anymore new module into core to keep its stability and i totally agree with him on this point - small but good is better ;-)

4) communication ? a harsh work to do... first thing should be to be active on the user's forums; reading github is a pain, even more for users !

As often i think that dolibarr addresses two different kinds of people and we have to go with it because it's a good thing (mix of little and bigger companies with different points of view, different usages, different needs, etc). If someone want to do it its own way because he thinks it's better, he may fork the project and it is also good for everyone.

My two hundred dollars


Le 24/10/2016 à 14:39, Hubert Andriolo a écrit :
As user, i find this conversation quite sterile : 
2 points of view are debated here, but the end user is not taken in the judgement.
Both points of view are valid : 
One is : release fast, show dynamism, correct bugs faster, but lose consistency in satellite modules...
the other is : release once a year, adapt less quickyly, show users "reliability", but lose dynamism to correct bugs and adapt modules...
in the second case there is no "pro" arguments because anyway small companies of one or 2 devs will take 6 months to adapt their modules, compared to bigger teams that will take just 1 month...
even releasing less often, will have for consequence to report less bugs, less tests....

The point of view of the user is not revealed here, except Defrance that tries to tell us : 
Many of his users go on x.0 or x.1 versions to get as many bugs as possible in their ERP...

the solution is : don't let go your users on new versions, since you didn't adapt your modules !
If they chose a recent version, and want fast work, they have a big wallet, or they wait...

The communication seems not really bad when you follow github's pace of notifications about Dolibarr/Dolibarr... (Eldy always says : Prepare package 5.0, prepare 4.0.2... etc...
Maybe a digest a week would be better, because everyday it is a hassle to "pick" "read or delete"...

Why external modules don't "merge" in core after a period of time ?
- Not financed enough
-Sold as many times as versions appear
-abandonned ?

Why complaining Developpers don't "merge" the Dolibarr-Develop version in theirs "private-Dolibarr-module-forks" to adapt their modules little by little and see if there could be a problem ? Instead of waiting the package and then see a mountain of work ?

Please, once for all stop arguing about the rythm, this rythm lasts for years, 6 month in IT environment is quite long-term already.

And please take this time to find solutions to make external modules "accompany" the Develop version :

-Merge into Core when financed (Dolistore setup : when X sales of Y € has been reached, merge my module into develop)
-Advertise on module updates and price of these updates and time it could take. Or NO update guaranteed (STS)
-Make a private repo with all Dolistore modules merged into core develop to see compatibility issues.





Hubzzz

2016-10-19 14:37 GMT+02:00 <[hidden email]>:
Send Dolibarr-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dolibarr-dev digest..."


Today's Topics:

   1. Re: [Dolibarr-association]  Dolibarr 4.0.1 (Maxime Kohlhaas)
   2. Re: [Dolibarr-association] Dolibarr 4.0.1 ([hidden email])
   3. Re: [Dolibarr-association] Dolibarr 4.0.1 (Maxime Kohlhaas)


----------------------------------------------------------------------

Message: 1
Date: Wed, 19 Oct 2016 09:47:50 +0200
From: Maxime Kohlhaas <[hidden email]>
To: [hidden email]
Cc: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Subject: Re: [Dolibarr-dev] [Dolibarr-association]  Dolibarr 4.0.1
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi all,

Regarding the current release management, I (speaking also for ATM) think
that having 2 releases per year is a very good thing.
This shows community members that Dolibarr is very active, users that the
project is very much alive and that they don't have to wait for more than a
year to have a new functionality.

On the development side, we strongly think that short delays between
releases is the best because the beta stage is reduced and so are the
bugfix. The more new things you have to test and fix, the longer and harder
this will be. There's already a lack of testers and bugfixers, so having
more for them will be discouraging.

Finally, I don't see where the developer creativity is reduced with this
system.

Of course I (again we at ATM) are open to discussion, especially when you
will visit us in Valence on December 9/10/11 ;)

Bien cordialement,

--
*Maxime Kohlhaas* | Consultant associ?
------------------------------------------------------------------------------------
T?l : <a moz-do-not-send="true" href="tel:06%2033%2042%2092%2043" value="+33633429243">06 33 42 92 43

2016-10-17 18:38 GMT+02:00 The mailing-list for Dolibarr foundation members
<[hidden email]>:

> Hello
>
> I agree with Charlie and not only for creativity reason.
> I think this point as to be debated to the next devcamp in Valencia.
>
> Regards
>
> Philippe Scoffoni
>
>
> Le 15/10/2016 ? 14:51, Charles Benke a ?crit :
>
> Hello,
>
> 10 years is a good year to change his use, be more adult ?
>
> 5.0 is a REAL major version IF they include as stable multicurancy and
> accountancy
>
> In other case they will be another disturbish version who decrease the
> number of sell in the Dolistore.
>
> 6 month between 2 major version freeze the creativity of developpers, We
> have waiting 3 years to have the accountancy stable in Dolibarr and without
> the crownfunding of darkjeff, I suppose that we have to wait 3 years more
> this major feature ?
>
>
>
> Once again I ask to change the scheduling of the major release to 1 by
> year and I propose to plan a vote for change the roadmap ASAP
>
>
>
> Bien cordialement,
>
> Charlie Benke
>
>
>
> *De :* Dolibarr-association [mailto:[hidden email]
> bounces+charles.fr=[hidden email]
> <dolibarr-association-bounces+charles.fr=[hidden email]>] *De la
> part de* The mailing-list for Dolibarr foundation members
> *Envoy? :* samedi 15 octobre 2016 11:47
> *? :* ML Dolibarr dev <[hidden email]> <[hidden email]>;
> ML Dolibarr Foundation <[hidden email]>
> <[hidden email]>
> *Objet :* [Dolibarr-association] Dolibarr 4.0.1
>
>
>
> Hi.
>
> Just a note to let you know that dolibarr 4.0.1 has been released.
> 4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues
> discovered just after release of the major version 4.0
>
> The current development branch should also be frozen soon to start the 5.0
> beta period. Goal is to release 5.0 in january as stated in the roadmap we
> follow from 10 years now (1 major version in january and 1 in july)
>
> Version can be downloaded from official portal https://www.dolibarr.org
>
>
> _______________________________________________
> Dolibarr-dev mailing listDolibarr-dev@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
>

--
 <http://www.atm-consulting.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/b0762273/attachment.html>

------------------------------

Message: 2
Date: Wed, 19 Oct 2016 10:02:53 +0200
From: "[hidden email]" <[hidden email]>
To: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Cc: [hidden email]
Subject: Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
Message-ID:
        <CADneLzdshbLAx17bcZOE4dZS+w5sG8GJoSosOfX5ON=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi

I don't know if one, two or more releases each year is good. As user is
without interest.

The more important is to have an easier update. Actually I know only two
projects very nice to update : dolibarr and piwik.

As developper, other aspects, I don't try anymore to use plugin, because is
often broken or without maintenance. Also I don't try to propose PR or
patch, between two releases I'm sure to lost these changes. Actually it's
easier to maintain locals patchs and run a routine after each update.

And dolibarr communication is poor, for example, release notification are
often forget in this list.

Km
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/73c3b05a/attachment.html>

------------------------------

Message: 3
Date: Wed, 19 Oct 2016 14:37:10 +0200
From: Maxime Kohlhaas <[hidden email]>
To: "Posts about Dolibarr ERP & CRM development and coding"
        <[hidden email]>
Cc: [hidden email]
Subject: Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1
Message-ID:
        <CAMn8xZeqUFQ3zi3VGF94vCzFpw=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi Km,

Thanks for sharing this.
I agree, Dolibarr migration is pretty nice !

Regarding communication, this is a work in progress. From now on, we'll
have systematic annoucement when a major version is released, minor version
too, why not. A communication group has been started within the fundation
with the goal to better communicate with the community. We already are
present on social medias, but this dev mailing-list and the dolistore
customers are 2 audiences we poorly communicate with (not to say not at
all).

About your concerns around PRs and plugins, I'm sorry you feel that way.
PRs are usually correctly integrated and not lost. Plugins are the
responsibility of their developers. Personnaly, our plugins are upgraded
with the new releases

--
*Maxime Kohlhaas* | Consultant associ?
------------------------------------------------------------------------------------
T?l : <a moz-do-not-send="true" href="tel:06%2033%2042%2092%2043" value="+33633429243">06 33 42 92 43

2016-10-19 10:02 GMT+02:00 [hidden email] <[hidden email]>:

> Hi
>
> I don't know if one, two or more releases each year is good. As user is
> without interest.
>
> The more important is to have an easier update. Actually I know only two
> projects very nice to update : dolibarr and piwik.
>
> As developper, other aspects, I don't try anymore to use plugin, because
> is often broken or without maintenance. Also I don't try to propose PR or
> patch, between two releases I'm sure to lost these changes. Actually it's
> easier to maintain locals patchs and run a routine after each update.
>
> And dolibarr communication is poor, for example, release notification are
> often forget in this list.
>
> Km
>
> _______________________________________________
> Dolibarr-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>

--
 <http://www.atm-consulting.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/dolibarr-dev/attachments/20161019/040e9f13/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


------------------------------

End of Dolibarr-dev Digest, Vol 163, Issue 6
********************************************



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

--
---------------------------------------
Christophe Battarel
Responsable technique Altairis

+33 (0)9 52 71 70 96
Altairis - Blog - Modules Dolibarr - Twitter
Financez vos projets avec Dolipro




_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev