I agree this is the most important bug that's up for discussion about 3.4. I'm not sure it's worse than the 3.2 bug we're trying to solve (public release doesn't include SM).
Opinions?
Suggestion - make 3.5 a very short release, consisting mainly of getting as many fixes in as we can, and giving them a proper testing. It's an opportunity for us Guides to warm up at doing the whole process ourselves. I'm talking about a time scale of 1 month total - 2 weeks alpha, 1 week beta, 1 week gamma, release. We start with specific, very doable goals (maybe even decide in advance a prioritized list of fixes we want to get in, not trying to catch up with everything that's up for harvesting), and basically spill them all into the update stream on day one, with the rest of the time for integration. Fixes that aren't ready for integration (meaning, posted tested, and reviewed by someone) by the end of week 1 will wait for 3.6.
Doug, guys, do you think this is reasonable? desirable?
Daniel
Bert Freudenberg bert@isg.cs.uni-magdeburg.de wrote:
Am Freitag, 28.02.03 um 02:01 Uhr schrieb Doug Way:
Craig Latta wrote:
Hi Ned--
Are we going to do anything about them?
I think we should address them in 3.5, not 3.4. In theabsence of other open issues, I think we should release 3.4.
I was going to agree with Craig here, these bugs alone don't seem serious enough to postpone the 3.4 release.
Are you going to include the other things that already have fixes?
The "release" will be the one newbies use. They might not know how to update, or even if they do, they might hesitate to do so (it is somewhat scary to change your tires while running at 100 mph, isn't it?).
For example, I consider project publishing to be extremely important for newbies and it has a bug we ran into, which fortunately was fixed by Nishihara Satoshi (http://groups.yahoo.com/group/squeak/message/54616). I tried with 3.4gammaOne and the fix is not in there.
-- Bert
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher danielv@netvision.net.il wrote:
Suggestion - make 3.5 a very short release, consisting mainly of getting as many fixes in as we can, and giving them a proper testing. It's an opportunity for us Guides to warm up at doing the whole process ourselves. I'm talking about a time scale of 1 month total - 2 weeks alpha, 1 week beta, 1 week gamma, release.
I find it just about impossible to imagine getting stuff done that quickly given the geographic and chronologic spread of people involved. It'll take more than two weeks before any decent number of people heve even downloaded 3.4, let alone done anything much to find and fix any bugs.
For topics to cover + relating to the vm, how about incorporating any removal of vm/slang code that we can manage - JMM & I have been trying to get a decent release of codegen stuff together and can probably produce a removal update and re-install package. + in the image, how about the remove-b3d etc changes? + how about declaring that only fixes released by a certain date will be considered and that after that only comment improvements will be accepted ?
tim
Tim Rowledge tim@sumeru.stanford.edu writes:
I find it just about impossible to imagine getting stuff done that quickly given the geographic and chronologic spread of people involved. It'll take more than two weeks before any decent number of people heve even downloaded 3.4, let alone done anything much to find and fix any bugs.
I think it's hard to imagine because we're all used to a different process. However, with a steady monthly rhythm and known dates we would all soon adjust. Eg when the world knows that "3.x comes out on the 1st" it will get downloaded a lot quicker. If bugs or major enhancements aren't ready in time for the release, fine, they show up next month (or the month after or..).
NB in the worst case, release time rolls around and noone's had time to do anything this month, we'd be just re-releasing (we'd probably skip that one). That's fine. The larger process is far more important.
Of course we can debate the optimal duration of an "iteration" - one month, two months, three.. personally I feel one month works here. A faster cycle allows us to learn and improve the process more quickly.
On Sat, 2003-03-01 at 17:48, Simon Michael wrote:
However, with a steady monthly rhythm and known dates we would all soon adjust.
I think a month is too short. My preference is still a quarter now and probably slowing down to 6 months when all there's left to be released centrally is just the kernel/core.
In any case, I feel we must not set goals at this point in time that will risk the next production version getting out much later than in ~3 months. The reason is that the changes are going to be massive (with all the 'taking apart' going on), and the smaller steps we make, the more likely we'll be in succeeding.
I did a 5 month release last december (i.e. work collected since Summer 2002). I deeply regretted it, and immediately proclaimed a weekly schedule. May sound like a deadline, but as we're just scoping time, not work, it is actually much more relaxed.
squeakfoundation@lists.squeakfoundation.org
-
Cees de Groot -
Daniel Vainsencher -
Simon Michael -
Tim Rowledge