[Geany-devel] Git for plugins
frank at xxxxx
Sat Aug 27 18:23:11 UTC 2011
On Fri, 26 Aug 2011 12:06:28 +1000
Lex Trotman <elextr at gmail.com> wrote:
> 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.
Yepp. That's true.
> 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 agree also. This was at least one idea behind my original proposal.
> > 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 agree. Mistakes are something, everybody might do at some point.
Punishment might not the right answer as it will cause insecurity on
committing for the author. Is my commit good enough? Shall I better
don't do it? etc ...
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the Devel