Need to do something

stéphane ducasse ducasse at iam.unibe.ch
Sun Oct 16 09:06:04 UTC 2005


Hi daniel,

Thanks because you summarize well what we live and what we try to  
achieve.
And I would like to have more time to focus on your kernel fixes :)

Stef

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




More information about the Squeak-dev mailing list