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
|