[Geany-devel] Git for plugins
elextr at xxxxx
Fri Aug 26 02:06:28 UTC 2011
On 26 August 2011 10:47, Matthew Brush <mbrush at codebrainz.ca> wrote:
> On 08/25/2011 03:27 AM, Frank Lanitz wrote:
>> On Thu, 25 Aug 2011 15:51:24 +1000
>> Lex Trotman<elextr at gmail.com> wrote:
>>> Yes, with DVCS each plugin can have its own repository and the Geany
>>> project only needs to manage the aggregated build.
>> Yes, this was the outcome on IRC. So once a feature is ready/bug has
>> been fixed a pull request is send to maintainer who is including them
>> into his/her tree. Once this has been done a snapshot of that tree
>> will be the release.
I don't know what was said on IRC (since if you don't happen to be
there at the time you can't contribute, and I am not going to search
through days of c**p in the logs)
My reasoning was based on past discussions around quality control of
the plugins. As noted in those discussions, plugins are more and more
providing essential capability and the aggregated plugins are being
released in the name of the Geany project. So the project gets the
blame for plugin problems and if it delegates functionality to plugins
it needs to take responsibility for their quality.
So I was basically proposing that the development of the aggregated
plugins follow the method of the main Geany (iaw your post) and so the
same quality criteria can be applied before changes go in the devel
branch thats heading towards a release. That has added a step from
the current process, but it is the same as that for the main app.
> I disagree with this. I think using a workflow more like I linked to
> previously where people work from feature branches, and only merge to
> "devel" when the feature is complete (or bug fixed, etc) would be better. I
> just feel like limiting access *more* than before is a step backwards for
> the project.
Who can do the commit to devel is a different question from the
workflow. The more responsible people who can do this the better
(applies to main app as well). But see comments about quality above.
> IMO, it would be better to give people the benefit of the doubt, and if
> someone continually pushes broken builds and stuff to the "devel" branch,
> then revoke access and work on a pull-request system like you mentioned.
Removing a permission from an individual is a very inflammatory
action, better to avoid it. The requirement is being responsible, not
necessarily technically brilliant.
> I do think there still is a place to have a maintainer, who will be the
> person who reverts changes made that break the build at will, without
> needing to ask other people for approval and who decides when it's necessary
> to revoke access.
> +1 for Frank for maintainer like this :)
Ditto if he has the time and interest.
More information about the Devel