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.
I notice that we must now work onto annoucements: For public and also communities.
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.
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.
2014-03-12 21:44 GMT+01:00 Sasa Ostrouska <address@hidden>:
On Wed, Mar 12, 2014 at 8:18 PM, Doursenaud, Raphaël <address@hidden> wrote:
2014-03-12 19:34 GMT+01:00 Destailleur Laurent <address@hidden>:
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 annoncementMaking 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 anouncementswith 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 DoursenaudDirecteur technique (CTO)
Technopole Hélioparc2 avenue du Président Pierre Angot64053 PAU CEDEX 9SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921_______________________________________________
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
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