Hi Guides,
[Sorry for the belated reply but the mail server in Berne wouldn't let me send email through it. I just came home so here we go...]
I think it's important for the Guides and anyone else to understand that this idea really goes both ways. When we were talking about this in Berne, my point of view was essentially the following: SCG needs an open, extensible, clean kernel for their research work. Squeak needs an open, extensible, clean kernel for its users. What better match is there?! We have the same needs and a group of people willing and able to do the job. By providing that kernel to the Squeak community, SCG gains an interesting "playground" for their research work on and in Squeak, with the ability to experiment with everything, including VM modifications. The Squeak community gains the kernel and the ability to easily play around with any new stuff that SCG develops if that is of interest. Whether any of these developments actually makes it into "core Squeak" is quite a different matter at this point.
To me, there is a clear win-win situation if we put our trust into SCG to handle the situation appropriately and not to take overly advantage of the fact that they could in fact change the MOP of Squeak beyound recognition (but hey, isn't that the case for any package on SqueakMap?! after all the maintainers can change it at their own will and pace...). Knowing the people involved I think that this would be a very reasonable arrangement with advantages for all parties involved. Let's not forget - someone needs to maintain these aspects of Squeak and personally I'd much rather see a group of people work on this who actually understands what they are doing and what the community wants and expects out of this work.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Stephane Ducasse Sent: Sunday, February 23, 2003 8:55 PM To: The general-purpose Squeak developers list Subject: Re: Fw: [Squeakfoundation]Re: Taking control of parts of Squeak
Hi all
Just a point that may not have been made clear enough. We want to clean the kernel not change it. For our own business we will certainly come with a better one but at that time we will see.
Stef
Hi all!
Ok, most of us seem to agree that the offer from SCG/Berne to "steward" the kernel (we need of course to define what parts they really want to take responsibility for) is a good offer. If anyone still has a strong opinion against this then I would like to hear the arguments.
And besides - if people have a strong opinion against the principal at work here (and not only against the particular package/proposed maintainer) - namely that we need to partition the Squeak core into packages that people actively take responsibility for (call it what you like) - then we have a genuine problem because this is the route that we have been discussing for quite some time to take.
So... unless there are many more "strongly against" :-) then I would like us to work out some form of "rules" for these core package maintainers. This is essentially what Roel was describing.
1. Work out a draft of a ruleset for "core package maintainers". Let's keep it small and simple. Roel could perhap spost a draft to start from (please think in general and not only for the kernel stuff etc.).
2. Define core packages. In this case we simply start with the packages that SCG are interested in. Can you (SCG) define them? "Compiler" would be one of course etc.
3. Let SCG write down some form of charter or near plan or something. I think we are all interested in who will do what and what the immediate plan is.
Well, this is a delicate discussion. But it is an extremely important one to have and the community - we - really need to pull this off. Remember that SqC was a really talented group working full time. Now we have a dispersed loose group with a little group called the Guides that are *not* working full time.
In order for this to work we simple *must* partition core Squeak and let the most suited people for each part take the responsibility for it. There is no other way we can make this work.
And remember that it is already working for lots of stuff that could in fact be considered "core" today(DVS, SAR, all the VMs, Connectors, etc etc).
regards, Göran
Hmmm ok. I thought that last one was crossposted to squeak-dev, but it wasn't. Oh well, whatever. Someone else will probably smack it in there too. ;-)
regards, Göran
On Monday, February 24, 2003, at 05:17 AM, goran.hultgren@bluefish.se wrote:
So... unless there are many more "strongly against" :-) then I would like us to work out some form of "rules" for these core package maintainers. This is essentially what Roel was describing.
I'm all for entrusting the Berne fellows with maintainership of the Squeak kernel. They're the perfect candidates, actually, since they have an itch to scratch.
However, I don't know that we need to have a big rules discussion. There seems to be a certain level of comfort in the community with the idea, and as long as the development of the kernel happens out in the open, it'll become clear rather quickly what works, what doesn't and what's problematic.
We're a small enough community that we don't have to be overly concerned with rules, so much as establishing conventions for distributed maintainership of Squeak. In fact, I bet that no matter what we decide by talking about it in the abstract, what we end up actually doing will be different, and probably better.
So my suggestion would be, just do it. And my question for they Berne fellows would be, "what needs doing?"
Colin Putney Whistler.com
Hi all!
Colin Putney cputney@whistler.com wrote:
On Monday, February 24, 2003, at 05:17 AM, goran.hultgren@bluefish.se wrote:
So... unless there are many more "strongly against" :-) then I would like us to work out some form of "rules" for these core package maintainers. This is essentially what Roel was describing.
I'm all for entrusting the Berne fellows with maintainership of the Squeak kernel. They're the perfect candidates, actually, since they have an itch to scratch.
However, I don't know that we need to have a big rules discussion. There seems to be a certain level of comfort in the community with the idea, and as long as the development of the kernel happens out in the open, it'll become clear rather quickly what works, what doesn't and what's problematic.
We're a small enough community that we don't have to be overly concerned with rules, so much as establishing conventions for distributed maintainership of Squeak. In fact, I bet that no matter
I agree we don't need a lot of rules. I think I essentially was thinking about what you call "establishing conventions for distributed maintainership". Actually.
Other "rules" like in fact much what Roel mentioned could be up to the maintainership in fact. At least to start with. Eventually, especially when we have better tools like the Harvesting tool, we may perhaps try o streamline but until then I agree - let the maintainership work as they see fit for the packages they tend.
Of course, at the same time, it does feel reassuring to hear how SCG intend to work.
regards, Göran
Colin,
However, I don't know that we need to have a big rules discussion.
True. But I think some general outline of what is expected from someone who wants to "take over" a portion of kernel Squeak is good. It simply means that there's a common understanding within the community of what is expected from a "kernel package maintainer". This can only help as we are moving towards a more decentralized model of development.
Cheers, - Andreas
-----Original Message----- From: squeakfoundation-bounces@lists.squeakfoundation.org [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] On Behalf Of Colin Putney Sent: Monday, February 24, 2003 6:48 PM To: Discussing the Squeak Foundation Subject: [Squeakfoundation]Taking control of parts of Squeak
On Monday, February 24, 2003, at 05:17 AM, goran.hultgren@bluefish.se wrote:
So... unless there are many more "strongly against" :-) then I would like us to work out some form of "rules" for these core package maintainers. This is essentially what Roel was describing.
I'm all for entrusting the Berne fellows with maintainership of the Squeak kernel. They're the perfect candidates, actually, since they have an itch to scratch.
However, I don't know that we need to have a big rules discussion. There seems to be a certain level of comfort in the community with the idea, and as long as the development of the kernel happens out in the open, it'll become clear rather quickly what works, what doesn't and what's problematic.
We're a small enough community that we don't have to be overly concerned with rules, so much as establishing conventions for distributed maintainership of Squeak. In fact, I bet that no matter what we decide by talking about it in the abstract, what we end up actually doing will be different, and probably better.
So my suggestion would be, just do it. And my question for they Berne fellows would be, "what needs doing?"
Colin Putney Whistler.com
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi all!
"Andreas Raab" andreas.raab@gmx.de wrote:
Colin,
However, I don't know that we need to have a big rules discussion.
True. But I think some general outline of what is expected from someone who wants to "take over" a portion of kernel Squeak is good. It simply means that there's a common understanding within the community of what is expected from a "kernel package maintainer". This can only help as we are moving towards a more decentralized model of development.
I agree.
I also agree with Colin that we shouldn't get tangled in trying to establish a complicated rule set that noone will follow and just make people hesitant of becoming a kernel package maintainer. :-) But I think we can avoid that.
But again - for a *particular* maintainer to present how he/she/they intend to maintain a *particular* package is very good.
So, to be a bit constructive here - I would like the community to produce the following:
1. A very small rule set for being a kernel package maintainer. Say, about 5 rules? :-)
2. Some form of simple process how to become a kernel package maintainer, how to stay one :-), and how to move the stick to someone else.
And lets stay out of the "technical how" for a bit. We can attack that as the next step. So... is this admittedly short list what we need? If it is then I can continue by presenting a little draft based both on ideas from Roel etc.
regards, Göran
PS. I intend to produce some form of proposal here on this list and then, when we agree on it - post it on squeak-dev and see what all others think.
Hi Göran,
- A very small rule set for being a kernel package maintainer. Say,
about 5 rules? :-)
I dunno. It seems very hard (at least to me) to come up with a set of rules here. Something more loosely defined such as "guide lines" might be more appropriate (this is why I was referring to a "general outline").
But let's see. One rule (or rather guide line) which I think is important for the community is a "controlled rate of evolution". What I mean by this is that while we expect the kernel packages to evolve as any other part of Squeak there is always the danger of breaking existing stuff (much more so than in any other package). I _think_ that this means that larger scale changes have to be discussed with the community first and that a time line for deployment needs to be developed prior to making it part of the "core release". It should give other maintainers enough time to get the changes integrated and should probably come along with some "migration support" (whatever this means in the concrete case - it could be automated tools, it could just be an FAQ).
Hm ... just thinking about it I think that's essentially the only "rule" I can come up with. Other than that there seems to be no difference between a package which is part of "kernel Squeak" and one that isn't. It's really the aspect of evolution (e.g., rate of change, stability etc) that makes a kernel package "different" from any other, which effectively means that a kernel package maintainer needs to be a bit more conservative for her stuff than Joe-Doe.
Cheers, - Andreas
-----Original Message----- From: squeakfoundation-bounces@lists.squeakfoundation.org [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] On Behalf Of goran.hultgren@bluefish.se Sent: Monday, February 24, 2003 9:28 PM To: Discussing the Squeak Foundation Subject: RE: [Squeakfoundation]Taking control of parts of Squeak
Hi all!
"Andreas Raab" andreas.raab@gmx.de wrote:
Colin,
However, I don't know that we need to have a big rules
discussion.
True. But I think some general outline of what is expected
from someone who
wants to "take over" a portion of kernel Squeak is good. It
simply means
that there's a common understanding within the community of
what is expected
from a "kernel package maintainer". This can only help as
we are moving
towards a more decentralized model of development.
I agree.
I also agree with Colin that we shouldn't get tangled in trying to establish a complicated rule set that noone will follow and just make people hesitant of becoming a kernel package maintainer. :-) But I think we can avoid that.
But again - for a *particular* maintainer to present how he/she/they intend to maintain a *particular* package is very good.
So, to be a bit constructive here - I would like the community to produce the following:
- A very small rule set for being a kernel package maintainer. Say,
about 5 rules? :-)
- Some form of simple process how to become a kernel package
maintainer, how to stay one :-), and how to move the stick to someone else.
And lets stay out of the "technical how" for a bit. We can attack that as the next step. So... is this admittedly short list what we need? If it is then I can continue by presenting a little draft based both on ideas from Roel etc.
regards, Göran
PS. I intend to produce some form of proposal here on this list and then, when we agree on it - post it on squeak-dev and see what all others think.
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi Andreas,
Very well said indeed.
Do we expect to see a report on Berne conference in WSJ any time soon ;-)
Cheers,
PhiHo.
----- Original Message ----- From: "Andreas Raab" andreas.raab@gmx.de To: squeakfoundation@lists.squeakfoundation.org Sent: Sunday, February 23, 2003 6:33 PM Subject: RE: Fw: [Squeakfoundation]Re: Taking control of parts of Squeak
Hi Guides,
[Sorry for the belated reply but the mail server in Berne wouldn't let me send email through it. I just came home so here we go...]
I think it's important for the Guides and anyone else to understand that this idea really goes both ways. When we were talking about this in Berne, my point of view was essentially the following: SCG needs an open, extensible, clean kernel for their research work. Squeak needs an open, extensible, clean kernel for its users. What better match is there?! We have the same needs and a group of people willing and able to do the job. By providing that kernel to the Squeak community, SCG gains an interesting "playground" for their research work on and in Squeak, with the ability to experiment with everything, including VM modifications. The Squeak community gains the kernel and the ability to easily play around with any new stuff that SCG develops if that is of interest. Whether any of these developments actually makes it into "core Squeak" is quite a different matter at this point.
To me, there is a clear win-win situation if we put our trust into SCG to handle the situation appropriately and not to take overly advantage of the fact that they could in fact change the MOP of Squeak beyound recognition (but hey, isn't that the case for any package on SqueakMap?! after all the maintainers can change it at their own will and pace...). Knowing the people involved I think that this would be a very reasonable arrangement with advantages for all parties involved. Let's not forget - someone needs to maintain these aspects of Squeak and personally I'd much rather see a group of people work on this who actually understands what they are doing and what the community wants and expects out of this work.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Stephane Ducasse Sent: Sunday, February 23, 2003 8:55 PM To: The general-purpose Squeak developers list Subject: Re: Fw: [Squeakfoundation]Re: Taking control of parts of Squeak
Hi all
Just a point that may not have been made clear enough. We want to clean the kernel not change it. For our own business we will certainly come with a better one but at that time we will see.
Stef
_______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org
-
Andreas Raab -
Colin Putney -
goran.hultgren＠bluefish.se -
PhiHo Hoang