Hello fellow FreeRDP developers, I’ve been involved in past with FreeRDP project and O.S. Systems is an active contributor of the project as well so I am comfortable to make a proposal to gather people opinions about it.
FreeRDP is a bright and life project; it has accomplished many nice challenges since it begin and with 1.0 we did what many people thought it would be impossible: we rewrote it from scratch! That said, the workflow used for it wasn’t well documented and mostly done as a code FIFO so code being done were continuously being merged on master for use as base for next day of work. FreeRDP now is being use by many projects that goes from small in-house use to commercial solutions; the wider use it turns, more users starts to depends on it. Bugfix releases are important to have but quite difficult with current workflow. I see current workflow as: * work for a feature is started * some code is written for it * as soon as it works more or less it is merged on master This has very serious problems for maintenance point of view. The main ones I see are: * not ready to use features in master * difficult to identify bugfixes * difficult to port bugfixes to old releases * a movable target all the time So to make FreeRDP more manageable and start having faster releases I’d like to propose a change on this workflow mostly following what is done in Linux and is prove to work fine: * every new feature needs to be done in a branch * new features are merged in first week of release development * after merge window we release rc1 * every week we release a rcX and only bugfixes are accept for merging * regressions are release blockers * bugfixes in new features may be release blockers If we follow this workflow I think we will have one FreeRDP release every 45 days, maybe less. This will reduce the amount of new features in every new release but at same time it might give us a stable release at end. Since the release cycle will be short if a feature that is not ready for the merge window can be easily postponed for next release; maintenance branch are not much importance as it will be easy for distributions to cherry-pick specific bugfixes from development branch, and another good effect of this is that features will be develop in a more stable base. Obviously it won’t be easy to change the habit of development of people working at FreeRDP but if we all help each other this can be done. I’m convinced that this workflow will make FreeRDP a bigger and widely used project in the end but as it is a community project, the community is in charge to decide what is better or not. So, what’s your call? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
