Simon, the reason I very much am waiting to hear Doug on this topic, and speaking about 1 month releases should be very tentative, is that none of us has Actually Done It. Doug might know how much the price of a release is, and how much it might be reduced, and whether he has time for it/someone else can do it in reasonable time, and those'll be the prime considerations in deterimining how often it will happen.
Even doing only a short first release (without setting a fixed rythm yet), as I propose, depends on these parameters.
Daniel
Simon Michael simon@joyful.com wrote:
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. _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hmm. Having gone through the process (well, at least most of it), I suppose a one-month release might be barely workable if the goal was limited to fixes only as you say. One problem has been coordinating things via email (such as new VM releases, getting problems fixed), but I suppose these things get better when people know what to expect after the first time through.
The big question for me is whether we would want to have a fixes-only release. In other words, how does the quality of the 3.4 release with respect to bugs compare with other recent releases?
I recall that the 3.0 release was pretty rushed, and there were some problems. 3.2 was somewhat better, it had a bit more time to settle. Even though 3.4 mostly just added support for SqueakMap and retrofitted some enhancements from 3.3alpha, there were a few dozen bug fixes made during the 3.4beta stage. Which doesn't necessarily mean that much, but I think 3.4 did get more time for fixes and settling down than 3.0 did, and probably has fewer largish bugs. How it compares to 3.2... maybe about the same, maybe not quite as good, I'm not sure.
If we think that 3.4 is roughly on par with other Squeak releases quality-wise, I would tend to just have 3.5 allow enough time for package removals, enhancements, etc., in a more typical release timeline. Whether that's 3, 4 or 6 months, I'm not sure. Some Squeak releases have had 12 months between them, I'm sure we don't want it to be that long. :-)
But if we think we really need a higher-quality release before the image breakup begins, then perhaps a shorter fixes-only release is worth considering.
(I guess I'm leaning toward not bothering with the fixes-only release, but I'm still on the fence.)
- Doug Way
On Sunday, March 2, 2003, at 06:27 PM, Daniel Vainsencher wrote:
Simon, the reason I very much am waiting to hear Doug on this topic, and speaking about 1 month releases should be very tentative, is that none of us has Actually Done It. Doug might know how much the price of a release is, and how much it might be reduced, and whether he has time for it/someone else can do it in reasonable time, and those'll be the prime considerations in deterimining how often it will happen.
Even doing only a short first release (without setting a fixed rythm yet), as I propose, depends on these parameters.
Daniel
Simon Michael simon@joyful.com wrote:
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. _______________________________________________ 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
On Tue, 4 Mar 2003, Doug Way wrote:
Hmm. Having gone through the process (well, at least most of it), I suppose a one-month release might be barely workable if the goal was limited to fixes only as you say. One problem has been coordinating things via email (such as new VM releases, getting problems fixed), but I suppose these things get better when people know what to expect after the first time through.
On a personal note I'll just mention that making a VM release takes me an entire day (while I recompile on four different machines and construct more than a dozen seperate archives, _very_ slowly and methodically to make sure I don't mess anything up too badly). I wouldn't want to do this every single month. (Consider the 3.4gamma1 release as an exception.) Every quarter might be acceptable.
I realise that the VMs change much more slowly than the image itself and new VM releases are only really be needed when something in the VM related code (or the plugins) changes. OTOH, it would be slightly confusing if the latest VMs had lower version numbers than the latest stable images (pretty much consistently, modulo the occasionaly four-week period when the versions coincide after a VM-related change).
I think the whole regular release cycle is a bad idea anyway. Even with the current infrequent big releases I tend to lag behind the stable image by a version or two, since there's just not enough incentive to change until something is _obviously_ better (or new and exciting) in the latest image. My most recent image change was from 2.3 to 2.8. If releases were more frequent then deltas would be smaller and I'd be even less likely to notice new stuff or improvements and hence track the latest image. I'm probably not alone in thinking/working this way.
Just my 2 centimes of a Euro worth.
Ian
On Tue, 2003-03-04 at 08:18, Ian Piumarta wrote:
On a personal note I'll just mention that making a VM release takes me an entire day (while I recompile on four different machines and construct more than a dozen seperate archives, _very_ slowly and methodically to make sure I don't mess anything up too badly). I wouldn't want to do this every single month. (Consider the 3.4gamma1 release as an exception.) Every quarter might be acceptable.
When I worked at OpenLink software, we managed around 20 ports (lots of Unices, Mac, Win, VMS) and build weekly releases - so I have a bit of experience in automating this :-). Is there somewhere I can help in automating? Could we parallelize this by having four people doing the job on one machine?
I do agree that the VM release number should state the same as the image release number. Of course, if nothing changed, a simple patch might work ;-).
I think the whole regular release cycle is a bad idea anyway. Even with the current infrequent big releases I tend to lag behind the stable image by a version or two, since there's just not enough incentive to change until something is _obviously_ better (or new and exciting) in the latest image. My most recent image change was from 2.3 to 2.8. If releases were more frequent then deltas would be smaller and I'd be even less likely to notice new stuff or improvements and hence track the latest image. I'm probably not alone in thinking/working this way.
YMMV, etcetera. You're probably not alone, but you're probably not a majority either. However, since the upcoming releases most likely will concentrate on picking stuff apart and making it harder to get a decent Squeak distro, your, err, 'faction' will probably grow a bit ;-).
(making it harder, that is, until we master packaging etcetera - one of the main reasons to go through short release cycles IMO, because it will help us (force us) create a smooth process for building and releasing various images - 'core', the 'fat' image we now have, and anything else people want to pick up).
squeakfoundation@lists.squeakfoundation.org