On 11/15/2011 08:55 AM, Frank Lanitz wrote:
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.
The point is closed, see the thread, apologies for not making that clear
enough. IIUC it's basically just a matter of someone pushing the repo
unless people have committed to SVN in the meantime I guess it needs to
be re-processed. See below for rest of reply.
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.
I like this idea, but depending on the criteria, it might become very
time-consuming (ex. if code reviews were involved for all the changes).
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 ;)
As I've proposed before, I still think the best option is to use Git
submodules[1]. IIUC it's basically "the right way" to do what you've
described above.
Doing it this way, each plugin developer would have their own git
repository[2] (on github.com or elsewhere), and the "release team" could
handle the pull/merge requests at critical points.
This has the advantage that each plugin could stand on it's own in
addition to being part of the "officially sanctioned" geany-plugins
project. IIUC people could choose to just checkout the one plugin or the
whole lot of them, or even just clone the plugin's main repository.
With some changes to the build system(s) it should be possible to make
each plugin buildable on its own or as part of the geany-plugins
project, as opposed to now, where it's difficult (impossible?) to have
your plugin build independently of the geany-plugins project and still
use Autotools (or Waf).
The main advantage though is that it allows this sort of "centralized
administration" and quality assurance of the main project as you're
describing, without making it overly complicated, basically just using
the tools we already have available.
I could probably fill another email or two with other advantages of
doing it this way, but I'm trying not to be so verbose :)
Cheers,
Matthew Brush
[1] http://help.github.com/submodules/
[2] or have a repository for each plugin under the geany organization,
with the appropriate permissions, which IIUC is what XFCE and GNOME do,
for example.
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel