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.


> regards
> Keith
> ===
> "Branching is the new Forking"
>

-- 
Best regards,
Igor Stasenko AKA sig.