Hi daniel

Too bad that we are using email so I will try to do my best to share  
my feeling.

> stéphane ducasse wrote:
>
>> I thought that it could be a work for the foundation but we do  
>> not  want to open
>> a war or destroy the community by proposing that someone get payed  
>> to  help us
>> to fix the process/problem. Once I asked Ned if he could help and   
>> been payed
>> but again we do not know how to proceed.
>>
> I think that is not a good solution. One commercial model that  
> works well is when a commercial entity fixes things for itself. Our  
> example is impara (who created the model we started from for MC  
> update stream, because it was useful to them), another one is  
> Ubuntu. The community directly paying people to do stuff seems like  
> poison to me.

So what you say basically is do nothing and pray that a small company  
can find the resources to fix something.
I know that netstyle spent hours trying to fix omnibase on mac and  
I'm not sure that they got it.

>> So if you have any suggestion think twice before but now there is   
>> still time to say
>> something and make sure that the process support itself.
>>
> First I want to say that I think we're doing really well in eating  
> up this learning curve, and the need for a learning curve is  
> natural. We will still have to invest in more MC improvements, and  
> it will take time, but if we simply postpone merging contributions  
> that are problematic under the current model (things requiring a  
> bootstrap), I think we'll do pretty well. If you're having problems  
> with using MC for the regular contributions, be specific.

The problem we have are not about bootstrap.
In the changes that are a problem there is nothing related to that.  
Just some methods move in the different packages than kernel.
>

> And the problematic ones
> a: we always somewhat problematic, though we were more used to  
> their workaround
> b: we will get to those, if not this version, the next.
> c: when we get to them, will still be reasonably easy to merge,  
> because MC does that.

not with the current setup and this is not about bootstrap. The  
problem we have is about dead stupid
fixes. for example introducing isRectangle one Object and changing  
insetBy to call isRectangle instead of isKindOf:


Then the problem is much more general.
What will happen if marcus really only works on his PhD and me on my  
research?
Of course we take a risk but we cannot continue to have a process  
only based on free time of people.


>> But right  now I do not see how
>> we can continue like that. Seriously, I have fun to clean,  
>> harvest  fixes but
>> not like that and we need help.
>>
>
> So I think we need:
> 1. More people with deep MC knowledge helping out. Any of you that  
> are willing and still not there, please join the  
> packages at discuss.squeakfoundation.org list. If you don't have it  
> yet, but are using MC already, you should consider making the  
> plunge. MC is already a very useful tool to many of us, but the  
> fact is that it could improve much faster with a bigger active  
> community of developers. There is now a squeaksource.com project  
> for it that people can be added to, if you have code contribution,  
> join up.
> 2. More people merging stuff from the inbox repository in  
> source.sqf.org and from mantis, living with it, patching it, and  
> releasing new versions to inbox, therefore leaving only merging  
> into 3.9a to the harvesters.

ideally this can work but
only which costs us hours....

Then again of course there is a rick but we should arrive to a  
working system where we get some contributions
by people payed for doing them because nobody else want/can/has time  
to do it.

Propose a model.


>
> Daniel
>
>
>