Re: The Harvesting process and the BFAV
Daniel Vainsencher <[email protected]> Fri, 17 Oct 2003 13:47:31 +0300
| Newsgroups | gmane.comp.lang.smalltalk.squeak.foundation |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > [email protected] > http://lists.squeakfoundation.org/listinfo/squeakfoundation