Need to do something

Andreas Raab andreas.raab at gmx.de
Fri Oct 14 05:36:35 UTC 2005


Daniel Vainsencher wrote:
> I've been reading this for a while, and not really understanding what 
> this is all about. I just want to understand what exactly is digging you..

In the simplest terms possible: What's digging me is that if we want to 
solve the harvesting problem we need to scale it. And if we want to 
scale it we need maintainers, and maintainers need to be able to take 
ownership of their respective code. And that the current harvesting 
process actively destroys that sense of ownership.

> Are you saying we need code ownership in Squeak land? most open source 
> projects have a hierarchy instead, and people contribute stuff even if 
> they don't have commit access to the main repository. Linux is one 
> example, and pretty much every project with a non-public-write cvs is an 
> example also (for the non-committing contributers).

I am not saying anything against contributing code. Heck, I am not even 
saying anything against Marcus and Stefane just continuing what they do! 
;-) (just remember that this whole discussion started because the two of 
them are burning out rapidly)

> Suppose we need code ownership. What should it mean? that I can't edit 
> code you've written? can edit, but can't publish? can publish, but not 
> on a formal repository? on a formal repository, but not in the 
> squeak-dev update stream?

What code ownership means is simply that the person or group is 
responsible for the code. That includes the power to make decisions 
about that code, its design and its implementation, that includes the 
responsibility to fix (or reject) bugs, that includes the ability to 
decide about style issues.

> We have a distributed system version management system. You can maintain 
> your version of the code in your own repository, and never merge that 
> junk that people put into the update stream, and we can still merge all 
> of your stuff when you contribute. So why exactly do you care what other 
> patches other people bring in? how does this damage your "ownership", as 
> far as it goes in a distributed world?

But you are missing the point. Of course I can ignore other people's 
patches. That's just what I've been doing for the last couple years. But 
the point of this discussion is not how to *ignore* other people's 
patches but how to *care* for them, e.g., deal with harvesting in a 
better way.

> Can you explain what exactly we're supposed to gain from forbidding some 
> changes? After all, an active maintainer that does 90% of the work 
> anyway, can simply decide whether to merge every specific change, and 
> ignore what they don't like, and the release people will probably use 
> his version to the extent he deals with the problems they have. This way 
> they make public the fixes they think are appropriate, and are able to 
> act on their release responsibility. If they make a bad fix, the 
> maintainer tells them "I'm not integrating that, its wrong", and the egg 
> is on their face.

This is so frustrating. You are actually making my point without even 
recognizing it: Yes, if we *HAD* a maintainer, then this maintainer 
*COULD* make the decision if he were allowed to do that. But for the 
stuff that's in the image we *don't* have any maintainers, and except 
from Marcus and Stefane *nobody* can actually do anything! And if indeed 
you *first* send the patch to the maintainer then all is well but that's 
*not* what has happened in the harvesting process; instead changes got 
committed *right over the head* of the people responsible for the code.

> What's the problem?

The problem is that all of what you write is pure theory that doesn't 
exist today. We have no maintainers, but even if we had, they wouldn't 
have access to their own code, and where we indeed have maintainers with 
access to their code their ownership of that code gets simply ignored. 
That is the problem.

Sigh. I'm tired now.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list