On 02/23/11 04:28, Alexander Petukhov wrote:
If nobody mind, let me state my opinions:
1. Maintaining
I believe there has to be only one maintainer who is commiting code.
As for me, the amount of code in a ordinary geany plugin is not that huge,
one can easily support it. Others who has patches/improvements have to send them
to the maintainer and it's he, who decides what to do with them and is somehow
responcible for the result.
Giving commiting rights to several people can cause mess in code.
Isn't this how the current setup is? I thought it was just a courtesy
to not mess with the other plugins?
If the plugin is unmaintained for a long time, lets contact a developer to
learn his plans
and if he hasn't time for now (or at all) and there is someone else who wants
to do his job - let this man to become a new maintainer,
I think little developers will reject this suggestion if they really have no
time to deal with the code for now.
Current active maintainer have to mentioned on the plugins web-site in order to
contact him to solve problems / send patches etc
2. Documentation
Support Mathew, there has to be common documentation system,
maybe we can start from standartization README etc standart files
Maybe even to have a "plugin template" (GStreamer has this[1]), where
you clone from a repo/extract from a tarball all the standard files and
then add your source code and customize the templates (README, autotools
stuff, etc).
3. Different repos
Here I strongly disagree, I think this will also cause kind of a mess,
why not to solve problems in te common repository?
I guess I don't know enough about to Subversion to understand its
workflow. But this sounds better to me:
"The Fork + Pull Model lets anyone fork an existing repository and push
changes to their personal fork without requiring access be granted to
the source repository. The changes must then be pulled into the source
repository by the project maintainer. This model reduces the amount of
friction for new contributors and is popular with open source projects
because it allows people to work independently without upfront
coordination." [2]
But like someone said, this is a whole different thread, and I really
don't know enough about VCS to have a strong opinion.
4. Removing unsupported plugins from releases
what do you think about the following scheme: divide all pluging into:
- "supported" (that are acting really well)
- "unsupported" or "bad" (having problems) ?
So, every geany-plugins release will contain several packages: "geany-plugins",
"geany-plugins-bad or "geany-plugins-unsupported", something like this
This is like GStreamer plugins and I think it's a very good idea. They
could be grouped in the configure.ac file to add an option like
--enable-bad and --enable--unsupported or something.
5. Other language bindings - don't really think it can increase plugins quality
dramatically,
there can be problems in any language that you have to solve in order to make
your code work correctly.
I have to disagree with this for a few reasons:
- Many more people would write plugins if they could do it in their
"native" language (Just look at how many plugins Gedit has).
- I'd rather use a plugin written in Perl by a Perl guru, running on
it's interpreter, than Perl code written in C (ie. lets people use their
existing skills instead of translating them into bad C code).
- No memory leaks (ie automatic ref-counting, garbage collection)
- Isolation from Geany since most languages would be running under
their own VM/interpreter. Same reason you don't often (or ever?) see
Segmentation Fault when running a PHP or Python program for example.
- Rapid development. There's been many plugin ideas I've had myself
that I would've written if I could've done it in a couple evenings
instead of a month of evenings.
- People can still use the C API.
The only downside I can think of is the extra memory overhead of the
embedded interpreter.
My 0.02$
[1]
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-building-boiler.html
[2] http://help.github.com/pull-requests/
Cheers,
Matthew Brush (codebrainz)
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
