[distcc] Project Planning

[Thomas A. F. Thorne]

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.

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.

[Anders Björklund]

Post by Thomas A. F. Thorne
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

The suggestion was to do the branch-out of 3.2-maint _before_ changing
from python to python3. My suggestion of allowing python2 was rejected.
So you would have one maintenance branch that still "allowed" the
system's python in maintenance and one master that required python3...

I suppose you want to do some 3.3 releases from master, at some point.
But tagging the 3.2rc1 and doing some 3.2.x release would be a start ?

Post by Thomas A. F. Thorne
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.

I'm not sure what the plan was for pump mode, after the 2to3 upgrade.
Just thought it was a bit overkill, especially if not using it (pump)

More interesting would be the bug fixes:
https://github.com/distcc/distcc/pull/160
https://github.com/distcc/distcc/pull/161
Currently everything is hardcoded to "4".


So get the project maintenance on track, and I can help with the code.

The python thing is not terribly important to me, so just do either...

/Anders
(afbjorklund, itensionanders)
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.

[Thomas A. F. Thorne]

Post by Anders Björklund
I suppose you want to do some 3.3 releases from master, at some point.
But tagging the 3.2rc1 and doing some 3.2.x release would be a start ?

Sounds like a reasonable idea to me.

Post by Anders Björklund
The suggestion was to do the branch-out of 3.2-maint _before_ changing
from python to python3.

This also sounds sensible. There are 74 issues currenlty on the git site of the project. There have been a lot of changes since the 3.1 release we have tagged so drawing a line in the sand my kicking off a 3.2 release would be a good start.

We can deside which issues are enhancments and bugs. Which are high, medium or low priority. Then make a commitment to try and fix the high priority bugs on the 3.2 maintenace line which will be maintained for Python 2 for now.

Following that we can decide if we want to try and support Python 2 & Python 3 or just Python 3 in the 3.3 and onwards releases. I know that Ubuntu and a few other systems are swtiching of ther 3 being the default.

Regards, Tom

[Thomas A. F. Thorne]

Dropping Python 2 Support

(or more specifically moving up to python2.7 from python2.4 on a
maintenance branch and dropping python3 support from master)

Having looked into starting a 3.2 release or 3.2_maintenance branch I
stumbled into the https://github.com/distcc/distcc/pull/177 request.
Under that request the creation of the 3.2 maintenance branch is
suggested and it is proposed that said branch will be used to maintain
some support for Python2.7 for as long as it seems necessary.

The main work would continue on master, with the creation of a 3.3.#
release in the near future. The master branch (and therefore the 3.3
releases onwards) would require python3.


What do the viewers of this list think of the proposal?



Silence will be taken as support. If the action is supported I will try
an action at least some of it at the end of the month.

Regards, Thomas

[Anders Björklund]

Post by Thomas A. F. Thorne
Dropping Python 2 Support
(or more specifically moving up to python2.7 from python2.4 on a
maintenance branch and dropping python3 support from master)

The actual suggestion was to drop python _2.2_, but leave the rest.
There was nothing on the maintenance branch that required newer...

Post by Thomas A. F. Thorne
Having looked into starting a 3.2 release or 3.2_maintenance branch I
stumbled into the https://github.com/distcc/distcc/pull/177 request.
Under that request the creation of the 3.2 maintenance branch is
suggested and it is proposed that said branch will be used to maintain
some support for Python2.7 for as long as it seems necessary.

The half-way option (drop the really old stuff, keep the default
system /usr version of python on enterprise linux releases) was in:

https://github.com/distcc/distcc/pull/182

The master branch can stay as it is. That is, only support python3
but not any variant of python2 (2.7). Mostly for "non-pump" mode.

Post by Thomas A. F. Thorne
The main work would continue on master, with the creation of a 3.3.#
release in the near future. The master branch (and therefore the 3.3
releases onwards) would require python3.

Sure, I have no problem with that. I'm not sure _what_ development that
was planned on "master" (that required python3), but it's there already.

I also suggest getting off the "3.2rc1" track, and releasing real 3.#.#
Is there anything on master that needs a 3.3 release ? The swift stuff ?


i.e. supposedly you would also do a maintenance branch for 3.3 as well.
(if you decide to fork it off from master, that is). And then merge.

Something like a road map would be nice, to see what the difference is.
Maybe 3.2 should have been forked even earlier in history, I dunno...


But it would be nice to do another "stable" release after distcc-3.1.
Which is from 2008 already.

Many stay off the distcc-3.2rc1, because of the silly release suffix.
And that was back in 2011 ?

/Anders
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba

[Thomas A. F. Thorne]

Thank you for clearing up the misunderstandings I had.

Post by Anders Björklund
Something like a road map would be nice, to see what the difference is.
Maybe 3.2 should have been forked even earlier in history, I dunno...

That would be nice and might be a bit of work. I can try and skim back
over the commit history and see what major features are in since the 3.1
release we have marked. It would be quite nice to fill in some of the
release notes in GitHub too so I will try and do that based on older
documents and changeset too. Once we can see the past perhaps we can
plan for the future.

Post by Anders Björklund
But it would be nice to do another "stable" release after distcc-3.1.
Which is from 2008 already.

That is what I see most people asking for. I am not sure there are new
features the core program needs to do. If we were going to go for a
snazzy dynamic system with (web) GUIs I think it would need to be
facilitated by a suit of micro-services in the modern and classic UNIX
style.

Post by Anders Björklund
Many stay off the distcc-3.2rc1, because of the silly release suffix.
And that was back in 2011 ?

I am more familiar with Semantic like visioning as described in
http://semver.org/ so would be quite happy to switch to that. Perhaps
the first job should be to release a 3.1.1 release as an updated
stable. Numbers and names are not that important as long as people can
understand their intent. I am happy to go with whatever the group feels
would best fit.

Looking at this I realise I probably should have made three separate
responses so we would have a Roadmap, Stable and Version Numbering
thread. This list does not have a high volume though. People can
narrow the scope on reply if they feel the need.

I shall try and scribble some release notes before months end and get
back to you all.