Hi Bert!

Bert Freudenberg <bert at impara.de> wrote:
> Am 23.09.2005 um 09:13 schrieb goran at krampe.se:
> 
> > Hi Daniel and all!
> >
> > Daniel Vainsencher <daniel.vainsencher at gmail.com> wrote:
> >
> >> Hi all. We've been discussing on the packages list how to make life
> >> easier on harvesters and everyone else that cares about what goes  
> >> on in
> >> the alpha, development stages.
> >>
> >> Here are some things that you might consider. I am not stating agreed
> >> policy, just a proposal for such.
> >>
> >
> > I have been exchanging some emails with Ken on this - we kinda slided
> > into the discussion when he joined the Coord group - it is of course a
> > dear subject to Ken and me too. I agree with everything you wrote but
> > there are even more things related to this.
> >
> > Ken and I will post soon on a "larger" sketch about this and then  
> > we all
> > can dissect/shoot it down together here on squeak-dev. :) And  
> > eventually
> > come up with something we can club.
> 
> A nice community project might be adding bug tracking facilities to  
> SqueakSource.

Yes. :)

But we have focused on how to integrate this new process with:
	- Stewarding
	- Mantis as it stands today
	- The concept of a release Team (instead of and/or a harvester team)
	- ..and how to live with pre-3.8, 3.8 and 3.9 images
		- pre 3.8 still have the "mail to list" mechanism causing people to
send ENH/FIX to squeak-dev
		- 3.8 can be tinkered with using a post-release update in which we can
"block/adjust" that mechanism
		- 3.9 can of course also be tinkered in that respect.

One way to technically make CSes more pleasant is integrating/debugging
this package into 3.9 and 3.8:

	http://map1.squeakfoundation.org/sm/packagebyname/packageinfo-ex

Which can given a CS - split it based on the PIs into multiple
one-per-MC-changesets and compose an email with all those parts
including the original full CS and mail it to all affected maintainers
and co-maintainers according to the registered PIs in SM.

This would enable "direct feedback" of fixes/enhs to the Stewards
(=maintainers and co-maintainers according to SM) which then in turn
could use the new "inbox" process to feed MCs to the harvesters/release
team.

In fact - when thinking about it this resembles the way the Linux kernel
is maintained. :)

So... now I jumped ahead - but give us a day or three :) to write down a
more careful sketch.

regards, Göran