A request on another project's distribution list prompted me to accidentally generate a selection of comments about distcc instead. As I feel there is at least some value in what I said, I will repeat my message here for the expected target audience.
The originating message which prompted my response was: > I noticed that the list of pull requests for the munin contrib repository is > quite long. Thus it probably needs some love Now I should have been awake enough for the munin part to make me realise it was not about distcc but the coffee had obviously not soaked in. The idea that distcc could use some love did stick with me though. From this point on, my response is mostly unedited [although I put the odd new bit in square brackets here and there]. My suggestions for making things easier or breathing a little more life into the project are in the latter half. - - - It is and it does. I have eye-balled most of the requests and could merge them but I am unsure about which ones should go where. There is currently no defined plan [that I know of] for releases, feature requests and maintenance branches. My blindly merging any patch that turns up & compiles onto master might do more harm than good. [This got a response of That's probably true ;-)] Otavio and I were were talking about some vague ideas about getting automated builds working to make things simpler to maintain. To that end I had added tracis-ci.org build to my own fork; the results of which can be seen at: https://travis-ci.org/TafThorne/distcc It would require a distcc GitHub Project Administrator to activate the tracis-ci build for the main distcc project. Your email has prompted me to update my pull request https://github.com/distcc/distcc/pull/190 asking that the switch get flipped on the builds. > I am willing to put effort into the list of pull requests Thank you for the offer. Any help with reviewing pull requests would be greatly appreciated. > Do you have a formal process for granting commit access? > (just in case: my github account name is "sumpfralle") I do not know if we have much formal process for anything. I seem able to accept and merge code from pull requests, I think that means I am an authorised outside collaborator with write permissions for the source repository. I am not able to elevate other users or perform administrative functions on the distcc repository or the distcc organisation. I know several people on this list are the some of original authors of distcc and that they have higher permissions on the distcc organisation. Otavio is a recently added co-owner who helped with the migration of the project from Google Code before the project history was lost. There are also a handful of recently active contributors on GitHub who were trying to tidy up the loose ends of the 3.2 release. The most recent developments in that area can be found at https://github.com/distcc/distcc/issues/159 https://github.com/distcc/distcc/pull/178 https://github.com/distcc/distcc/pull/182 Perhaps yourself, Omer (thedrow, omerzimp), (paranormal), Anders (afbjorklund), I (TafThorne) and anyone else who is interest on this email list, could discuss a release strategy as the first step to becoming organised. Which versions do we want to do maintenance on? Do we feel that keeping Python 2.4 support is important? Can we merge anything that builds, passes a basic functionality test and does not seem a terrible idea straight onto master and put of thinking about a release until some date in the future? These are all probably things do ask on another thread. Sorry for being a bit verbal and taking your thread a little off topic. I did at least manage to answer your questions to begin with.
signature.asc
Description: OpenPGP digital signature
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc