Mailing List Archive

At 03:41 PM 9/11/95 MDT, you wrote:
>
>> Who's the patch coordinator for 0.8.13?
>
>it hasn't been discussed. You can volunteer if you want :-)
>

Only if you tell me what I should be doing? >:->
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

On Mon, 11 Sep 1995, Aram W. Mirzadeh wrote:
> At 03:41 PM 9/11/95 MDT, you wrote:
> >
> >> Who's the patch coordinator for 0.8.13?
> >
> >it hasn't been discussed. You can volunteer if you want :-)
>
> Only if you tell me what I should be doing? >:->

A patch coordinator needs to

1) maintain the patch repository for that particular build

a) make sure things are organized intelligently, with comments in
the patches as to why the patch is needed

b) monitor the mailing list and newsgroups for patches.

2) do a sanity check on the patches submitted first

a) make sure they patch cleanly - if not, create a clean patch using
diff -C3 which does not depend upon other patches

b) make sure patch makes sense in the context of the architecture and
the principles of cross-platform and least-astonishment

c) do an initial test on the patch to make sure it does what it claims
to do

if any of these fail, ask the patch submitter to submit again.

3) when a sufficient number of patches have been submitted, close the
patch submission for this round and leave two or so days for
comments/testing of the various patches. Then, create a ballot and
send to the list - hold the vote open for a day or two, and then tally.
finally, present results to the list and build the next release.


I may be missing something... Rob(s)? Roy?

Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

> Who's the patch coordinator for 0.8.13?

it hasn't been discussed. You can volunteer if you want :-)


rob

What's the saying... fools jump in where wise men don't....

Well, I guess I'll have to follow my peers, and jump in.

At 03:29 PM 9/11/95 -0700, you wrote:
>On Mon, 11 Sep 1995, Aram W. Mirzadeh wrote:
>> At 03:41 PM 9/11/95 MDT, you wrote:
>> >
>> >> Who's the patch coordinator for 0.8.13?
>> >
>> >it hasn't been discussed. You can volunteer if you want :-)
>>
>> Only if you tell me what I should be doing? >:->
>
>A patch coordinator needs to
>
>1) maintain the patch repository for that particular build
>
> a) make sure things are organized intelligently, with comments in
> the patches as to why the patch is needed
>
> b) monitor the mailing list and newsgroups for patches.
>
>2) do a sanity check on the patches submitted first
>
> a) make sure they patch cleanly - if not, create a clean patch using
> diff -C3 which does not depend upon other patches
>
> b) make sure patch makes sense in the context of the architecture and
> the principles of cross-platform and least-astonishment
>
> c) do an initial test on the patch to make sure it does what it claims
> to do
>
> if any of these fail, ask the patch submitter to submit again.
>
>3) when a sufficient number of patches have been submitted, close the
> patch submission for this round and leave two or so days for
> comments/testing of the various patches. Then, create a ballot and
> send to the list - hold the vote open for a day or two, and then tally.
> finally, present results to the list and build the next release.
>
>
>I may be missing something... Rob(s)? Roy?
>
> Brian
>
>
>--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
>brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

Brian said,

> A patch coordinator needs to
>
> 1) maintain the patch repository for that particular build
>
> a) make sure things are organized intelligently, with comments in
> the patches as to why the patch is needed
>
> b) monitor the mailing list and newsgroups for patches.
>
> 2) do a sanity check on the patches submitted first
>
> a) make sure they patch cleanly - if not, create a clean patch using
> diff -C3 which does not depend upon other patches
>
> b) make sure patch makes sense in the context of the architecture and
> the principles of cross-platform and least-astonishment
>
> c) do an initial test on the patch to make sure it does what it claims
> to do
>
> if any of these fail, ask the patch submitter to submit again.
>
> 3) when a sufficient number of patches have been submitted, close the
> patch submission for this round and leave two or so days for
> comments/testing of the various patches. Then, create a ballot and
> send to the list - hold the vote open for a day or two, and then tally.
> finally, present results to the list and build the next release.
>
>
> I may be missing something... Rob(s)? Roy?

missing something ? far from it, I think you've overstated the
job.

Check newsgroups ? :-)

If you're offering to be the vote collector, you collect votes.

If you're offering to be the release builder, you apply the patches
that the vote collector announces as passing the vote, then you
update the changelog and version number and upload the result.
If any patches fail to apply cleanly, you can reject them or ask for
help to apply them.

I'm not aware of anything more that is required of the 2 jobs.
Maybe thick skin :-)

rob

>
>What's the saying... fools jump in where wise men don't....
>
> Well, I guess I'll have to follow my peers, and jump in.

Please do (jump in, that is) -- I am busy this week with a conference
and a grant and three specs, and I don't want to slow things down.

......Roy

> Well, someone in the chain of events should be the sanity checker - just
> because someone can write a patch, and that patch works in the context of
> the bug it was meant to fix, does not mean that it's the cleanest way to
> do things

if it isn't, and there's a good reason to do it cleanly, then a
replacement patch is appropriate.

> , or that it doesn't conflict with other patches or even go
> against the code philosophy.

This is what the peer-review voting process takes care of. Dumping the
responsibility on one person isn't the best way to operate.

> This could be done at patch-collection time

Oh, is that what I just said ?

> - it is crucial after all to know if two patches on the same ballot
> conflict.

This should become obvious if people apply patches in order. Even if
you don't intend testing a patch, if it looks reasonable, patch it into
your current version (so we identify compilation problems *before* release)

> It definitely has to be done by release build time - and if
> approved patches do conflict, they need to be resolved, and I
> don't worry about autocracy at that point. If that means the patches
> need to be slightly altered, that's fine with me.

I'm sure we can all "slightly alter" a bit of code and cause a disaster :-)
*if* the release builder is spared the job of "slightly altering", all the
better.

Remember, the release builder can reject outright a patch that fails to
apply (presumably in numeric order). Not an ideal solution, but it should
encourage patch compatibility.


rob