[distcc] Project Planning

Thomas A. F. Thorne tafthorne at googlemail.com
Wed Oct 5 14:24:27 UTC 2016


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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/distcc/attachments/20161005/245ffff4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/distcc/attachments/20161005/245ffff4/signature.sig>


More information about the distcc mailing list