Hi folks,
Since a few releases I'm experiencing some not optimal way of development which is surely caused by the long history we already have on g-p as well as by the many people around luckily contributing to the plugins collection: More and more plugins are going into some kind of an orphaned state. There is some maintainer available but not really responsive e.g. due to workload at reallife etc. However, at the end some of the plugins are still compiling but not effectively working any more with recent Geany version or its documentation is really outdated -- when I was preparing the commits for waf removing I have seen plugins still depending on Geany 0.16 ... I'm pretty sure, if they would, they would compile any more ;)
Also the documentation of each plugin are differing in style, size and quality much. (and I have to include the plugins I'm maintaining here 100% too). At github we already got a bunch of bug reports and pull requests for plugins waiting for any response. Also there is a long backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall experience for our users)
1) Deactivating all plugins / out comment all plugins from MAINTAINERS 2) Cleaning off NEWS, Changelog etc. from individual plugin folders 3) Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point) 4) Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little 5) Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc. 6) Release a cleaned up g-p 7) Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
Timeschedule: 1-4 until Xmas 2015, 5-6 until March.
Cheers, Frank
On 11/21/2015 15:42, Frank Lanitz wrote:
- Cleaning off NEWS, Changelog etc. from individual plugin folders
Personally I world prefer to keep Scope NEWS and ChangeLog. The global NEWS contains only the most important changes in short format, and the git change log, common to all plugins, is a poor substitution for the standard text file in widely used change log format.
That being said, I may soon turn into one of the "not really responsive" maintainers you are talking about, if I can't find a way to turn gtk+3 under Windows /medium text size/ into something decent looking. It never looked great, but the latest versions are completely tabletish, with nonsense settings as the ones I described in "gtk 3.16 statusbar size under Win~1".
-- E-gards: Jimmy
On 21.11.2015 19:05, Dimitar Zhekov wrote:
On 11/21/2015 15:42, Frank Lanitz wrote:
- Cleaning off NEWS, Changelog etc. from individual plugin folders
Personally I world prefer to keep Scope NEWS and ChangeLog. The global NEWS contains only the most important changes in short format, and the git change log, common to all plugins, is a poor substitution for the standard text file in widely used change log format.
I was thinking to have a verbose NEWS/ChangeLog inside doc/ tree but with some common style, but not yet a hard opinion about. To understand need of ChangeLog now a days: What is it used for between NEWS for end users and git log for developer? Where is the advantage (so we can find a good way).
Cheers, Frank
On 21/11/15 14:42, Frank Lanitz wrote:
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
Although being this offtopic, I think getting this complete support for GTK3 and package geany with GTK3 for major distros would be a great idea.
Regards, Akronix.
On 2015-11-21 5:42 AM, Frank Lanitz wrote:
Hi folks,
Since a few releases I'm experiencing some not optimal way of development which is surely caused by the long history we already have on g-p as well as by the many people around luckily contributing to the plugins collection: More and more plugins are going into some kind of an orphaned state. There is some maintainer available but not really responsive e.g. due to workload at reallife etc. However, at the end some of the plugins are still compiling but not effectively working any more with recent Geany version or its documentation is really outdated -- when I was preparing the commits for waf removing I have seen plugins still depending on Geany 0.16 ... I'm pretty sure, if they would, they would compile any more ;)
Also the documentation of each plugin are differing in style, size and quality much. (and I have to include the plugins I'm maintaining here 100% too). At github we already got a bunch of bug reports and pull requests for plugins waiting for any response. Also there is a long backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall experience for our users)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
I don't think I ever edited these files for my plugins, at least not after adding the plugin initially. All changes are in the Git log.
- Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point)
I don't like that all plugin files aren't self-contained inside own plugin dir. The "build" directory is already like this, plugins have to put M4 files separately into that dir. Maybe we could have a script that, when generating the manual, can just automatically combine all the markup files from each plugin dir?
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
This sounds OK, clean up the root dir a bit.
- Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc.
- Release a cleaned up g-p
- Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
I would add;
8) Rename all plugins that start with "Geany" to remove the "Geany" prefix. It's annoying in the plugin manager and in the source tree having all kinds of plugins clustered at the letter G, and obviously the plugins are for Geany.
9) Remove redundant plugins. Have a rule that only one plugin to do one thing is allowed and if someone wants to work on a plugin, they should either work on the existing plugin, or else give reasoning why a new plugin should replace the existing one. It's too confusing for users, and they end up using the wrong (old unmaintained) plugins.
10) Support for Git submodules so plugins don't have to be forked to be included in Geany-Plugins collection, they just need to use Autotools as their build system. This would also require making the build system to support building the plugins using (parts of) their build system.
Cheers, Matthew Brush
Hi,
On 21.11.2015 22:34, Matthew Brush wrote:
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
I don't think I ever edited these files for my plugins, at least not after adding the plugin initially. All changes are in the Git log.
Yes. And this is the reason why I'd like to purge them. The reason why they are there is IIRC an ancient need on something at autotools. Currently beside of Scope it's just adding noise to the repo and mostly outdated files.
- Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point)
I don't like that all plugin files aren't self-contained inside own plugin dir. The "build" directory is already like this, plugins have to put M4 files separately into that dir. Maybe we could have a script that, when generating the manual, can just automatically combine all the markup files from each plugin dir?
This is the exact point I want to get rid of. IMHO geany-plugins is one package and should behave like on package to the enduser when downloading the geany-plugins-release tarball.
In past having a project here and a copy there confused users a lot and it's adding overhead to plugins maintainer IMHO. Also having documentation here and there ended up in the mass of documentation we currently have. Current feature of plugins.geany.org is a good workaround but in time not the solution.
There might needs another solution for having g-p plugins and more plugins. Of course if we can integrate them into g-p it would be a benifit. I see adding e.g. geanypy just as distribution of geanypy for convenience not as main feature. (not saying anything the plugin itself)
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
This sounds OK, clean up the root dir a bit.
Good ;)
- Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc.
- Release a cleaned up g-p
- Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
I would add;
- Rename all plugins that start with "Geany" to remove the "Geany"
prefix. It's annoying in the plugin manager and in the source tree having all kinds of plugins clustered at the letter G, and obviously the plugins are for Geany.
Good point. Even when distributing with g-p there is really no need. As I'm having a bunch of geany*-plugins maintained the main reason was they started as project outside of g-p.
- Remove redundant plugins. Have a rule that only one plugin to do one
thing is allowed and if someone wants to work on a plugin, they should either work on the existing plugin, or else give reasoning why a new plugin should replace the existing one. It's too confusing for users, and they end up using the wrong (old unmaintained) plugins.
Which ones do you think of? I would say scope and debugger could be one pair of it. What else? And how to solve it as they do differ in target group and usecases I guess.
- Support for Git submodules so plugins don't have to be forked to be
included in Geany-Plugins collection, they just need to use Autotools as their build system. This would also require making the build system to support building the plugins using (parts of) their build system.
No, well, yes ... hmmm. I was thinking about that point and got to the idea, that I'd prefer a maybe smaller g-p with near cycle to geany-core as e.g. pidgin is doing it with some of the plugins. However, it could be possible. My main goal is having a src tarball at the end, which includes - Global, minimal README - Global NEWS, Changelog - plugins/-folder including all plugins code - doc/-folder including all plugins documentation
This could be also done during e.g. make dist. So a make dist could do a git submoule update etc. So pretty much I'm ok having a special rule for external plugins on git, but when packaging is ready it all should be all of a piece IMHO. How can we ensure the documentation fits together? What to do with translations? Please convince me ;)
Cheers, Frank
Am 21.11.2015 um 14:42 schrieb Frank Lanitz:
Hi folks,
Since a few releases I'm experiencing some not optimal way of development which is surely caused by the long history we already have on g-p as well as by the many people around luckily contributing to the plugins collection: More and more plugins are going into some kind of an orphaned state. There is some maintainer available but not really responsive e.g. due to workload at reallife etc. However, at the end some of the plugins are still compiling but not effectively working any more with recent Geany version or its documentation is really outdated -- when I was preparing the commits for waf removing I have seen plugins still depending on Geany 0.16 ... I'm pretty sure, if they would, they would compile any more ;)
Also the documentation of each plugin are differing in style, size and quality much. (and I have to include the plugins I'm maintaining here 100% too). At github we already got a bunch of bug reports and pull requests for plugins waiting for any response. Also there is a long backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall experience for our users)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
- Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point)
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
- Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc.
- Release a cleaned up g-p
- Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
Timeschedule: 1-4 until Xmas 2015, 5-6 until March.
Perhaps we should rethink what g-p is, or what we want it to be.
IIRC it was born simply as a collection of random plugins with two major purposes/requirements: - unified build system including shared translation(s) - combined release, thus shared release cycle
And nothing more than that. I don't think it was ever planed to establish some kind of minimum code quality or frequent maintainer actions. It was simply meant to provide a convinient service to plugin authors.
In the light of the above, I do think that current g-p is doing well and doesn't need to change (perhaps apart from cleaning multiple plugins doing the same thing). Plugins shouldn't be removed without good reason (i.e. if they're broken).
However, if we now start to add requirements to the above, then yeah, some actions like the ones Frank mention should be taken (perhaps removing dormant plugins). Keep in mind though, that that may mean *additional* burdens for maintainers, now and potential future ones, which I think is against the initial purpose of g-p.
Best regards.
On 22.11.2015 12:48, Thomas Martitz wrote:
Am 21.11.2015 um 14:42 schrieb Frank Lanitz:
Hi folks,
Since a few releases I'm experiencing some not optimal way of development which is surely caused by the long history we already have on g-p as well as by the many people around luckily contributing to the plugins collection: More and more plugins are going into some kind of an orphaned state. There is some maintainer available but not really responsive e.g. due to workload at reallife etc. However, at the end some of the plugins are still compiling but not effectively working any more with recent Geany version or its documentation is really outdated -- when I was preparing the commits for waf removing I have seen plugins still depending on Geany 0.16 ... I'm pretty sure, if they would, they would compile any more ;)
Also the documentation of each plugin are differing in style, size and quality much. (and I have to include the plugins I'm maintaining here 100% too). At github we already got a bunch of bug reports and pull requests for plugins waiting for any response. Also there is a long backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall experience for our users)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
- Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point)
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
- Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc.
- Release a cleaned up g-p
- Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
Timeschedule: 1-4 until Xmas 2015, 5-6 until March.
Perhaps we should rethink what g-p is, or what we want it to be.
Indeed that's a good question. IMHO g-p should be something for users. Therefore everything we do should fit with what a user would expect. I don't think about everything working out of the box with one click, but thinking about an user downlaoding an extension pack and wanting it to install and use with without collecting 200 different libraries and checking for documentation in 20 places. So there needs to be a single point to step in like an README and a single point or at least a reasonable place for documentation on how plugins work. Also I don't want to have a user having git, hg, bzr (read: many addition tools and steps to start finally compiling plugins) installed to just get the sources to make latest release-tarball running. Of course, I hope all plugin maintainers and contributors are users too so it should fit their developing process ;)
IIRC it was born simply as a collection of random plugins with two major purposes/requirements:
- unified build system including shared translation(s)
- combined release, thus shared release cycle
And nothing more than that. I don't think it was ever planed to establish some kind of minimum code quality or frequent maintainer actions. It was simply meant to provide a convinient service to plugin authors.
No. It was also meant to be a single point of contact for users. But we established it >7 years ago so I might remembering wrong -- and I don't want to grab archives as at least I didn't expect at this point Geany will become every this popular and we will have more than maybe 20 plugins at all.
The more important question for me is what will it be in future?
Cheers, Frank
Have been thinking about it for a bit.
Frank, I believe you are on the right track in considering that G-P should be for users which brings some implications like reliability, especially *thou shalt not crash Geany*, and some level of documentation, and a good set of useful features.
But thinking further about the last, to get a good selection of plugins G-P needs to support developers as well. It needs to provide a process that makes it easy for developers to add plugins and support for making useful documentation and to continue to develop the plugins.
So how to provide these? The rest of this post is one suggestion for how to implement it, but there are other possibilities, but whatever method is used, but should not lose sight of the principles above.
I don't think the current monolithic arrangement is suitable for providing the way forward.
@b4n has in the past ruled out a download based system for plugins, but perhaps its time to consider it further. G-P could provide the infrastructure to fetch the plugins when the user requests them, using a repository/package list that packagers can set for their distro, or from git(hub) for those plugins that don't need building (the future Python etc plugins) and for those with development environments it could get and build C/C++ plugins.
It is particularly important that the system is suitable to support no-build languages like Python, Autotools and m4 need not apply :). Thats the way to make it easier to develop plugins so more effort can go in the features and quality and less into low level hacking.
Because G-P would use a fixed list *reasonable* security features can allay some of @b4n's fears. The list should be provided by distros for the plugins that they package and in G-P git as a fallback referring to the git repos of the approved plugins.
The big advantage of such a system is that it can allow individual plugins to remain in their own repository rather than a central site, and they can have their own issue tracking without developers having to know about all the other plugins issues. G-P plugins would be mirrored on the Geany github for fallback purposes and for running quality control tests supporting translations etc. Having individual plugins in their own repository makes it much simpler for their developer to support them and will encourage more to be included so they become part of distributed G-P (see the list of "external" plugins on the G-P site).
There are many details to consider here, I don't think its a 1.27 target, but at least the process has started.
Cheers Lex
On 28 November 2015 at 19:22, Frank Lanitz frank@frank.uvena.de wrote:
On 22.11.2015 13:52, Frank Lanitz wrote:
The more important question for me is what will it be in future?
Any thought about this anybody?
Cheers, Frank
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Hi Frank,
sorry for replying so late. The proposal looks good to me except maybe...
On Sat, Nov 21, 2015 at 2:42 PM, Frank Lanitz frank@frank.uvena.de wrote:
Hi folks,
Since a few releases I'm experiencing some not optimal way of development which is surely caused by the long history we already have on g-p as well as by the many people around luckily contributing to the plugins collection: More and more plugins are going into some kind of an orphaned state. There is some maintainer available but not really responsive e.g. due to workload at reallife etc. However, at the end some of the plugins are still compiling but not effectively working any more with recent Geany version or its documentation is really outdated -- when I was preparing the commits for waf removing I have seen plugins still depending on Geany 0.16 ... I'm pretty sure, if they would, they would compile any more ;)
Also the documentation of each plugin are differing in style, size and quality much. (and I have to include the plugins I'm maintaining here 100% too). At github we already got a bunch of bug reports and pull requests for plugins waiting for any response. Also there is a long backlog at sf I've been told.
This is what I was thinking of to improve the situation (the overall experience for our users)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
- Moving documentation of all plugins into a structure like doc/<pluginname> to get a real fitting (online) manual. At this point update documentation and bring them to some markup stil (Rest? md? Docbook? I don't care at this point)
...this one - similarly to Matthew, I would also prefer having all the stuff related to a single plugin in the plugin's directory. What's the problem with the online manual? The build system should know the plugin directories and be able to pick the documentation files from each of them.
Related to this it would be nice to be able to easily detach a plugin from the geany-plugins repository so it can be e.g. developed separately between releases. But I'm not an autotools expert and don't know whether it's easy/possible to do.
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
- Reactivating plugins by a pull request of the actual (old|new) maintainer maybe doing steps 2-4 and comment back in the plugin in MAINTAINERS. Also I would be happy if at this point po/POTFILES.in is reviewed etc.
- Release a cleaned up g-p
- Post 1.27 puring not update plugins from src tree
What do you think about this idea? I would combine this with some release goals like complete support of Geany Gtk3 stack (if applicable).
In my opinion things like support for Gtk3 for all plugins are out of the scope of the geany-plugins project as a whole. If the maintainers of the plugins not supporting Gtk3 yet don't have time to add the support and nobody else cares enough to add it then what - remove the plugin because of that even if it works fine with Gtk2? IMO the task of geany-plugins should be to just know which plugins support Gtk3 and build only those which do.
For me at least geany-plugins is a kind of repository so users can find various plugins easily and at the same time serves geany developers to make changes to all the plugins when e.g. some API call changes. But the individual plugins inside are the responsibility of the individual maintainers. Of course the question is what to do if a plugin gets unmaintained - perhaps the best is to keep it as long as it builds and there aren't any major issues with it.
Cheers,
Jiri