Hi developers, It has been a while when I first announced a mail about my idea of process after transition of geany-plugins repository. As from my understand the only open point is to have clarified the svn-url-reference question its a good point to tell you what I'm thinking of.
Currently we do have about 25 people which are allowed to commit to geany-plugins svn. Not all of them are active at the moment (and might won't get active again sometime in future), some of them are low in time or no responsive at the moment. On the other hand we do have about 30 plugins, which are mostly maintained. As you know from discussion about e.g. geanydbg/debugger and the project plugins, some of them are currently not maintained very actively and are getting obsolete. Given the changes for Python plugin support in pipeline of Geany I'm in a good mood that we will have a increasing number of contributors and plugins available for Geany. Some of the new plugins will be distributed via the geany-plugins-project for sure as well as contributors like to add maybe features, bugfixes etc. to existing code basis. Unfortunately in past we had not really some kind of a quality assurance on committing code beside authors and maybe devel users. We introduced the make check build target a couple of month ago which gave a more critical view onto code. Based on this a huge number of warnings, memory leaks and bugs has been able being removed. But still issues are left. As we will have some kind of a reset with movement to github, its a good point to rethink about the way, how patches are introduced to geany-plugins. So this is my idea how to do so: We will have one master branch where all changes intended for releasing are going in. Features and new plugins are going to be developed inside branches (more late onto this topic) and once they are in a suitable status, they are getting merged into master branch. Release are generated from master branch and are getting marked with a tag. If there is any need for some minor release as we had e.g. with 0.21.1 there will be a release branch that will include all patches going in. If they are also needed to get applied on master, we can cherry-pick them or find some other way of merging them back. We can divide contributors for plugins into 2 groups: 1: Contributors to existing plugins or general infrastructure as e.g waf/autotools 2: Contributors of new plugins Here we should set up 2 processes: Contributions of group 1 should clone the repository and sending a pull request or patch to maintainer of plugins. Once they did this, the maintainer is reviewing the changes and including them into his branch. Contributors of new plugins shall send a pull request of full diff to release team. And this is another point. I imagine to have a release team which is taking care of overall quality of geany-plugins. This is including following: If a plugin maintainer is finishing a change or a review he is sending a merge request to the release team. After they did a review based on criteria given e.g. inside HACKING they are merging it into master branch. If the patch is not hitting a minimum on quality its getting refused. Thins to be done in front if you like this change: - Defining release team - Reviewing HACKING and defining basic quality criteria - Pushing all to github ;) What do you think? Feedback is highly welcome ;) Cheers, Frnak _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
