What about making a more formal approach concerning next release?
It would be very useful to have a roadmap, what features we want in next release. We can divide things/initiatives onto subprojects and place this on a web page. This will serve good both for historical and organizational reasons. This will help community (and newcomers) to be certain in what direction we are moving and what most of us want to see in next release. On 19/03/2008, Edgar J. De Cleene <[hidden email]> wrote: > > > > El 3/4/08 12:24 PM, "Matthew Fulmer" <[hidden email]> escribió: > > > > The last "Release Team" meeting happened last Monday, 25 > > February. I summarized the results of the meeting at > > http://installer.pbwiki.org/MeetingNotes002 > > > > Based on the results, I started an agenda for the next meeting, > > which is not yet scheduled: > > http://installer.pbwiki.org/MeetingNotes003 > > > > If you have questions about the release team, or want to discuss > > something, add an item to the agenda and come to the next > > meeting. You can either add them directly to the page, or email > > me, and I'll add them to the page > > > > -- > > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 > > > Matthew: > > I thanks you organizational efforts. > > Slowly I reading all mails for I don't miss some important. > > Maybe we could use current v3dot10 reduced list or ask to web team for a new > "future Squeak" discussion list, for advance in clarify all ideas ? > > I wish start 3.11, following previous ideas. > > Seems a shorter goal and a more compatible one with actual Squeak. > > > Edgar > > > > > -- Best regards, Igor Stasenko AKA sig. |
El 3/20/08 1:29 AM, "Igor Stasenko" <[hidden email]> escribió: > What about making a more formal approach concerning next release? It would be > very useful to have a roadmap, what features we want in next release. We can > divide things/initiatives onto subprojects and place this on a web page. This > will serve good both for historical and organizational reasons. This will help > community (and newcomers) to be certain in what direction we are moving and > what most of us want to see in next release. +1 for me. I resume my view, for all could send feedback and we could collect somewhere. 3.10 was the first release with some "package out" from previous 3.9 in automatic and predictable way. For this take the learning of Pavel with his Kernel and MinimalMorphic and mine from SqueakLight. Of course the list of people doing shrinking is bigger , as I put in my old pages about SqueakLight http://wiki.squeak.org/squeak/3935 I wish going as close is possible towards MinimalMorphic, reshape current Morphic (1.3 mb mcz) with my old "Ladrillos " http://www.squeaksource.com/Ladrillos.html I have the new ReleaseBuilderFor3dot11 class, as we have in the old days and use again in 3dot10. So this class documents all shrinking and reorganization I propose. I see in this days some propose having Smalltalk current cleanUp using the Ramon Leon script as start point. Being off line , I put a cleanupPhaseFinal in ReleaseBuilderFor3dot11 with some things I was discovering in the shrinking process. So , I was ready for cut the following from 3.10 'Tests' 'SMLoader' 'SMBase' 'SUnit' 'SUnitGUI' 'ScriptLoader' 'Universes' 'Installer' 'XML-Parser' 'BookMorphandFriends' 'EToys-StarSqueak' 'MorphicExtras-Demo' 'MorphicExtras-Components' 'EToys' Still some more polish needed and agree with Pavel if this was the best reorg and take all methods changes needed from MinimalMorphic or do the needed ajustments. For Squeak3.10.gamma.7159.image Smalltalk size 1947 For MinimalMorphic.19 Smalltalk size 1278 For "tentative" Squeak 3.11 Smalltalk size 1495 And we have Flaps and could load and unload projects. So I think this was a good nine months target for polishing all and trying DeltaStreams / Monticello2 as update mechanism Edgar |
Good, how we suppose to arrange this?
Add new wiki entry? I would prefer a page at squeak.org , since squeak release is our major product, so we need to keep information about it up to date and easy to find. On 20/03/2008, Edgar J. De Cleene <[hidden email]> wrote: > > > > El 3/20/08 1:29 AM, "Igor Stasenko" <[hidden email]> escribió: > > > > What about making a more formal approach concerning next release? > It would be > > very useful to have a roadmap, what features we want in > next release. > We can > > divide things/initiatives onto subprojects and place this on a > web page. This > > will serve good both for historical and organizational > reasons. > This will help > > community (and newcomers) to be certain in what > direction we are moving and > > what most of us want to see in next > release. > > > +1 for me. > > I resume my view, for all could send feedback and we could collect > somewhere. > > 3.10 was the first release with some "package out" from previous 3.9 in > automatic and predictable way. > > For this take the learning of Pavel with his Kernel and MinimalMorphic and > mine from SqueakLight. > > Of course the list of people doing shrinking is bigger , as I put in my old > pages about SqueakLight http://wiki.squeak.org/squeak/3935 > > I wish going as close is possible towards MinimalMorphic, reshape current > Morphic (1.3 mb mcz) with my old "Ladrillos " > http://www.squeaksource.com/Ladrillos.html > > I have the new ReleaseBuilderFor3dot11 class, as we have in the old days and > use again in 3dot10. > > So this class documents all shrinking and reorganization I propose. > > I see in this days some propose having Smalltalk current cleanUp using the > Ramon Leon script as start point. > > Being off line , I put a cleanupPhaseFinal in ReleaseBuilderFor3dot11 with > some things I was discovering in the shrinking process. > > So , I was ready for cut the following from 3.10 > 'Tests' 'SMLoader' 'SMBase' 'SUnit' 'SUnitGUI' 'ScriptLoader' 'Universes' > 'Installer' 'XML-Parser' 'BookMorphandFriends' 'EToys-StarSqueak' > 'MorphicExtras-Demo' 'MorphicExtras-Components' 'EToys' > > Still some more polish needed and agree with Pavel if this was the best > reorg and take all methods changes needed from MinimalMorphic or do the > needed ajustments. > > For Squeak3.10.gamma.7159.image > Smalltalk size 1947 > > For MinimalMorphic.19 > Smalltalk size 1278 > > For "tentative" Squeak 3.11 > Smalltalk size 1495 > > And we have Flaps and could load and unload projects. > > So I think this was a good nine months target for polishing all and trying > DeltaStreams / Monticello2 as update mechanism > > > Edgar > > > -- Best regards, Igor Stasenko AKA sig. |
On Thu, Mar 20, 2008 at 06:17:13PM +0200, Igor Stasenko wrote:
> Good, how we suppose to arrange this? > Add new wiki entry? > I would prefer a page at squeak.org , since > squeak release is our major product, so we need to keep information > about it up to date and easy to find. I have been recording what happens in our meetings at http://installer.pbwiki.org/MeetingNotes . I just started a home-page for the release team with links to the current releases and efforts to do that: http://installer.pbwiki.org/SqueakReleaseTeam By request of the board, a strictly MIT-based image is currently top-priority, and, as a license change is a major change, a cleanly-licensed image will be Squeak 4.0. I've summarized what we have decided about what Squeak 4.0 will be. http://installer.pbwiki.org/Squeak40 Next meeting's agenda is to define a roadmap and scope for Squeak40. I look forward to what Edgar has to say, as he has a lot of experience knowing what is required. Our next meeting will be Monday, 24 March at 18:00 UTC by Edgar's request: http://installer.pbwiki.org/MeetingNotes004 So far, most of the discussion has been between myself, Craig, and Pavel. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ |
In reply to this post by Igor Stasenko
Igor Stasenko ha scritto:
> What about making a more formal approach concerning next release? > It would be very useful to have a roadmap, what features we want in > next release. Why not two lists of features, one for the next release and one for that after the next. > We can divide things/initiatives onto subprojects and place this on a > web page. This will serve good both for historical and organizational > reasons. > This will help community (and newcomers) to be certain in what > direction we are moving and what most of us want to see in next > release. > What would help even better is having a time-boxed release cycle, so that the community and the other stakeholder can know in advance _when_ the next release will happen (with some approximation, of course). Giovanni |
On Fri, Mar 21, 2008 at 04:41:28PM +0000, Giovanni Corriga wrote:
> Igor Stasenko ha scritto: >> What about making a more formal approach concerning next release? >> It would be very useful to have a roadmap, what features we want in >> next release. > > Why not two lists of features, one for the next release and one for that > after the next. We just havn't got around to discussing that yet. >> We can divide things/initiatives onto subprojects and place this on a >> web page. This will serve good both for historical and organizational >> reasons. >> This will help community (and newcomers) to be certain in what >> direction we are moving and what most of us want to see in next >> release. > > > What would help even better is having a time-boxed release cycle, so that > the community and the other stakeholder can know in advance _when_ the next > release will happen (with some approximation, of course). I'll try to do that. I think 4.0 could be ready in 2-3 months. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ |
Matthew Fulmer ha scritto:
> On Fri, Mar 21, 2008 at 04:41:28PM +0000, Giovanni Corriga wrote: >> Igor Stasenko ha scritto: >>> We can divide things/initiatives onto subprojects and place this on a >>> web page. This will serve good both for historical and organizational >>> reasons. >>> This will help community (and newcomers) to be certain in what >>> direction we are moving and what most of us want to see in next >>> release. >> >> What would help even better is having a time-boxed release cycle, so that >> the community and the other stakeholder can know in advance _when_ the next >> release will happen (with some approximation, of course). > > I'll try to do that. I think 4.0 could be ready in 2-3 months. > Hmm, is that enough time for a proper alpha-beta-gamma cycle with significant improvements to the image? Or are you suggesting that for 4.0 we simply move to an MIT-licensed Kernel Image, without further changes? Giovanni |
On Mon, Mar 24, 2008 at 12:08:17AM +0000, Giovanni Corriga wrote:
> Matthew Fulmer ha scritto: >> On Fri, Mar 21, 2008 at 04:41:28PM +0000, Giovanni Corriga wrote: >>> Igor Stasenko ha scritto: >>>> We can divide things/initiatives onto subprojects and place this on a >>>> web page. This will serve good both for historical and organizational >>>> reasons. >>>> This will help community (and newcomers) to be certain in what >>>> direction we are moving and what most of us want to see in next >>>> release. >>> >>> What would help even better is having a time-boxed release cycle, so that >>> the community and the other stakeholder can know in advance _when_ the >>> next release will happen (with some approximation, of course). >> I'll try to do that. I think 4.0 could be ready in 2-3 months. > > Hmm, is that enough time for a proper alpha-beta-gamma cycle with > significant improvements to the image? Or are you suggesting that for 4.0 > we simply move to an MIT-licensed Kernel Image, without further changes? This topic has not yet been discussed, but my inclination is just to get a relicense out as fast as possible, so that we can join the conservancy and people like Randal can use squeak for their business. This is a topic for the next meeting: http://installer.pbwiki.org/MeetingNotes004 -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ |
Free forum by Nabble | Edit this page |