Andreas Raab wrote:
> 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.
Oh, I agree with that. Just don't happen to agree there is any problem 
with what Stef and Marcus are doing. Only problem is they feel they have 
to make some quota, and other people apparently feel they have to get 
permission before they can help. (Guys, you have permission. Really)

 > And if we want to
 > scale it we need maintainers,
Maintainers, in my book, are people that produce lines of MC versions of 
their packages in some public repository, such that these are what 
everyone starts from, because its clear that those versions are the 
best. Some packages are maintained, some aren't.

> 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.
I don't see how it is possible to destroy the sense of ownership that 
I'm talking about. Either you're the person who's versions people want, 
or you're not. Maybe you're sharing. Only way someone can change that is 
being more active than you, and that is rarely a bad thing, isn't it? 
(if you think the chess example is such a case, I talk about it later)

> 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.
Well, we happen to have a license that doesn't give you power to have 
exclusive power. So any programmer can make decisions about code, 
design, style and implementation. And any bundler (like Marcus or you 
guys for iSqueak) can decide which version of stuff to take, and what 
adjustments to make to that. Of course bundlers can't afford to make big 
changes to many specific packages, therefore it is impossible for them 
to really compete with any maintainers.

Therefore, absolutely nothing about the current process stops 
maintainers from exerting sufficient control of their packages - all 
they need to do is be active enough, and then of course bundlers will 
take their versions.

And of course bundlers have the right and need to make adjustments to 
fit version to their release. That their job? so what if a maintainer 
can't put a version into the release repository, who cares? that's not 
the official repository for the package, it just happens to be what that 
bundler is releasing, who cares about that?

> 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.
Yes, I'm just saying that all that that takes is the maintainers need to 
be active. If maintainers feel that they are blocked by someone else 
integrating something they dont like, then they are simply 
misunderstanding MC. What was integrated, can be easily unintegrated 
(*), and that's the bundlers problem. All the maintainer has to do is 
produce the version that is best, by merging in only what is an 
improvement.

If he's nice, then he can throw people a clue when they're thrashing, to 
reduce the general noise level. If he does, he might even find he's 
getting listened to, and we'll earn more clueful contributors. Nobody 
can stop you from doing this, and nobody can force you to do it.

If enough people just do it, bundlers will have an easy life.

> This is so frustrating. 
Don't have a cow, man :-)

> You are actually making my point
Not a problem, since we mostly agree

> without even 
> recognizing it:
That's your opinion

> 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! 
Really? wow, I had no idea! and there I was, thinking that I'd posted 
new versions of the kernel package to a public repository, and anyone 
can decide to take that instead of the official repository. I must be 
completely mistaken, because I didn't get any permission from anyone, so 
they must not really be there in that inbox for anyone to use. Hey guys, 
why didn't you tell me Marcus and Stef are masters of the universe, 
that's so unfair :-D

> 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.
Look, I agree it would be useful if Marcus had told people "have you 
shown the chess stuff to Andreas?". Of course this would probably have 
happened if you'd asked for it to happen. But it certainly isn't 
necessary. You're making a greek tragedy of what should be a minuscule 
inefficiency. Next time you put out a great new version of the package 
you're maintaining, and it completely ignores the changes john doe made, 
its the bundlers job to solve it. If there are no conflicts, he can play 
stupid and just merge. If there are conflicts, he might have to think, 
and at that point probably have you and mr. doe bang heads and put out 
something he can use. Or he might decide he's just undoing the other 
guys stuff and merging in yours and be done with it.

Please explain to me how anything about this scenario bothers the 
genuine, "putting out a version a month" maintainer.

> The problem is that all of what you write is pure theory that doesn't 
> exist today. 
Sure it exists. MC is an example. Avi maintains it. Bert occasionally 
contributes, at some periods, more frequently than Avi. Then Marcus 
might merge Berts stuff "over Avi's head". If Avi really dislikes a 
change, he can merge and undo, or ignore and forge on, and Marcus can do 
what he wants. No fuss, no muss. Wow, we even have multiple maintainers, 
and it works, even with that meddlesome "official" repository. No problem.

> 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. 
Ownership seems like an empty concept to me in our context. If you're 
really maintaining the package, anyone is a fool to ignore you, and 
we're not seeing that (welcome to show me an example). If you're not 
really maintaining the package, having your name up somewhere and having 
to go through you is just drag when someone wants to do the work (see 
case of xfree86).

You might think you're entitled to veto someone elses refactorings by 
ignoring them, I happen to disagree. You want a say, you'll have to say 
it, or at least release versions. Other wise we must assume you either 
don't care or agree.

> Sigh. I'm tired now.
Always fun to cross keyboards... :-D

(*) to undo a version - Suppose B,C descend from A, I bundler had A, 
merged B, and now decided C is good, and B is bad. So I load A, adopt B, 
merge C, and save as D. Publish D as the next official version. IIUC, 
when people merge it in, it undoes the B changes, and installs those of 
C, with perfectly good ancestry records, so merges will continue to work 
well in the future.

Daniel