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) :-) > > > 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 > > <[email protected] <mailto:[email protected]>> > > 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: [email protected] > > Dolibarr developer: [email protected] > 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
