[Release] 3.11 liaison change

[Igor Stasenko]

Guys, maybe you should turn a discussion in more rational plane?

What i am thinking about, and what was discussed during board meeting is
to find a most simple & most comprehensive development model for
distributed development,
by considering what tools we have and what can be used for what
purposes, and what fits best for
such aims.

So, my concern is to see a clear & simple instructions to anyone who
would want to contribute
in a simple and well understood steps, as easy as:
1. do this
2. do that
3. then do this.

Take in account, that we should not assume that people having any
knowledge about either Installer or MC or whatsoever.
Or even if having, just very basic one.
Understand, the more technical & usability prerequisites we put in
these steps, the more harder it would be for decent people to
understand the process and use it effectively to contribute.

We could have a lot of cool stuff, but unless it turns own face to
developers, no-one would want to use it.
So Keith & Andreas, you can be an experts in using different tools,
and argue to death what is better. But this is not the point, i think.
Think as an outsider, who just came here, and think, how many he
should learn & keep in mind, in order to become an effective
contributor to Squeak. And thus, our aims, how we could minimise his
efforts.


2009/7/2 Keith Hodges <keith_hodges at yahoo.co.uk>:
>
>>
>> A typical use case is that a developer starts some bit of work this
>> week and then only gets around to work on it again two weeks later.
>> What the developer needs to be able to do is to find out what changed,
>> find out whether it affects any part that he was working on, and merge
>> eventual differences. Monticello can handle these tasks trivially, I
>> have no idea how Mantis or Bob would help me here.
> If you specify a build that you are working on then there is an MC
> repository for that build, e.g. 3.11. As you modify the items that
> contribute to that build the MC repository gets updated each time the
> build is run, if a pacakge has changed.
>
> I admit that this is the most experimental and unproven part of the idea.
>
> An example...
>
> 1. I run the build... and it generates the packages e.g.
> 311/Network-bob.20.mcz
>
> 2. A while later I have a couple more fixes added to Mantis, Bob tracks
> mantis and so can work out what they are.
>
> 3. I run the build again and it generates the package
> 3.11/Network-bob.21.mcz and adds the comment indicating that two fixes
> were added since the last time.
>
> like I say experimental (and somewhat slow)
>
> Keith
> _______________________________________________
> Release mailing list
> Release at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/release
>



-- 
Best regards,
Igor Stasenko AKA sig.