[Squeakfoundation]The Harvesting process and the BFAV

[Daniel Vainsencher]

That won't work, because we can only look at a tiny portion of the
posts. Effectively, this means that everyone has commit access. No open
project that I know of works like this.

Daniel

ducasse <ducasse at iam.unibe.ch> wrote:
> Daniel
> if we open more the process, I think that harvester/guides/ should have 
> a veto vote.
> 
> Stef
> 
> On Vendredi, oct 17, 2003, at 10:39 Europe/Zurich, Daniel Vainsencher 
> wrote:
> 
> > Marcus Denker <marcus at ira.uka.de> wrote:
> >> bugs are good, because bugs generate tests.
> > I'm sorry, but this seems to be a little disconnected from reality 
> > right
> > now. I agree they should, but they don't. And expecting everyone to
> > start churning out lots of SUnit tests seems a bit optimistic. Though
> > any ideas on how to achieve this would be very welcome - I do agree 
> > that
> > the easiest fixes to approve are the ones that turn a test green, so
> > that would be a very sound technical basis to use, if we find the way 
> > to
> > cultivate it.
> >
> >> 2) It could be not-that-perfectly documented. To me, the alternative
> >>    seems to be: Not adding, or adding a slightly-not-perfect thing.
> >>    What is worse? I would *really* prefer to e.g. have some feature
> >>    now instead of waiting indefinitly. But that may only be me.
> >> Make it green. Then refactor.
> > Again, this seems reasonable if you can make some assumptions, such as
> > that people will actually refactor. But this seems again, optimistic. 
> > If
> > people aren't joyfully reviewing one anothers patches, why do you 
> > assume
> > they'll cheerfully refactor one anothers "ugly code that got in the
> > image"?
> >
> > We should also consider the case:
> > 3) The patch could be completely inappropriate, like (apparently) 
> > Martin
> > Wirblats patch related to Pool declarations.
> > Some patches, if accepted, simply reduce a solutions coherency, and 
> > make
> > it harder to understand and improve in the future.
> >
> > Daniel
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> >
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation