Re: Voting meta-discussion (was Re: cvs commit: apache/src

[Rob Hartill <ro...@imdb.com>]

Paul Richards wrote:

>Paul Sutton <pa...@ukweb.com> writes:
>
>>   3.  It is wrong to develop code on the principle of first
>>       putting it into the current code then taking it out if it fails.
>>       New code and features should be discussed first and tested before
>>       being applied after an approval vote
>
>I disagree with this. You're advocating that cvs be used to combine
>code after it has been tested, this is going back to the patch-n-vote
>days where we'd have to apply patches on our own boxes to test them
>out before they go into cvs. This is very difficult to do, it was then
>and it would be more so now, with more frequent contributions.

This is not my idea of how it'd work or Paul Sutton's I'd suspect.

All that's being asked is that people agree to stuff being added to the
cvs tree before it is committed.

For 1.2b1 and "satisfy" I asked that only something that had been tried
and tested be added. As the release date nears, it's more important to
keep commits to a minimum and only for stuff that doesn't need to be
pulled out within an hour of being committed.

For 2.0 and beyond, I'd like to see the voting used to okay ideas before
they're committed. There'll be more time to test after comitting than we
have now for 1.2b1. Voting before 1.2b1 commits focuses everyone on what's
going in at the last minute. Perhaps when there's more time, we can say
that voting +1 on a commit means you agree with the idea and are
willing (or already have) tested it.

>None of the strong advocates of voting have yet shown why the current
>development practices are failing? Is Apache any less stable?

The beta users will tell us that. I'd hope it isn't less stable.

>My view
>is that a hell of a lot more progress has been made since we started
>using cvs than when we had to patch-n-vote.

That's clear and nobody will deny that, but at the same time we've also
lost a valuable tool that introduced order, more testing and wider
participation.

>>   4.  A feature freeze does not imply a free-for-all to commit their
>>       favourite patches just prior to the freeze
>
>This was hardly a free for all. The desire for a satisfy patch has
>been there all along and all I did was take item no 1 off Rob's todo
>list and actually do it.

The motivation was good, but the execution left a lot to be desired. Had
you offered the patch last night, you would not have gained enough support
to get it committed. It would have saved Roy from undoing it and everyone
else jumping on your back.

Re: Voting meta-discussion (was Re: cvs commit: apache/src

[Paul Richards <p....@elsevier.co.uk>]

Rob Hartill <ro...@imdb.com> writes:

> For 2.0 and beyond, I'd like to see the voting used to okay ideas before
> they're committed. There'll be more time to test after comitting than we
> have now for 1.2b1. Voting before 1.2b1 commits focuses everyone on what's
> going in at the last minute. Perhaps when there's more time, we can say
> that voting +1 on a commit means you agree with the idea and are
> willing (or already have) tested it.

I don't really disagree with any of that. I always advocated group
discussion before making significant changes. Of course, what's
significant is somewhat open to opinion and we'll have to think about
that at a later date.

> >This was hardly a free for all. The desire for a satisfy patch has
> >been there all along and all I did was take item no 1 off Rob's todo
> >list and actually do it.
> 
> The motivation was good, but the execution left a lot to be desired. Had
> you offered the patch last night, you would not have gained enough support
> to get it committed. It would have saved Roy from undoing it and everyone
> else jumping on your back.

Yeah, Ok. The satisfy patch was rushed, I admitted that in my commit
message but I really didn't want to see the feature freeze go by
without it getting in since I know there are sites that won't use
Apache simply because this feature is missing (we're going to need it
here for a start).

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155