2009/6/29 Andreas Raab <andreas.raab at gmx.de>:
> 1) Agree on MC as the core development tool/model. This is painful and
> consequently the decision has to be made consciously. However, from my
> perspective there is really no suitable alternative [1].

Monticello is an acceptable choice to me. MC sounds like something we
can use right here, right now. And as long as we can easily
contribute, we can bring improvements to the development process and
tools in our way.

> 2) Decide on the canonical repositories. I would suggest that
> http://source.squeakfoundation.org/trunk is a fine starting point [2].

Yes, I support this idea.

> 3) Decide on who gets commit rights. I would suggest that the board decides
> that (equally for eventual access removals). The "masters" list from
> Squeak-people could act as a starting point.

Yes, I support on the board decides who is approved and revoked.
Could you point out the masters list mentioned here?

> 4) Implement an update model for MC. I would suggest to adopt a similar
> model to what we've been using for Tweak in the past: Use MC config maps to
> mark points in the update process where order is important and otherwise
> update the packages in a well-defined order[3].

What would be the incidence of such an update model, with well-defined
order, on the eventual maintenance a component manager (someone who
has commit access) has to carry on? Isn't just plain revision number?

> The main difference to what we've done in the past is simply that we have an
> inclusive list of committers instead of a select few and that we do
> understand the image as truly being "work in progress" inbetween the
> releases. In other words, be more active, change things faster, make it
> possible to report, devise, submit, and deploy a change in a matter of
> minutes.

Woot! Sounds exciting. =)

> What do people think about this as a straw-man? Obviously, I want to enable
> people to contribute in the most straightforward way possible. Allow
> development to be more fluid, make mistakes faster, fix them faster. It does
> not address the issue of controversial / strategic changes but I think we're
> mostly loosing out on the most basic level and if we want to fix the
> processes we must make simple things simple and complex things possible, not
> the other way around.

On the account of controversial changes, I think that Squeak Oversight
Board should clearly state what changes will be acceptable without
thorough review and acceptation process by the board/community. For
example, community could commit quickly tests (any), fixes (only on
what is tested), minor improvements (which kind?) with tests, etc. A
clear statement should avoid misunderstandings, in general at least.

Andreas, I would like some clarification on how someone part of the
community, with no special rights, can contribute using your process,
method and tool. I'd be glad if you could provide a use case/scenario.

Your solution does seem leaving the little man outside the loop, sent
back to mantis or something along this line. That's hardly something
interesting. We as a community need instant feedback on our work and
be well integrated in the process. Do not set us apart! It is
important to renew the excitement of contributing to Squeak within the
community and not just for few selected committers.

Considering continuous integration would really help on that matter, I
think it's possible to push updates for review from any body to the
committers. I would really prefer a community repository rather than
yet another elitist process; but I am always fine with the idea that
the selected elites will review, accept, modify and/or reject
community committed content.

Or did I get it all wrong?

Regards,
Ian

-- 
http://mecenia.blogspot.com/