Project Planning

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============6188366348515468322==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="FCsLVi1UJLv7pPg3fR0vakf3FgQNvRHKj"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FCsLVi1UJLv7pPg3fR0vakf3FgQNvRHKj
Content-Type: multipart/mixed; boundary="ueJCNhv0mx7fWoas47fWOI8mIdMxmK09P"
From: "Thomas A. F. Thorne" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Subject: Project Planning

--ueJCNhv0mx7fWoas47fWOI8mIdMxmK09P
Content-Type: multipart/alternative;
 boundary="------------D262DCE449528DD073D94744"

This is a multi-part message in MIME format.
--------------D262DCE449528DD073D94744
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

A request on another project's distribution list prompted me to accidenta=
lly generate a selection of comments about distcc instead.  As I feel the=
re is at least some value in what I said, I will repeat my message here f=
or the expected target audience. =20

The originating message which prompted my response was:
> I noticed that the list of pull requests for the munin contrib reposito=
ry is
> quite long. Thus it probably needs some love=20
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 thi=
s point on, my response is mostly unedited [although I put the odd new bi=
t in square brackets here and there].  My suggestions for making things e=
asier or breathing a little more life into the project are in the latter =
half. =20
- - -


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.=20

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 o=
f 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.=20

> 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.=20

> 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.=20

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.=20

Sorry for being a bit verbal and taking your thread a little off topic.=20
I did at least manage to answer your questions to begin with.=20


--------------D262DCE449528DD073D94744
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <pre wrap=3D"">A request on another project's distribution list promp=
ted me to accidentally generate a selection of comments about distcc inst=
ead.  As I feel there is at least some value in what I said, I will repea=
t my message here for the expected target audience. =20

The originating message which prompted my response was:
<blockquote type=3D"cite"><pre wrap=3D"">I noticed that the list of pull =
requests for the munin contrib repository is
quite long. Thus it probably needs some love <span class=3D"moz-smiley-s1=
" title=3D":)"></span></pre></blockquote>Now I should have been awake eno=
ugh 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 mostl=
y unedited [although I put the odd new bit in square brackets here and th=
ere].  My suggestions for making things easier or breathing a little more=
 life into the project are in the latter half. =20
- - -


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.=20

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 &amp;
compiles onto master might do more harm than good. [This got a response o=
f 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:

<a class=3D"moz-txt-link-freetext" href=3D"https://travis-ci.org/TafThorn=
e/distcc">https://travis-ci.org/TafThorne/distcc</a>

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 <a class=3D"moz-txt-link-freetext" href=3D"http=
s://github.com/distcc/distcc/pull/190">https://github.com/distcc/distcc/p=
ull/190</a>
asking that the switch get flipped on the builds.=20

</pre>
    <blockquote type=3D"cite" style=3D"color: #000000;">
      <pre wrap=3D"">I am willing to put effort into the list of pull req=
uests
</pre>
    </blockquote>
    <pre wrap=3D"">Thank you for the offer.  Any help with reviewing pull=
 requests would be
greatly appreciated.=20

</pre>
    <blockquote type=3D"cite" style=3D"color: #000000;">
      <pre wrap=3D"">Do you have a formal process for granting commit acc=
ess?
(just in case: my github account name is "sumpfralle")
</pre>
    </blockquote>
    <pre wrap=3D"">I do not know if we have much formal process for anyth=
ing.  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.=20

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
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/distcc/dist=
cc/issues/159">https://github.com/distcc/distcc/issues/159</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/distcc/dist=
cc/pull/178">https://github.com/distcc/distcc/pull/178</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/distcc/dist=
cc/pull/182">https://github.com/distcc/distcc/pull/182</a>

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.=20

Sorry for being a bit verbal and taking your thread a little off topic.=20
I did at least manage to answer your questions to begin with. </pre>
  </body>
</html>

--------------D262DCE449528DD073D94744--

--ueJCNhv0mx7fWoas47fWOI8mIdMxmK09P--

--FCsLVi1UJLv7pPg3fR0vakf3FgQNvRHKj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX9Q0bAAoJEPXLKKkUazGA+lYIALVi0jsO1gSJcWFsQ1Y2QDiu
yL1LCuJfSJqKhQq2jVh1iDrWlhdpNlONqjzLD6yoAai9olY1EfmHFNkp15qDfALF
pHZeIQBqCqKg4g5OErbpaBxgaoGDVqbXp3kon936+8knFmXlXTYF0rt+3kic9BOj
FfzKxLKVFLltfUhZDKY7QKUo9kpp/+MzmSaz0WQGfkpZpOjzttufHYqakwY8Lsby
u/MIcvsfbK0l668NKDCE4mHygFREDYky5Fh9aiNwf8kCpRJ1azHksezXv62tuzZh
ctbwbboDSNZRJoPJM4lEucFd30oMLu0IkNQjMvqCdccWzX8/6ApKXH6Yq8cTQ/o=
=FCcD
-----END PGP SIGNATURE-----

--FCsLVi1UJLv7pPg3fR0vakf3FgQNvRHKj--


--===============6188366348515468322==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X18KZGlzdGNjIG1haWxpbmcgbGlzdCAgICAgICAgICAgIGh0dHA6Ly9kaXN0Y2Muc2FtYmEub3Jn
LwpUbyB1bnN1YnNjcmliZSBvciBjaGFuZ2Ugb3B0aW9uczoKaHR0cHM6Ly9saXN0cy5zYW1iYS5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaXN0Y2M=

--===============6188366348515468322==--