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@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@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.
- 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@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
On Fri, Oct 17, 2003 at 01:47:31PM +0300, Daniel Vainsencher wrote:
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.
I don't think that we should allow anyone to do everything.
It would be nice to relax the harvesting-requirements on "trusted" people. e.g. if Ned or Anreas do some Morphic changes, there is really no way we can really review them. (I can't).
Marcus
Marcus Denker marcus@ira.uka.de wrote:
On Fri, Oct 17, 2003 at 01:47:31PM +0300, Daniel Vainsencher wrote:
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.
I don't think that we should allow anyone to do everything.
It would be nice to relax the harvesting-requirements on "trusted" people. e.g. if Ned or Anreas do some Morphic changes, there is really no way we can really review them. (I can't).
I think the best answer is to focus on "staking out" packages. If Morphic was Stewarded by Ned (or Andreas) this would IMHO mean that Ned has full commit power to Morphic (no reviewing) and if people submit FIXes to Morphic then typically Ned would harvest them, and possibly also do much of the reviewing himself.
So in short - let's stake out the image. And then I think the problem will gradually "go away".
regards, Göran
squeakfoundation@lists.squeakfoundation.org
-
Daniel Vainsencher -
goran.krampe＠bluefish.se -
Marcus Denker