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
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.
Am 16.11.2011 02:18, schrieb Matthew Brush:
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).
This wasn't the goal. The goal was to have one, single plugin release. Singe build wasn't goal and I'd like to don't some thinking about at this point.
Cheers, Frank
Hi Frank,
Although I am not a plugin developer I have a couple of suggestions based on the following needs:
1. Individual plugin maintainers shouldn't care about all the other plugins in the combined release 2. Users getting the combined release to build should get everything in one command 3. The combined release maintainers still need to be able to make changes to each plugin in case of urgent bugfix and temporarily or permanently missing individual plugin maintainer. 4. Not all plugins are in the combined release, due to quality, timing, or maintainer availability issues. But users rely on plugins so it is bad to remove their availability.
Having a single repository with branches fails item 1. since Git can't do partial checkouts/clones so all maintainers have all plugins and have to see all changes, a lot of noise. And accidental changes to parts of the tree outside the users plugin can be committed and pushed.
So I suggest that each plugin needs to have a separate repository under the Geany organisation. The plugin maintainer can fork these for development of their individual plugin in complete freedom and push to the repository when the plugin is ready providing item 1. These repositories also ensure Geany has a copy of the plugin under project control to prevent them disappearing or changing unexpectedly and to allow local bugfixes and quality checks to be made, providing item 3. I understand that access can be limited to specific repos so maintainers can't accidently change another plugin.
The combined release has its own repository that refers to the individual plugins ones. Git submodules allow the combined repository to point to specific versions of the individual plugin repositories, perfect for release functionality. Pushes from maintainers are not automatically included in the combined release until they have been quality checked.
Unfortunately this violates item 2 since users checking out the combined release need to know to pull the subprojects, a somewhat more esoteric thing than "git clone git://github.com/geany-plugins/geany-plugins.git" but we can put the necessary command in readme and other places. Other than that only the combined plugin maintainers need to know about the subproject technology, not individual plugin maintainers. This keeps the entry cost low for plugin maintainers.
Note that a plugin that fails to meet quality requirements, or some other criteria for inclusion in the combined release, still has its own repository available to users. So plugins can be added or dropped from the combined release whilst still being available to users from their individual repository, providing item 4.
Cheers Lex
Am 16.11.2011 07:12, schrieb Lex Trotman:
- Individual plugin maintainers shouldn't care about all the other
plugins in the combined release
Not a written, but existing rule.
- Users getting the combined release to build should get everything
in one command
ACK.
- The combined release maintainers still need to be able to make
changes to each plugin in case of urgent bugfix and temporarily or permanently missing individual plugin maintainer.
ACK.
- Not all plugins are in the combined release, due to quality,
timing, or maintainer availability issues. But users rely on plugins so it is bad to remove their availability.
ACK
Having a single repository with branches fails item 1. since Git can't do partial checkouts/clones so all maintainers have all plugins and have to see all changes, a lot of noise. And accidental changes to parts of the tree outside the users plugin can be committed and pushed.
I disagree a bit here. The goal is to have your own branch and work on your own branch for your plugin. Ones this is done you are sending a merge request to $release_team. You will not see whole noise - only if you do a git merge or rebase against master. Of course the commit and push is possible. But release team is asked to block such requests.
So I suggest that each plugin needs to have a separate repository under the Geany organisation. The plugin maintainer can fork these for development of their individual plugin in complete freedom and push to the repository when the plugin is ready providing item 1. These repositories also ensure Geany has a copy of the plugin under project control to prevent them disappearing or changing unexpectedly and to allow local bugfixes and quality checks to be made, providing item 3. I understand that access can be limited to specific repos so maintainers can't accidently change another plugin.
I did this with GeanyLaTeX, GeanySendMail and some of the others for a while and it wasn't worth as it was twice effort. It will not work out as most of the maintainer currently aren't able to do basic maintenance in time, they will not be able to do extra efforts e.g. for having a local build system which you will need.
The combined release has its own repository that refers to the individual plugins ones. Git submodules allow the combined repository to point to specific versions of the individual plugin repositories, perfect for release functionality. Pushes from maintainers are not automatically included in the combined release until they have been quality checked.
In general its a good idea, but for geany-plugin's purpose I'm not with you.
Unfortunately this violates item 2 since users checking out the combined release need to know to pull the subprojects, a somewhat more esoteric thing than "git clone git://github.com/geany-plugins/geany-plugins.git" but we can put the necessary command in readme and other places. Other than that only the combined plugin maintainers need to know about the subproject technology, not individual plugin maintainers. This keeps the entry cost low for plugin maintainers.
Hmmm.... No. Do users remember that the have to do regularly git submodules update?
Note that a plugin that fails to meet quality requirements, or some other criteria for inclusion in the combined release, still has its own repository available to users. So plugins can be added or dropped from the combined release whilst still being available to users from their individual repository, providing item 4.
This can be solved by deactivating the plugin in general build flavor by setting the autotools and waf parameters to Don't build. If user want to have, they could use --enable
Cheers, Frank
On 11/15/11 8:55 PM, 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.
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
Hi there,
I also vote for increasing plugins quality, but as for me Franks ideas about different branches seem a bit overcomplicated.
Maybe we can use git pre-commit hook to prevent commits that breaks some quality criteria? http://book.git-scm.com/5_git_hooks.html To be honest I didn't get much into details but it seemed to me that it can handle quality check tasks.
So my suggestion is still to use a single common repo for all plugins and use commit hooks to prevent unqualified code.
This requires that at some point all plugins in this repo pass this quality check, and here is what I suggest - move plugins from svn one by one, checking code for quality.
For those that didn't pass we can create a distinct repo under geany organization. Once a maintainer or a volunteer refine a code to fit the requirements it can be moved to a main repo. Until then it can be still available but won't be included in g-p release (maybe we can create distinct release geany-plugins-unsupported, as IIUC I already suggested once).
To easily move plugins between probably it's a good idea to use submodules, IIUC this is svn "externals" analogue.
To make every plugin compile and build independently I vote for eliminating common "po" catalog, that I also suggested recently, this will also help to avoid translations intersection between different plugins.
Renaming plugins in sense of removing "geany" prefix also can be done while moving.
So, here are the steps:
1. create distinct "po" catalog for every plugin, update build systems to allow building plugins individually 2. create code quality tests that can be used in git pre-commit hook 3. move plugins that pass a test to a "geany-plugins" GitHub repo (renaming if needed) 4. move the rest of plugins to a "geany-plugins-unsupported" GitHub repo (renaming if needed)
What do you think guys?
Regards, Alexander
Am 16.11.2011 12:02, schrieb Alexander Petukhov:
Maybe we can use git pre-commit hook to prevent commits that breaks some quality criteria? http://book.git-scm.com/5_git_hooks.html To be honest I didn't get much into details but it seemed to me that it can handle quality check tasks.
Well, this will need to maintain the hook e.g. on adding white rules for warnings that are common and don't hurt much. Give we don't add such thing, geanylua, prettyprinter and a bunch of other plugins will not be part of the party.
So my suggestion is still to use a single common repo for all plugins and use commit hooks to prevent unqualified code.
I diasagree as see above.
This requires that at some point all plugins in this repo pass this quality check, and here is what I suggest - move plugins from svn one by one, checking code for quality.
For those that didn't pass we can create a distinct repo under geany organization. Once a maintainer or a volunteer refine a code to fit the requirements it can be moved to a main repo. Until then it can be still available but won't be included in g-p release (maybe we can create distinct release geany-plugins-unsupported, as IIUC I already suggested once).
In basic thoughts I'm with you. As this will remove a bunch of plugins from repository and split up focus very much I'm afraid I have to disagree.
To easily move plugins between probably it's a good idea to use submodules, IIUC this is svn "externals" analogue.
I think submodules is nice for including external libraries into your source tree, but will make things more complicated by none visible extra from my point of view. Its against the idea behind geayn-pluings (see also below).
To make every plugin compile and build independently I vote for eliminating common "po" catalog, that I also suggested recently, this will also help to avoid translations intersection between different plugins.
This wasn't the goal behind geany-plugins as wrote in other. The goal was to have one single build system, one single translation and some more common infrastructure.
Renaming plugins in sense of removing "geany" prefix also can be done while moving.
This is up to the author of plugin ;D
Cheers, Frank
Am 15.11.2011 17:55, schrieb Frank Lanitz:
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.
I like this proposal. Requiring pull requests will also formally mean "get your plugin in shape" before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins.
However, there's one problem that isn't addressed, and I'm not sure it can be technically since it's more a cultural problem: There's IMO too little collaboration on plugins. It's kind of "each plugin to its maintainer", with little to no collaborative effort to form the best and greatest plugins. It feels like the source is available but not really open. OTOH perhaps my perception is just wrong, and this cannot be fixed by technical measures anyway.
Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The "combined release" idea came actually some time after that.
If the repos are separate and only merged for release, then they can just as well be separate entirely. So I disagree with that.They should be one repo, since they share a common code base via the translation and infrastructure.
Am 16.11.2011 07:12, schrieb Lex Trotman:
Although I am not a plugin developer I have a couple of suggestions based on the following needs:
- Individual plugin maintainers shouldn't care about all the other
plugins in the combined release
Not caring about other plugins is ok, but that doesn't mean his clone/checkout must not have other plugins.
- Users getting the combined release to build should get everything
in one command
This is status quo, and should be kept, yes.
- The combined release maintainers still need to be able to make
changes to each plugin in case of urgent bugfix and temporarily or permanently missing individual plugin maintainer.
I agree.
- Not all plugins are in the combined release, due to quality,
timing, or maintainer availability issues. But users rely on plugins so it is bad to remove their availability.
Covered by my suggestion to simply re-use the previous release.
Best regards.
Am 16.11.2011 13:06, schrieb Thomas Martitz:
I like this proposal. Requiring pull requests will also formally mean "get your plugin in shape" before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins.
I agree.
Cheers, Frank
[...]
I like this proposal. Requiring pull requests will also formally mean "get your plugin in shape" before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins.
Yes, using an older version is a good idea if it still builds ok. If it doesn't (eg devhelp plugin on some systems because only gtk3 version is available) then the decision needs to be made at the time to accept the upgrade or remove the plugin and what to do with it.
However, there's one problem that isn't addressed, and I'm not sure it can be technically since it's more a cultural problem: There's IMO too little collaboration on plugins. It's kind of "each plugin to its maintainer", with little to no collaborative effort to form the best and greatest plugins. It feels like the source is available but not really open. OTOH perhaps my perception is just wrong, and this cannot be fixed by technical measures anyway.
I don't think your perception is wrong, but I think that keeping plugins reasonably separate is also a good idea. As a user I can choose the parts I want without the parts I don't need. So only really tiny things should be combined like addons.
In other cases, like project management, there is sufficient variation in use-cases that there may be more than one plugin, like how the current project plugins address two slightly differernt uses. Or in some cases there is a natural progression from an old plugin to a new (and hopefully better) one, eg debugger plugins
What it needs is a technical solution to allow plugins to build on other plugins. That way the original functionality doesn't need to be re-built, but it introduces dependencies between plugins.
Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The "combined release" idea came actually some time after that.
I'm not sure that it prevents any of this, but as I now understand it, GP plugins can't be built separately so, yes, it makes less sense to have separate repos.
If the repos are separate and only merged for release, then they can just as well be separate entirely. So I disagree with that.They should be one repo, since they share a common code base via the translation and infrastructure.
As you say above, they actually share bugger all :)
[...]
Cheers Lex
Am 16.11.2011 22:50, schrieb Lex Trotman: [..]
I don't think your perception is wrong, but I think that keeping plugins reasonably separate is also a good idea. As a user I can choose the parts I want without the parts I don't need. So only really tiny things should be combined like addons.
We talked about this earlier on IRC and the goal of geany-plugins to have one single plugin bucket where plugins are not splitted up. Right now its already possible to build single plugins e.g. by using --enable flag on waf.
In other cases, like project management, there is sufficient variation in use-cases that there may be more than one plugin, like how the current project plugins address two slightly differernt uses. Or in some cases there is a natural progression from an old plugin to a new (and hopefully better) one, eg debugger plugins
What it needs is a technical solution to allow plugins to build on other plugins. That way the original functionality doesn't need to be re-built, but it introduces dependencies between plugins.
Dependencies? I agree. I think introducing changes to core about GObject etc will make such things easier. Currently its far away.
Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The "combined release" idea came actually some time after that.
I'm not sure that it prevents any of this, but as I now understand it, GP plugins can't be built separately so, yes, it makes less sense to have separate repos.
I agree ;)
Cheers, Frank