On Fri, 26 Aug 2011 12:06:28 +1000 Lex Trotman elextr@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.
Yes.
Cheers, Frank