Re: [Dolibarr-dev] 3.2 frozen for any new features

[Sasa Ostrouska]

On Fri, Apr 13, 2012 at 4:05 AM, Juanjo Menent <address@hidden> wrote:
> Hi,
>
> completely agree!
>
> and I also included....
>
> I think we do not we take full advantage to the doliforge....
>
> El vie, 13-04-2012 a las 08:46 +0200, Régis Houssin escribió:
>
> hi,
>
> I am not against the principle of freezing a version, but why should we
> have a clear roadmap with clearly defined development goals, which is
> not really the case. Everyone does it on its side soup without any
> consultation and suddenly we are never synchronous on the status of
> each. We must be more diligent in using at least the management tasks in
> doliforge. (me included) :-)
>

Hi , I don't get exactly what you mean. But any development should
have a clear roadmap, this simplify
the development itself, especially when its a community driven
project. One good tool I know is trac, and of course a bug tracker
comes out very usefull in this situations, because you can open a bug
or a ticket for each task.

If there is no common roadmap, it is quite normal anybody works on its
own priorities and therefore comes out a big mess to maintain.

Rgds
Saxa

>
> je ne suis pas contre le principe de figer une version, mais pour ça il
> faudrait qu'on ai une roadmap clairement défini avec des objectifs de
> développement clairement défini, ce qui n'est pas vraiment le cas
> actuellement. Chacun fait ça soupe de son côté sans aucune concertation
> et du coup nous ne sommes jamais synchrone sur l'état d'avancement de
> chacun. Il faut qu'on soit plus assidu à utiliser au moins la gestion
> des tâches dans doliforge. (moi le premier) :-)
>
>
>
> Le 13/04/12 01:05, Sasa Ostrouska a écrit :
>> Hi, I would say, that beta , RC and other names are used, as Eldy said,
>> exactly to make a point from where a maintainer of the code decides that
>> the code is
>> becoming stable and bug free with the features it has. This explains
>> exactly that adding new features is not allowed, and contradictory.
>>
>> VCS (Version Control systems) were invented exactly to simplify this
>> process. This is whay they permit you to branch and tag code.
>>
>> So in my opinion alpha, beta and any other code tag should never receive
>> new features. If it receives new features it is not alpha or beta or
>> release candidate , but its development code.
>>
>> Rgds
>> Saxa
>>
>> On Wed, Apr 11, 2012 at 11:14 AM, Cyrille de Lambert
>> <address@hidden <mailto:address@hidden>>
>> wrote:
>>
>>     Pour info, il y a pas mal de bugs à corriger (version 3.1) ->
>>     exemple sur les filtres (commande fournisseur entre autre) qui se
>>     réinitialisent alors que ce ne devrait pas être le cas.
>>     Vu qu'on est (encore) complètement perdu avec GIT, ce sont des
>>     choses qu'on avait corrigé mais  qu'on a surement perdu en cours de
>>     route.
>>     Je vais faire un tours de cette version bêta pour voir ce qui va ou
>> pas.
>>
>>
>>     Cyrille
>>
>>
>>     Le 11/04/2012 16:03, Laurent Destailleur (eldy) a écrit :
>>>     Ajouter des fonctionnalités et faire des comit pour en compléter
>>>     d'autres reviens au meme, on crée de l'instabilité sur ce qui a
>>>     été validé comme stable.
>>>     Si des commits enlevés rendent bancales des choses, c'est qu'il y
>>>     avait bug avant d'etre enlevés et la beta est la pour les
>>>     corriger. Et si cela corrigent ces bugs, les changement seront
>>>     acceptés, donc pas de problèmes.
>>>
>>>     J'accepte les bleus au visage. L'interet des utilisateurs étant
>>>     prioritaire sur ma santé ou sur l'interet des développeurs.
>>>
>>>     :-)
>>>
>>>
>>>     Le 11/04/2012 15:55, Régis Houssin a écrit :
>>>>     je parle en french car j'ai pas le temps de googliser
>>>>
>>>>     je ne parlais pas de rajouter des fonctionnalités mais de
>>>>     compléter ce
>>>>     qui était en train de se faire, car certains des commits que tu as
>>>>     enlevé va rendre bancale les devs en cours, ce qui va encore
>>>>     rendre la
>>>>     3.2 non finalisée, et des gueulards et des énervements et des
>>>>     coups de
>>>>     poings dans la gueule et des bleus au visage ;-))
>>>>
>>>>
>>>>
>>>>     Le 11/04/12 15:47, Laurent Destailleur (eldy) a écrit :
>>>>>
>>>>>     Le 11/04/2012 14:55, Régis Houssin a écrit :
>>>>>>     but we will still end up in the same case, the 3.2 become
>>>>>>     obsolete even
>>>>>>     before being output :-)
>>>>>     Wrong. Adding new features in a release means restart from the
>>>>>     end the
>>>>>     beta and having beta delay that last 8 month (like it was for 3.1).
>>>>>
>>>>>     Saying we can't release because it miss feature is not a good
>>>>>     way of
>>>>>     thinking. It means, Dolibarr should not have been released at
>>>>>     all even
>>>>>     in version 1 and should not be released even in 5 years.
>>>>>     Imagine a feature is rejected because it was done just the day
>>>>>     after the
>>>>>     froze, at t=0 (+1 day). This feature will be included in next
>>>>>     beta, so
>>>>>     only two month after at t=+2 month, so can be released at t=+6.
>>>>>     This
>>>>>     means the feature you say it miss, will be available at t+4
>>>>>     instead of
>>>>>     t+8 (if it is t+8, it might be t+12 if we keep add changes into
>>>>>     beta).
>>>>>     And t+4 is better than t+8 !
>>>>>     We saved 4 month to have new features. So, adding features in a
>>>>>     beta is
>>>>>     a lost of time for everybody and it is the worst way to have
>>>>>     missing
>>>>>     feature in current stable version because the complete version that
>>>>>     include it can't be release before several month. Users must not
>>>>>     wait so
>>>>>     long, that's why we must end with changes into a beta branch,
>>>>>     just to
>>>>>     have more feature, faster !
>>>>>
>>>>>
>>>>>     Don't forget this :  There is commit every day to add features and
>>>>>     whatever you do, you will always have missing features. If we
>>>>>     don't make
>>>>>     any stop, we will never make release or we will need to wait 8
>>>>>     month
>>>>>     like we did for 3.1 to have a beta stable (and it should be more
>>>>>     if i
>>>>>     didn't stopped adding features into beta, and there was still
>>>>>     lot of
>>>>>     bug, curiously, most of them was bugs introduced by change of last
>>>>>     minutes). Making a version stable (that is most important that
>>>>>     having a
>>>>>     feature) consumes most of time of core team that make the beta
>>>>>     tests,
>>>>>     time wasted.
>>>>>     Features can come two times faster if we respect best practices
>>>>>     seriously, and version will be less obsolete when it will be
>>>>>     released.
>>>>>
>>>>>>     Le 11/04/12 12:41, Laurent Destailleur (eldy) a écrit :
>>>>>>>     Sorry.
>>>>>>>     A beta is a beta.
>>>>>>>     Adding something else means all time spent by tester to
>>>>>>>     guarante that
>>>>>>>     everything is stable must be started again.
>>>>>>>     We can't always add new features or add complement on a frozen
>>>>>>>     version.
>>>>>>>     Any change, even minor that is a new feature breaks stability.
>>>>>>>     Just an example, 60% of time I spent to make beta 3.0 and 3.1
>>>>>>>     stable was
>>>>>>>     spent to restore stability by forbidden adding feature or
>>>>>>>     architecture
>>>>>>>     change. This is not acceptable. This rate should be 0%.
>>>>>>>     Any change that are not fix will be discarded if it is not to
>>>>>>>     fix a bug,
>>>>>>>     translation or documentation.
>>>>>>>
>>>>>>>
>>>>>>>     Le 11/04/2012 12:32, Régis Houssin a écrit :
>>>>>>>>     yes but no, they are commits that complement the current dev,
>>>>>>>>     we'll
>>>>>>>>     still end up with 3.2 sloppy, they should be able to include
>>>>>>>>     minor
>>>>>>>>     additions in this 3.2
>>>>>>>>
>>>>>>>>
>>>>>>>>     Le 11/04/12 11:00, Laurent Destailleur (eldy) a écrit :
>>>>>>>>>     Hi Dolibarr developers.
>>>>>>>>>
>>>>>>>>>     I revert some changes into the 3.2 branch because they were
>>>>>>>>>     introducing
>>>>>>>>>     new features.
>>>>>>>>>     Absolutely no change must be done into the 3.2 branch,
>>>>>>>>>     except if a bug
>>>>>>>>>     is found and change must fix only the found bug.
>>>>>>>>>     Code normalizing and new features must be push using github
>>>>>>>>>     into the
>>>>>>>>>     develop branch only.
>>>>>>>>>
>>>>>>>>     Cordialement,
>>>>>>     Cordialement,
>>>>     Cordialement,
>>>
>
>
> Cordialement,
> --
> Régis Houssin
> ---------------------------------------------------------
> Cap-Networks
> Cidex 1130
> 34, route de Gigny
> 71240 MARNAY
> FRANCE
> VoIP: +33 1 83 62 40 03
> GSM: +33 6 33 02 07 97
> Web: http://www.cap-networks.com/
> Email: address@hidden
>
> Dolibarr developer: address@hidden
> Web Portal: http://www.dolibarr.fr/
> SaaS offers: http://www.dolibox.fr/
> Shop: http://www.dolistore.com/
> Development platform: https://doliforge.org/
> ------------------------------
> ---------------------------
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>