I think you're completely right. Of these big projects, the ones that moved are the ones that had a harvester actively looking out for them, and moving them forward process wise.
As someone doing some of this, I don't think we can "assign" anyone to work on these. Its more a question of whether other harvesters actually want to get involved with this aspect of the process.
Daniel
Doug Way dway@riskmetrics.com wrote:
1 Removals 2 KCP 3 MCP 4 Anthony runtime enhancements (split in two - fixes and closures) 5 Craig's simulator fixes 6 mir Network rewrite 7 TrueTypeTextStyle 8 Diego look style enhancements 9 Replace fonts with AccuFonts (mainly in order to remove the old - people can now load additional nice fonts themselves anyway). 10 SM 1.1 11 Inclusion of SM plus related packages in the release image (though maintained as packages, not directly by update stream).
Here's our current 3.6 plan list of larger enhancements/tasks. Right now, we have 4 1/2 of these done... maybe we'll get a couple more in before the end of the week. They've been moving along somewhat slowly for various reasons.
For larger enhancements, specifically these ones singled out for the 3.6 release, I wonder if it would help to assign a guide or harvester as a "shepherd" for each one. Someone who would be responsible for tracking progress on the enhancement and deciding when enough review has happened and when it's ready to go in. Right now, there's not really anyone responsible for most of these, so it sort of falls to me to make sure something happens, or a random person complaining on one of the mailing lists. I don't really have time to handle all of these myself.
I remember Goran hinted at something like this with his PROP proposal or whatever it was. But just something simple like assigning people to shepherd these items might help things get done.
Does this make sense?
- Doug
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher wrote:
I think you're completely right. Of these big projects, the ones that moved are the ones that had a harvester actively looking out for them, and moving them forward process wise.
As someone doing some of this, I don't think we can "assign" anyone to work on these. Its more a question of whether other harvesters actually want to get involved with this aspect of the process.
Right. For example, I was going to look at the Accufonts item tonight/tomorrow, so I can be the shepherd for that one.
You (Daniel) are already the shepherd of sorts for the remaining KCP items, and Goran is for SM 1.1.
I think this is the reason Craig's simulator fixes haven't made it in yet, for example... no one's moving that one forward. It sounds like someone in Berne (Alexandre?) was using the fixes with success. Shepherding that one would simply be a matter of emailing with Alexandre and getting him to post his feedback to the list, or posting it for him, and then announcing a decision on the list that this feedback should be enough to warrant that the changes go in (if the feedback is indeed good enough). Then I can add the changes in the next batch of updates. Perhaps Craig or Tim would be interested in following up on this?
It would also be good if someone could volunteer to shepherd TrueTypeTextStyle and Diego's look enhancements. Although it's getting a bit late for 3.6alpha if we're moving to beta on Friday, but who knows...
- Doug
Daniel
Doug Way dway@riskmetrics.com wrote:
1 Removals 2 KCP 3 MCP 4 Anthony runtime enhancements (split in two - fixes and closures) 5 Craig's simulator fixes 6 mir Network rewrite 7 TrueTypeTextStyle 8 Diego look style enhancements 9 Replace fonts with AccuFonts (mainly in order to remove the old - people can now load additional nice fonts themselves anyway). 10 SM 1.1 11 Inclusion of SM plus related packages in the release image (though maintained as packages, not directly by update stream).
Here's our current 3.6 plan list of larger enhancements/tasks. Right now, we have 4 1/2 of these done... maybe we'll get a couple more in before the end of the week. They've been moving along somewhat slowly for various reasons.
For larger enhancements, specifically these ones singled out for the 3.6 release, I wonder if it would help to assign a guide or harvester as a "shepherd" for each one. Someone who would be responsible for tracking progress on the enhancement and deciding when enough review has happened and when it's ready to go in. Right now, there's not really anyone responsible for most of these, so it sort of falls to me to make sure something happens, or a random person complaining on one of the mailing lists. I don't really have time to handle all of these myself.
I remember Goran hinted at something like this with his PROP proposal or whatever it was. But just something simple like assigning people to shepherd these items might help things get done.
Does this make sense?
- Doug
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Doug Way dway@riskmetrics.com wrote:
Although it's getting a bit late for 3.6alpha if we're moving to beta on Friday, but who knows...
I _really_ don't think that is a good idea. We really ought to get at least the basic, decently reviewed and tested, stuff that we declared in the image before changing to beta. We're not being pushed by any dumbass marketing droid for a release date so let's take the luxury of at least trying to achieve feature completion!
If someone can point me to where the code is I'll check out the simulator changes so we can at least get _them_ done. In return I want someone to review the DeclarativePools stuff. :-)
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Stuck on the down escalator of life.
On Tue, Jun 24, 2003 at 04:27:30PM -0700, Tim Rowledge wrote:
Doug Way dway@riskmetrics.com wrote:
Although it's getting a bit late for 3.6alpha if we're moving to beta on Friday, but who knows...
I _really_ don't think that is a good idea. We really ought to get at least the basic, decently reviewed and tested, stuff that we declared in the image before changing to beta. We're not being pushed by any dumbass marketing droid for a release date so let's take the luxury of at least trying to achieve feature completion!
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Marcus
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Agree as I mention in one of my early emails. 3.6 should be sexy in terms of new stuff/clean/improvements. Let us make it really sexy.
The process is just starting to work.
Stef
Marcus
-- Marcus Denker marcus@ira.uka.de -- Squeak! http://squeak.de
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Stephane Ducasse ducasse@iam.unibe.ch wrote:
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Agree as I mention in one of my early emails. 3.6 should be sexy in terms of new stuff/clean/improvements. Let us make it really sexy.
Hmmm. And then people - WHY DIDN'T YOU SAY THIS WHEN THE 3.6 PLAN WAS POSTED???
He, I couldn't help myself, sorry for the shouting. ;-) But I really mean it. We agreed on the plan. And one of the things we wanted to do is to have faster release cycles than before - we are aiming for 3 releases per year IIRC.
There will ALWAYS be stuff to harvest. There will ALWAYS be cool new stuff to add. But we need a proper beta and gamma period.
Personally I think we should stick to the plan but move the beta start a few days so that NewLook, TTF and Simulatorfixes can get in.
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
regards, Göran
I'm going to shout also... Seems like an acepted way.
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Agree as I mention in one of my early emails. 3.6 should be sexy in terms of new stuff/clean/improvements. Let us make it really sexy.
Hmmm. And then people - WHY DIDN'T YOU SAY THIS WHEN THE 3.6 PLAN WAS POSTED???
IIRC, There was a (big?) group of people saying that since the very beginning.
He, I couldn't help myself, sorry for the shouting. ;-) But I really mean it. We agreed on the plan. And one of the things we wanted to do is to have faster release cycles than before - we are aiming for 3 releases per year IIRC.
We are not talking about the plan. We're talking WHAT to do in the case (like now) that the plan CAN'T be respected.
We had choosed Date and Features (an error in itself). Some of us want to respect the date, other (including me) want to respect the Features.
There will ALWAYS be stuff to harvest. There will ALWAYS be cool new stuff to add. But we need a proper beta and gamma period.
What is more important? the "proper periods" or the results?
Personally I think we should stick to the plan but move the beta start a few days so that NewLook, TTF and Simulatorfixes can get in.
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
Every time we talked about what to include in tha image the anser was: "Ehhh... wait... the configuration maps are coming".
IMO, the SM1.1 is a MUST to avoid a fork in the community.
regards, Göran
Diego.
PS: Oops... I REALIZED I DIDN'T SHOUT!
Hi all!
diegogomezdeck@consultar.com wrote:
I'm going to shout also... Seems like an acepted way.
Well, no - it is probably not. Except when the sender is Richard! ;-)
It was dumb of me to introduce CAPS but I *did* add a smiley etc. I will not use it anymore.
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Agree as I mention in one of my early emails. 3.6 should be sexy in terms of new stuff/clean/improvements. Let us make it really sexy.
Hmmm. And then people - WHY DIDN'T YOU SAY THIS WHEN THE 3.6 PLAN WAS POSTED???
IIRC, There was a (big?) group of people saying that since the very beginning.
I have looked through the "3.6 Plan" thread (many posts so mostly skimming) and can not find this. Sure, there were discussions and TTF + NewLook was proposed and incorporated. But nothing more as I could see it. We discussed, added a few things and got to a conclusion - that is how I read it.
So the thing I am reacting about now is adding even *more* (and we are not talking FIXes - they always go in). And not TTF and NewLook - they are going in as we speak if people do their reviewing now. TTF seems to be in the clear, don't know the final saying on NewLook.
He, I couldn't help myself, sorry for the shouting. ;-) But I really mean it. We agreed on the plan. And one of the things we wanted to do is to have faster release cycles than before - we are aiming for 3 releases per year IIRC.
We are not talking about the plan. We're talking WHAT to do in the case (like now) that the plan CAN'T be respected.
Who says it CAN'T be respected? I say it can.
You are saying - this is how it sounds anyway and please correct me - that you didn't agree to the plan in the first place so now you are implying that we should forget about the plan and start adding whatever makes it sexy enough?
I don't buy it.
We had choosed Date and Features (an error in itself). Some of us want to respect the date, other (including me) want to respect the Features.
It was not an error - it was a calculated balance.
There will ALWAYS be stuff to harvest. There will ALWAYS be cool new stuff to add. But we need a proper beta and gamma period.
What is more important? the "proper periods" or the results?
The result is highly connected to the beta/gamma periods. If we don't have them then the end result will suffer in stability. We all know that.
Personally I think we should stick to the plan but move the beta start a few days so that NewLook, TTF and Simulatorfixes can get in.
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
Every time we talked about what to include in tha image the anser was: "Ehhh... wait... the configuration maps are coming".
IMO, the SM1.1 is a MUST to avoid a fork in the community.
I agree. Read my other post where I explain what I mean.
regards, Göran
Hi Göran,
A silent thought:
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
It can't wait any longer than 3.6. I've mentioned this before but things will get critical with 3.6. Once significant packages are permanently hosted outside the Squeak image it means we'll have some serious trouble maintaining these without SM1.1. For example, consider the VMMaker package - if that gets "out of sync" during 3.7alpha we're really screwed. The same holds for a number of packages but VMMaker is probably the most critical in this regard.
If we really want these packages to live permanently outside the image then we need SM1.1. Everything else is going to be one big mess and the longer (in terms of releases) we have to wait before it comes the worse it'll get.
Cheers, - Andreas
Hi!
"Andreas Raab" andreas.raab@gmx.de wrote:
Hi Göran,
A silent thought:
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
It can't wait any longer than 3.6. I've mentioned this before but things will get critical with 3.6. Once significant packages are permanently hosted outside the Squeak image it means we'll have some serious trouble maintaining these without SM1.1. For example, consider the VMMaker package -
I know this.
if that gets "out of sync" during 3.7alpha we're really screwed. The same holds for a number of packages but VMMaker is probably the most critical in this regard.
If we really want these packages to live permanently outside the image then we need SM1.1. Everything else is going to be one big mess and the longer (in terms of releases) we have to wait before it comes the worse it'll get.
Again, I know this too. What I was saying was that the exact point in time when we really need SM1.1 to be there for us is when the first external package is getting ready to be released in a new release for 3.7.
That is all I am saying. I am not sure what this means for the process! Of course I want SM1.1 to get ready yesterday but I have a job and a life outside of Squeak. I am really trying to get time enough to push it through during july - I have vacation all of july.
If people think that 3.6 can be released without SM1.1 then fine. Just as long as people are aware of the fact that we will not be able to release new versions of the externalized packages after that until SM1.1 is there.
regards, Göran
Hi goran
but the plan 3.6 is perfect for me. We just have to stick with it. Sexy for me means having a
- clean kernel - diego stuff, - closure, - netwrok rewrite - simulator ....
So 3.6 is PERFECT but 3.5,5 is not so that is why I said that I would prefer that 3.6 should not come in beta just now.
Stef
On Thursday, June 26, 2003, at 10:21 AM, goran.krampe@bluefish.se wrote:
Stephane Ducasse ducasse@iam.unibe.ch wrote:
I'm against having a release on Friday.
Just look at the BugfixArchive: There's a lot of stuff pending, which really needs to be included. And my feeling is, that there's just not enough "new" stuff in 3.6 to allow a new release: Like 3.5, we'd get a "new release" nobody would use.
Agree as I mention in one of my early emails. 3.6 should be sexy in terms of new stuff/clean/improvements. Let us make it really sexy.
Hmmm. And then people - WHY DIDN'T YOU SAY THIS WHEN THE 3.6 PLAN WAS POSTED???
He, I couldn't help myself, sorry for the shouting. ;-) But I really mean it. We agreed on the plan. And one of the things we wanted to do is to have faster release cycles than before - we are aiming for 3 releases per year IIRC.
There will ALWAYS be stuff to harvest. There will ALWAYS be cool new stuff to add. But we need a proper beta and gamma period.
Personally I think we should stick to the plan but move the beta start a few days so that NewLook, TTF and Simulatorfixes can get in.
IMHO SM1.1 can wait until early 3.7. Even if it breaks my heart to admit it. :-)
regards, Göran _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi Tim--
If someone can point me to where the code is I'll check out the simulator changes so we can at least get _them_ done.
http://aspn.activestate.com/ASPN/Mail/Message/squeak/1662509
(That site seems to be a good cache of Squeak list traffic generally.)
thanks,
-C
-- Craig Latta http://netjam.org/resume craig@netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
If someone can point me to where the code is I'll check out the simulator changes so we can at least get _them_ done.
http://aspn.activestate.com/ASPN/Mail/Message/squeak/1662509
OK, so far as I can see _none_ of this goes in the basic image and the only issues are a) remembering to rename a couple of things since I am proposing renaming Test* to SmartSyntax* since it is a little less meaningless. b) deciding whether the simulator stuff ought to be dropped in with the VMMaker package or be kept as a separate but dependent package.
This means that this punchlist item now also depends on DeclarativePools :-)
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Got a life, but wasn't sure what to do with it.
It would also be good if someone could volunteer to shepherd TrueTypeTextStyle and Diego's look enhancements. Although it's getting a bit late for 3.6alpha if we're moving to beta on Friday, but who knows...
I'm getting really tired.
Diego
On Wed, Jun 25, 2003 at 05:26:02AM -0400, diegogomezdeck@consultar.com wrote:
It would also be good if someone could volunteer to shepherd TrueTypeTextStyle and Diego's look enhancements. Although it's getting a bit late for 3.6alpha if we're moving to beta on Friday, but who knows...
I'm getting really tired.
Yes, I totally understand you. We shouldn't forget that this ought to be *fun*. We should try to not set up a process that takes the fun away.
I don't know why, but I got *really* depressed when reading about doing a release late last week: somehow, I got the feeling that the "process" starts to get more important than the artifact. And that's not good.
Marcus
squeakfoundation@lists.squeakfoundation.org