Need to do something

Daniel Vainsencher daniel.vainsencher at gmail.com
Fri Oct 14 04:18:22 UTC 2005


Hi Andreas.

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

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

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?

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?

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.

What's the problem?

Daniel

Andreas Raab wrote:
> stéphane ducasse wrote:
> 
>> Sure this is what we are doing with Morphic enh (we trust eddie's  
>> speedup, we trust romain service architecture, we trust  
>> PLMrefactoring and accept that they may break a bit)
>> we just pay attention that the system at the end still work.
> 
> 
> The problem with this "trust model" is that you are still standing 
> squarely in the way of those people making independent progress. And 
> like it or not, you aren't the expert in this area, and if you aren't 
> who are you to say whether to extend the trust to that person? That's 
> exactly what gets us into the mess - there is a "well meant" idea which 
> is then poorly executed because nobody with actual firsthand knowledge 
> is involved in the process.
> 
> Secondly, (because I know this would be your next point ;-) you need to 
> give maintainers some time to react. I know that you are going to say 
> now, namely: "but we waited two years and nobody did anything!!!" But 
> that's not true because we *don't* have maintainers. We only have 
> maintainers for those things that actually packagized, and here it is 
> the rare exception (if it ever happened) that these things get 
> completely forgotten. And yes, this can happen, and yes, in such a 
> situation one needs to react. But it is still an exceptional situation 
> and you are now effectively operating under "exceptional rules" all the 
> time ;-)
> 
>>> That's exactly the point, isn't it? If you want to do that, e.g.,  
>>> personally ensure that everything gets integrated, then your only  
>>> option is to take ownership of all the code. But then please don't  
>>> complain, it's been your choice ;-) Alternatively, your only option  
>>> is to believe in an economy that scales and the only way to get  
>>> there is to stand back and delegate. Your task should then be to  
>>> *find* people who do the work and who feel responsible, not *do*  the 
>>> work (I think Goran understands that).
>>
>>
>>
>> This is what we have been trying to do, but who want/can want to that?
> 
> 
> You did? I fail to see any traces of that process :-( What I have seen 
> is requests for people to "do the slave labour", but I have yet to see 
> any attempt to delegate actual responsibility. Even with Ken and Goran's 
>  latest attempt it stays again in the "inner circle" of people who do 
> have commit rights to "basic Squeak" to begin with.
> 
>>> The point is that the system is too big for you on a personal level  
>>> and that it's too big for anyone and that even looking at  subsystems 
>>> like Morphic it's daunting task. You need to get this  smaller to get 
>>> people involved but to get people involved you have  to trust them.
>>
>>
>> Exact this is what we are doing. So may be these people should have  
>> access to the "update stream"
> 
> 
> I don't actually think so. These people should have access to their 
> packages, that's what they really need.
> 
>> But you saw what happened when diego started to work on Morphic,  
>> impara got afraid and said that they would do a fast release (btw  
>> this will become the ultimate joke I have against the Beeper  beep :)).
> 
> 
> You make this sound as if we deliberately delayed the release to make 
> sure that Diego's changes don't get in. But if I remember correctly, 
> then the real killer argument in 3.9a was that when you asked for help 
> to integrate these changes, you didn't get any feedback. That has very 
> little to do with Impara.
> 
>> OK excellent! We have no problem to see you working on integrated  
>> your stuff on 3.9a but your attitude certainly lets marcus think that  
>> you
>> were not interested. So this is a good news. Are you commited to  
>> maintain, integrate your package in 3.9a?
> 
> 
> I think I can speak for everyone involved in the ToolBuilder work (which 
> isn't just me) that we are committed to maintain and enhance ToolBuilder 
> for the foreseeable time (btw, we still need help with MVC support!). 
> And we will certainly work with any (existing or potential) customer to 
> help you get started and work with ToolBuilder.
> 
> However, we won't write your code. Don't expect that we suddenly run 
> around in the whole system and rewrite every class to use ToolBuilder. 
> Not our code, remember? As far as I am concerned you are free to 
> completely ignore ToolBuilder.
> 
>> Excellent news. So we added it on the list of the stuff not to let  
>> die because nobody pay attention.
>>
>> Marcus will be more than happy I can tell you. So let us know when  
>> you want to start. Doug has the account info
>> and as soon as marcus arrive in Chile and we get script 6 load you  
>> can integrate your changes.
>>
>> Again WHY DID NOT YOU SEND US AN EMAIL TO SAY THAT?
> 
> 
> If you have any issues with ToolBuilder integration you should talk to 
> Brian Brown and not yell at me. Brian is the appointed team leader with 
> the specific task to make sure this stuff gets integrated. Beyound that 
> you may want to talk to the appointed Coordinator (which would be Cees) 
> if you feel that Brian isn't helpful. I don't see any reason why you 
> yell at me - I have never promised to work on integration, I have only 
> promised to work on the framework. Which is precisely what I have done, 
> and will do in the future.
> 
> Besides that, have you ever asked at the dedicated Toolbuilder mailing 
> list? Has Marcus ever mentioned that he's got problems to anyone? I 
> don't see any messages towards that end. Why do you yell at me?
> 
> Besides that, I don't see any time pressure for ToolBuilder integration. 
> As soon as it is available people can decide whether they want to use it 
> or not. I don't see any reason to force anybody to do that and neither 
> do I see any reason to force integration.
> 
>> Come on andreas. I found that quite low level remark. You never payed  
>> any attention to  the work done by the Morphic Cleaning Project else
>> with a bit of steering they would have made great stuff. The only way  
>> to get people commited to do something is to pay attention to what  
>> they are doing.
> 
> 
> There are two reasons why I haven't paid any attention: First is that in 
> my eyes mechanical rewriting is completely useless. If you want to 
> rewrite code to clean it up, fine, but that's got nothing to do with 
> mechanically replacing all references to "foo at: 1" with "foo first". 
> That kind of cleanup is simply useless and I won't spend one second to 
> look at it. If you want to clean up something then take a functional 
> entity (say PLM) and do that. That's the kind of refactoring I can 
> approve of but most of what was done wasn't that kind.
> 
> Second, I *don't* claim any ownership about Morphic. I'm done with it, 
> over, out. If you want to refactor, refactor. I'm fine with that. And 
> since my time is limited too, I don't look at these refactorings.
> 
>>> Put differently: It is *my* choice whether I want "my  shitty code" 
>>> to be rewritten, not yours.
>>
>>
>> Except if the code is getting in the way of everybody and if lot of  
>> people propose fixes and nobody pay attention to it and there is no  
>> maintainer.
>> I think that you are playing with concepts here but not morphic reality.
> 
> 
> Again, I wasn't talking about Morphic specifically, I was talking about 
> code ownership in general. I actually agree that if there's a problem in 
> the way of everyone and if there's no maintainer then something needs to 
> be done, no matter what.
> 
> Cheers,
>   - Andreas
> 



More information about the Squeak-dev mailing list