On Thu, Mar 13, 2014 at 6:33 PM, Destailleur Laurent <e...@destailleur.fr>wrote:
> Hum, i see. > You're right. There is 2 different annoucements to do. I was thinking of > public one only. > I think we can progress only if things become automatic. We (and I) > continue to fails in some tasks as long as they are manual (when they can > be automatic). > > I have made enhancement recently into packaging script, to be better: > For example with 3.5.1, now setting the tag into GIT is done when making > package so we are sure tag is set and match with package (we frequently > forgot it). Also pushing to sourceforge is also done by script, saving a > lot of time. > > This is good to hear, also I think the best way is to use the git hooks post and pre commit and so on. There is plenty solutions about this kind of things out there. > I notice that we must now work onto annoucements: For public and also > communities. > > I would not complicate much on this but a simple heads up on the dev list that a release is coming is nice to have at least a week earler than the real release rolls out. > For public, i think to push news into web portal by a script (it can be a > generic message completed with changelog) so can be scripted too. Then > publish to social networks is already done automaticaly as soon as news is > onto portal. But we must wait new version of portal (currently in works) to > work on submitting news on portal. > > Great ! > For community annoucement, we can enhance/add scripts to send a generic > notice to dev ML. This is not best or enough but it is an easy step to do. > > In gnome.org there is a announces mailing list, so all the announcements go there, maybe a simple script can solve to mail the announcement to the correct ML. Rgds Saxa > > > > > > > > > > > > > 2014-03-12 21:44 GMT+01:00 Sasa Ostrouska <cas...@gmail.com>: > >> >> >> >> On Wed, Mar 12, 2014 at 8:18 PM, Doursenaud, Raphaël < >> rdoursen...@gpcsolutions.fr> wrote: >> >>> 2014-03-12 19:34 GMT+01:00 Destailleur Laurent <e...@destailleur.fr>: >>> >>> The release process is a process that takes a lot of work and need a lot >>>> of talks. It is not possible to do all this talks on one minutes, all at >>>> same time. That why notification may be sent few days after release, tests >>>> that all sync with mirrors are ok and that packages are ok. >>> >>> >>> Hi Laurent, >>> >>> I think you're missing that there are two different problems here : >>> - developper/translators/community announcement >>> - public/global annoncement >>> >>> Making the first announcement would warn everyone involved in the >>> community that a realease is about to happen. >>> This way Marcos would not have been surprised by an end user and would >>> have had the perfect answer : "The release is not _yet_ official, please >>> wait and refer him to the release process rules" and Saxa would have known >>> he needed to hurry for it's change to be integrated in the next release. >>> >>> I completely agree with you here, other projects do exactly that way, >> even gnome which is huge project do anouncements >> with exact dates for the release and they do start pushing out on the >> servers the tarballs few days earlier. >> >> >>> Your view is valid for the second case, for which I completely agree >>> with you : >>> It should only be done once we're sure everything went smoothly but you >>> can't prevent people from monitoring sourceforge. >>> >>> To be honest I have not even known that this project is using this >> sf.net functionality :). >> >> Rgds >> Saxa >> >> Anyway, our process is far from perfect and needs some love. >>> I'm ready to help as much as I can but the way I work, I prefer to raise >>> a consensus before doing any work hence my call for comments on the wiki. >>> (BTW it's missing talk pages that are usefull for this kind of work.) >>> >>> 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 EURO - R.C.S. PAU 528 995 921 >>> <https://www.google.com/a/partnersearch/#partner?partner_id=46687933_a0n60000000sqpWAAQ><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 >> >> > > > -- > 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/astats_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
