Hi Daniel,

> 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?

You care quickly about this when you download an image and things break 
because the "bundler" decides to change some code. Or, if you have been 
using that image for a while, and switch to another and load the package 
from the primary repository and it breaks for the same reason. The 
trouble is that because the bundler has typically so much further reach, 
that the package owner is basically forced to accept whatever the 
bundler does to the package. Which means that the bundler needs to be 
aware of this issue and the bundler really needs to work *with* the 
maintainers of the package.

>> 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.

Ah, now there is a concept: "Improvement". My whole bitching about what 
has done to the chess game comes down to the point that in my view, not 
a single one of these changes were improvements. Now, the question is: 
Can a maintainer (before you go into this, I am NOT claiming to be a 
maintainer for the chess game, this is a theoretical question) say that 
he doesn't want some global replace of "foo at: 1" with "foo first" and 
will still be considered responsible, or do you have to take whatever is 
thrown at you? In reality, the ability to decide what consitutes an 
improvement and what not is probably the strongest expression of 
ownership in that code.

>> 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

Don't be ridiculous. Nobody will use your version of the Kernel package. 
You must be sniffing glue if you think anybody will. The fact of the 
matter is that Marcus and Stef, being the ones who have commit rights to 
what is likely going to be 3.9 means that indeed they are the masters of 
the universe.

>> 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. 

I didn't. My point about the chess game was entirely different. It is 
you and others who make the greek tragedy to paint me in a silly light. 
The examples here would be changes being done to packages that *are* 
actively maintained, including Monticello or ToolBuilder.

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

Unfortunately, in this example John Doe is the bundler who decides to 
add a patch which got previously rejected by the maintainer. And that 
bothers the maintainer because the patch already got rejected.

>> 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.

I just wish you'd read my messages. I used MC as one example for how 
things ought to be:

	"The alternative: Hand out responsibilities for packages. Look at 
VMMaker, SqueakMap, Seaside, Monticello, ToolBuilder, you name it. These 
all work well and Stefane and Marcus don't have to spend any time 
whatsoever on them. So if you find a few people with vested interest in 
an area you'll see that suddenly you're cutting out a whole area of work 
for the likes of Stefane and Marcus (who in turn can concentrate on 
those packages that they have a vested interest in)."

But "inside the image, outside these packages" things don't work that 
way, what you describe does not exist. Please go back and read that 
first message of mine, it might explain a few things.

>> 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).

Did I say "we have no maintainers"? Sure anyone is a fool who ignores a 
maintainer (but it has happened nevertheless) but the starting point of 
this discussion is that we need to scale and for scaling we need (more) 
maintainers. It's amazing how you repeatedly manage to ignore the 
fundamental points I'm trying to make ;-)

Cheers,
   - Andreas