[Release] The role of Bob, Installer & Co.

Keith Hodges keith_hodges at yahoo.co.uk
Mon Jul 6 02:08:33 UTC 2009


Andreas Raab wrote:
> Keith Hodges wrote:
>> You really dont get it do you...
>
> I think that's pretty obvious by now, isn't it. What I'm trying to do
> is to enable developers to work together. I can't possibly imagine why
> anyone would be so violently against that, so clearly I'm not getting
> the point.
> I think our main practical difference is that you "abso-bloody-lutely"
> want  people to go through Mantis. Which is okay, you can use Mantis
> for anything you'd like. But I myself, and other developers who
> understand the MC workflow, would rather collaborate that way.
> If Bob can't support workflows that use collaboration through shared
> MC repositories then it's not suited for the task of image building.
> And if it does support these workflows, then I don't understand why
> we're even having this discussion.
>
> Cheers,
>
>   - Andreas 
You can do the workflows any where you like.  Specify a project, make a
repo for that project and get on with it. For example a project to
replace changes/sources with something better/cleaner. But you dont want
the person doing that project to be working in the same repo as someone
else whose project is to integrate rio. These are separate initiatives,
done external to the release effort, and integrated as external packages
+ integration patches.

You have to decide what it is you are going to do, and specify a project
to do it. Specify the deliverables the documentation and the outputs in
such a way as they can be picked up by the automatic builder.

You are not capturing the knowledge of what you are doing to achieve
what end. Simply because you aren't specifying any goals, nor any
deliverables. Sure you can work in your repositories, but please ensure
that every innovation you make is packaged, documented, and available
individually in a manner that can be peer reviewed, automatically tested
in all squeak forks and derived images.

The purpose of 3.11 is to develop a tool chain that promotes interchange
and commonality between forks.

i.e. someone using a 3.8 etoys image can ask the question... "I see
someone over there working on Rio integration, what would happen if I
applied their rio integration task to my 3.8 based etoys image."

As soon as you have two innovations contained in the one repository you
have a difficulty testing just one of them or offering that innovation
to someone else in another image.

am I making any sense?

Keith








More information about the Release mailing list