On 26 August 2011 10:47, Matthew Brush mbrush@codebrainz.ca wrote:
On 08/25/2011 03:27 AM, Frank Lanitz wrote:
On Thu, 25 Aug 2011 15:51:24 +1000 Lex Trotmanelextr@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.
Hi Matthew,
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.
Cheers Lex