2010/3/10 Igor Stasenko <siguctua at gmail.com>:
> On 10 March 2010 13:14, keith <keith_hodges at yahoo.co.uk> wrote:
>> Josh,
>> so now we have a feature in trunk called "future". I don't know if I want it
>> in my version of Cuis or not. I am not even sure what this feature consists
>> of, in that I cant see what its boundaries are. However if I do I will want
>> it to be a load-able extra, because some package I want to load may need it.
>> As a simpler example, take Mutex. Cuis doesnt have it, Magma uses it. It is
>> a relatively isolated piece of functionality, it doesn't need to be managed
>> inside the image, it can easily be a load-able feature.
>> Can you answer if you will, how you have packaged up this "future"
>> innovation so that it would be useful to me?
>> If your answer is that you committed it to trunk, and I am expected to
>> harvest it from trunk, I think you can forget it.
>> If your answer is that it is in Monticello inbox, then how can I get the
>> most current version, surely the inbox version will have been tweaked in the
>> image. And cuis being a kernel image doesn't have monticello.
>> Previously you said: "if we can achieve some of your goals without
>> sacrificing the benefits of the new process"
>> Hopefully this will help you to see that trunk is not really process
>> offering any benefits at all. As far as I can see it is simply promoting
>> sloppy work practices, where everything new you can think of gets thrown
>> into the soup of a monolithic image, and now everyone can join in throwing
>> stuff at the future (if you excuse the pun) image.
>> When I use the "grow" process I am now running and developing the same code,
>> (even kernel level code that would break trunk) in all forks simultaneously.
>> Every innovation or which is managed as a loadable extra, becomes a
>> potential point of commonality between existing forks. The fact that trunk
>> is not managing its features outside of the image, is a disaster. Heck you
>> haven't even split System up (yet).
>
> Keith, i am agree with you that trunk is hard thing to harvest
> comitted things, like futures.
> Yes, the trunk development model easing the way how one could join the
> project and commit own ideas/changes/fixes,
> but concerning cherry-picking features for different images, we are
> not moved forward comparing to old development model(s),
> which is used by Squeak before.
> We all need a good and easy solution for that. I'd say, an easy is
> more important than good, because if we make a harvesting be a hard,
> multiple steps process, which requires a deep knowledge about many
> tools, then it would be not much better than current situation, where
> people, to cherry-pick thing, should manually grok through image and
> extract individual classes/methods.
>

I'm in line with Igor.

Nicolas

>
>> regards
>> Keith
>> ===
>> "Branching is the new Forking"
>>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>