Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

3.6 release timing (was Re: Shrinking alpha image)
by Daniel Vainsencher 23 Mar '03

23 Mar '03

[Cross posting moves threads, cycle >~4 mo] Sure. [Sm 1.1 in Squeak 3.6, me or someone as release content prognosticator] If someone does want the job, they're welcome to it. As for me - Goran, I haven't had as much time/inclination to help with SM as I thought I might, but let me know if you need testing/someone to play XP customer, or any other specific kind of help. I wouldn't say that 1.1 will or even should be in 3.6, but I'd be damn happy to help it get there! :-) [3.6 harvesting to start soon] Sure. I'll be looking at the recent posts of removal scripts and reviewing them, so we can start putting some shrinking into the image. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > goran.hultgren(a)bluefish.se wrote: > > > > (crossposting, well - it seemed good) > > (Yeah, occasional crossposting is probably unavoidable. Perhaps we should > only crosspost when we want to shift discussion from squeak-dev over to the > SqF list (and maybe vice versa). Then all follow-ups should only be posted to > the newly added list, as I'm doing here. For example, squeak-dev can still be > a place where planning-related discussions will often happen (since it's a > free-for-all), but in more of a brainstorming phase, and to get as much input > as possible from the community. But then when final decisions need to be > made, the discussions should happen here on the SqF list.) > > > As I see it the plan Doug has laid out seems fine. I mean, we aren't > > really maintaining two images - we are maintaining the smaller one and > > making sure that the "full script" works. > > > > BUT... may I suggest that we set up a goal for 3.6 that SM1.1 is reached > > before release? Otherwise this "full script" will have problems, since > > it can't refer to specific versions of packages. > > Sounds like a good idea. I was guessing that SM1.1 would be out relatively > soon (within 1-2 months?) Making it a requirement for 3.6 could give you an > extra incentive. ;-) > > > And btw, who of us guides should be in charge of making sure that we pin > > down the list of planned things for 3.6? I have seen numerous posts on > > this subject but someone needs to collect these into a "big list" that > > we can condense somewhere and come up with "The Grand 3.6 Plan". In > > short - who should be the "Release Boss" for 3.6? :-) > > > > And the gist of that plan should of course be summarized on this page: > > http://swiki.squeakfoundation.org/squeakfoundation/79 > > > > Daniel? Tim? Ned? Craig? > > > > Personally I would like to keep my focus at you-know-what and Doug has > > already taken on enough IMHO. > > Right. Although I am sort of the "Release Master" or "Implementor", meaning > the guy in charge of moving the release from alpha->beta->gamma->final, and > making sure it happens reasonably on schedule. But yeah, someone else should > probably be in charge of pinning down the release "content". > > > I think Daniel would make a greate Release Boss... :-) > > I might nominate Daniel also, partly because he's posted on the topic in the > past, and his current role as guide of "image detanglement" is somewhat > nebulous and is partly covered by Ned's and Craig's roles anyway. But if he > doesn't want to do it and someone else does, that would be fine, too. > > On a related note: As the release implementor (or scheduler or whatever the > best term is), I'd like us to come to a decision on when we want to release > 3.6. > > The last few Squeak releases have typically had 6-12 months in between each > release. I'm pretty sure that most of us agree 12 months is too long. There > were some suggestions on squeak-dev of having six months between releases, or > having them every three months (quarterly), along with some nonsense about > having them once per month. ;-) My initial thoughts were to have them every 4 > or 6 months. > > Another alternative is to not have a regular schedule, but to just come up > with a list of features we'd like to see in the next release, and then put out > the release whenever it gets done. But I liked Daniel's argument about having > the release timing be a higher priority than the content. That way, people > can depend on new features coming out on a regular basis, and we won't have > releases that drag on for a year. If some features on the to-do list aren't > finished by the time we're scheduled to move to beta, they get put off until > the next release. (Of course, we'd try to make sure the most important > features got worked on right at the beginning of the alpha cycle, so at least > they would be finished. In a dire situation, we could postpone a release, but > the general rule would be that the timing is more important than the content.) > > Assuming we go with a regular schedule, I would propose having them every 4 > months. This was about how often the releases happened up until 2.8, I > think. Having them every 6 months would work too, but I like the idea of > moving things along a little bit faster. Having them every 3 months feels too > fast to me, though... my release duties would happen at a more hurried pace > and might start to impinge on the "fun" aspect of being a guide. Also, that > might not allow enough time for a reasonable beta cycle along with a longish > alpha cycle. I'm guessing our beta cycle should be something like 5-6 weeks? > > And having releases every 4 months would make the tri-annual releases, which > brings up the "triad" again. :-) Anyway, I could be convinced to go slower > than this, but I don't think I'd want to go any faster. > > If we stick with the "First Fridays" release date, that would put the release > date of 3.6 on August 1st. > > We can then come up with a list of content that we think can reasonably get > done in that time. > > Thoughts on this? > > - Doug Way > > > p.s. Even before we decide on the content for 3.6, I think we could get > started on harvesting fixes for 3.6 right away. I'll send out another note > shortly about this... getting the harvesting rules nailed down so I know what > to do. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 3

Re: [Squeakfoundation]re: release process (was "Shrinking alpha image")
by danielv＠netvision.net.il 23 Mar '03

23 Mar '03

[Faster turn around needed, at least for small things] Yup, I agree. Doug Way <dway(a)riskmetrics.com> wrote: > > On Saturday, March 22, 2003, at 03:05 AM, Craig Latta wrote: > > >> A few questions it should answer - > >> * How do we know what the community will come up with beforehand? > > > > We don't need to read minds. We can just decide that features get > > *scheduled* before they get included. E.g., if you come up with some > > whizzy new feature during the 3.6 cycle, you can suggest it for a > > future > > feature schedule (3.7 or later). > > > > Of course there will be some deviation from the ideal. For example, > > critical fixes often get special dispensation (inclusion into the > > current schedule instead of waiting for a future schedule). In general, > > though, I think it's good to encourage planning the next several > > releases. In particular, at any given time there are usually large > > features (e.g., changing the format of compiled methods) that one can > > imagine happening in the next major release as opposed to the next > > minor > > release. > > This sounds generally good. > > The only tweak I would make is that the number of items which get > "special dispensation" (inclusion into the current schedule) could be > fairly large, as long as they are small fixes/enhancements without > major ramifications. This would include both critical and minor fixes > harvested from the sqfixes page, and also minor enhancements. (During > the alpha stage of course.) We want to have a reasonably quick > turnaround on these smaller items; postponing them to the next release > as a general rule would be too long. > > As an example, I can imagine that several dozen bugfixes may go into > 3.6 without being in the plan. A bugfix with major ramifications > (which is arguably more than just a "bugfix") should be part of a > scheduled plan, though. > > Perhaps one way to address this is to just have "miscellaneous bug > fixing" or similar as part of each plan/schedule. Eh, that's sort of > cheesy. ;-) Although there may be times when we want to include in our > plan that we want to hold off on minor fixes/enhancements for a couple > of weeks before some massive change is made, for example. > > Another thing that we can do is, when reviewing items on sqfixes, if a > submission seems like too large/widespread a change for inclusion in > the current schedule, we can add a comment/opinion stating that it > needs to be discussed further on this list and should be part of a plan > for a future release. > > - Doug Way > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

RE: [Squeakfoundation]updating to next version after declining alpha
by danielv＠netvision.net.il 23 Mar '03

23 Mar '03

How about this combination - 1. By default we don't put in "final updates" that will cause compatibility problems. 2. When we put out alpha, someone can create a small SM package that changes versions specifically from m.n to m.n+1. Installing it will allow people to continue updating, but warn that there's a small chance the updates will be incompatible, so save your image first. Should solve 95% of these issues. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Doug, > > Three notes on this. First of all, the rollover message has some rather > scary implications. It implies that you _will_ receive "test pilot" updates > when you advance your system to alpha vs. that you _may_ receive final fixes > if you choose the other way. I would suggest to change this towards > something indicating that if you go into a final branch you're really > entering a dead end versus going onto alpha you _may_ update your system to > the next version at a point of your choosing. Note the subtle difference ;-) > > Secondly, it should be pretty straightforward to flip from a final branch > over to the next alpha - after all, all that's needed is setting the system > version right. A simple thing that could be done is to install a "next > version identifier" which contains the next future version a system could be > advanced to. If you choose to, then all that happens is that you are set to > the next update branch. This would allow people to stay with (for example) > 3.5 until 3.6 is finalized, then switch to 3.6 (at which point the next > future version is 3.6alpha) and update through everything (during which > there may be other future versions such as beta and gamma). When you receive > one of these advance messages choosing the "dead end" would just install the > next future (perhaps this is a better way of distinguishing the streams - a > "live" and a "dead" one; with the dead one only containing retrofitted stuff > from the live one). > > Also, concerning feeding back fixes into "final" branches I think that a > Very Useful rule of thumb should be that any fix going into final should be > resiliant to updating through the point at which it appears in the next > future version (testing this is almost trivial). For 95% of the fixes this > will be the case anyway. For the remaining 5% an explicit warning in the > update that "installing this update/fix will remove your ability to advance > to X.Y" might be appropriate. If the above mechanism would exist, the update > could simply reset the next future version. > > BTW, this entire thing is an issue I am quite interested in myself. With the > rapid releases you are aiming at it's a real pain in the neck to jump > versions. I was going to switch Croquet to 3.4 but now you're talking about > finalizing 3.5 already so I'm going to wait for this. Unless, of course, > there's going to be a 3.6 a month after that in which case I might wait for > it ;-) > > Cheers, > - Andreas > > > > > -----Original Message----- > > From: squeakfoundation-bounces(a)lists.squeakfoundation.org > > [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] > > On Behalf Of Doug Way > > Sent: Saturday, March 22, 2003 2:51 AM > > To: Discussing the Squeak Foundation > > Subject: Re: [Squeakfoundation]updating to next version after > > declining alpha > > > > > > > > On Friday, March 21, 2003, at 05:39 PM, Joshua 'Schwa' Gargus wrote: > > > > > Still, I don't like the idea of 3.5 final possibly being a short > > > dead-end branch, especially when it is not made clear to users that > > > this is the case (a newbie would have no way of knowing that loading > > > updates to 3.5 after the branch to 3.6 might make it impossible to > > > later update to 3.6). At the least, the rollover message could > > > warn that to accept further 3.5 updates voids the guarantee that > > > a later update to 3.5 will work fine. > > > > I could improve the rollover message next time to include that. (I > > assume you meant "a later update to 3.6 will work fine" above.) > > > > Actually, the current message sort of implies that anyway, it > > says that > > you will only be allowed to receive final fixes for the 3.5 > > release, if > > you choose not to advance to the next alpha. Here's the > > 3.5beta split > > message: > > > > "Do you wish to advance to version 3.6alpha? > > [Yes] Your system will be marked as 3.6alpha, and you will > > subsequently receive ''test pilot'' updates for 3.6. > > [No] Your system will be marked as 3.5beta, allowing you > > to receive only final fixes for the 3.5 release." > > > > I could add it to something like "Your system will be marked as > > 3.5beta, allowing you to receive only final fixes for the 3.5 > > release. > > You won't have a further opportunity to update to 3.6alpha." > > > > Or, technically it should be "You may not have a further > > opportunity..." because in some cases, if no changes go into the beta > > for whatever reason, we can add another opportunity to advance when > > going to gamma. This happened with 3.4beta->3.4gamma/3.5alpha. > > > > Anyway, I'm not going to spend a lot of time thinking about whether > > there's a better solution to this, because I can't imagine one right > > now that's not a lot of effort. :-) Perhaps sometime in the > > future if > > we have a generic uninstall capability. > > > > - Doug Way > > > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

re: Shrinking alpha image
by Daniel Vainsencher 23 Mar '03

23 Mar '03

As a good friend of mine once said, a contradiction implies anything you want. If you have an operational model of how we get to where you propose we should be, go ahead. A few questions it should answer - * How do we know what the community will come up with beforehand? * How do we get everyone to actually test and document everything? * How do we avoid being such pests that nobody actually wants to submit anything? I think the first is a mirage, and the second and third are reasonably addressed by QA tags -if we stick to them and accept nothing that doesn't have them-. Daniel Craig Latta <craig.latta(a)netjam.org> wrote: > > Hi Daniel-- > > > Let me explain how little is too much - when we posted 3.5a, and > > released it with two fixes that people asked for, that was probably too > > much. Yes, I know I was one of the people for it, but consider this > > consequence - 3.5 is in beta, soon in gamma. Have we heard one voice on > > any squeak list saying "gee guys this actually works"? not that I > > noticed. > > > > It's already in. The advocates for it have "won". If there's a screw up > > (for example, it clashses with another recent change), we'll find it > > when we're into 3.6. If we don't actually test releases, there's no > > point in having release cycles at all... > > Whoever does the testing... > > - You can't call it alpha until you know what changes you plan to have. > - You can't call it beta until all those changes are represented. > - You can't call it gamma until all those changes have been tested. > > I think adhering to that would help a lot. Of course, to be verifiable, > it would require rather more documentation than we do now. I think it'd > be worthwhile, though (and not terribly onerous if each change's > implementor took responsibility for testing and documenting that they'd > done so). > > > -C > > -- > Craig Latta > http://netjam.org/resume > craig(a)netjam.org > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Re: [Squeakfoundation]updating to next version after declining alpha
by Daniel Vainsencher 22 Mar '03

22 Mar '03

Hmm, do you have any ideas on how we can do this? it seems to me that two ideas here are in conflict - 1. "I should get backported fixes into 3.5 that worked in 3.6, without moving into 3.6 while it's alpha" 2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all" You can do either one of those manually now, by simply proceeding up only one of the upgrade paths, but I don't have ideas on how you can have both. On another note, some people might ask "why do you keep important stuff in your image anyway?" Daniel Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> wrote: > I originally posted this to squeak-dev, but it probably should have > been sent here. > > > ----- Forwarded message from Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> ----- > > Date: Wed, 19 Mar 2003 21:59:18 -0500 > From: "Joshua 'Schwa' Gargus" <schwa(a)cc.gatech.edu> > Reply-To: The general-purpose Squeak developers list > <squeak-dev(a)lists.squeakfoundation.org> > To: Squeak Mailing List <squeak-dev(a)lists.squeakfoundation.org> > Subject: updating to next version after declining alpha > User-Agent: Mutt/1.2.5.1i > Delivered-To: mailman-squeak-dev(a)lists.squeakfoundation.org > List-Id: The general-purpose Squeak developers list > <squeak-dev.lists.squeakfoundation.org> > List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, > <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=unsubscribe> > List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-dev> > List-Post: <mailto:squeak-dev@lists.squeakfoundation.org> > List-Help: <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=help> > List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, > <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=subscribe> > Errors-To: squeak-dev-bounces(a)lists.squeakfoundation.org > > I have a comment about Squeak version releases that may or may not > have been discussed already. My concern relates to beginning a new > alpha branch before the previous version is finalized. This happens > every time, and I think that it is unavoidable. > > I currently have a 3.5 beta "living" image where I keep a lot of > important information. I don't want to advance it to 3.6 alpha > because I can't afford to mess it up. So, I chose to only receive > the final fixes for the 3.5 release. However, some day 3.6 will > be stable enough to switch to. My problem involves the uncertainty > about being able to successfully update from a 3.5 final release > (which may include updates after the choice about whether to go > 3.5 or 3.6). > > Can we manage the update streams in such a way that we can be certain > that such updates are possible? In most cases, it probably works fine > on its own. However, I think that it is important for users to be > able to rely on this invariant. > > Comments? > > Joshua > > ----- End forwarded message ----- > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

5 5

Re: [Squeakfoundation]updating to next version after declining alpha
by Daniel Vainsencher 22 Mar '03

22 Mar '03

Have you tried exporting importing when moving from a 3.5 final to a initial 3.6alpha? it's very improbable that the final changes would include changes that make your morphs incompatible, compared to exporting importing across wider version gulfs. Otherwise, I do sympathize with your claim in principle, but as long as we don't put absolute limits on what final changes might include (no do-its, no shape changes, just method definitions, nothing that didn't get into version n.m+1), I don't see how the problem can be avoided. Proposals welcome. Daniel Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> wrote: > On Fri, Mar 21, 2003 at 09:00:19PM +0300, Daniel Vainsencher wrote: > > Hmm, do you have any ideas on how we can do this? it seems to me that > > two ideas here are in conflict - > > 1. "I should get backported fixes into 3.5 that worked in 3.6, without > > moving into 3.6 while it's alpha" > > 2. "When 3.6 becomes gamma, I should be able to upgrade 3.5 after all" > > Right. I don't see that there necessarily a conflict, at least > conceptually; for instance, Debian lets you do these kind of things. > However, you are probably right that there is a conflict once we > examine things from the point of view of Squeak update streams and > changesets. > > > > > You can do either one of those manually now, by simply proceeding up > > only one of the upgrade paths, but I don't have ideas on how you can > > have both. > > Hmm, I need to introduce some terminology. Call "base 3.5/6" the state > of the image right after the version is advanced, but before any further > updates are loaded. Call "current 3.5/6" the state of the image with > all of the updates currently available in the appropriate update stream > loaded. > > Most of the time, when backported fixes get added to current 3.5, you'll > be lucky and things won't break if you update with all of the changes > up to current 3.6. However, sometimes they will, but you should be > able to notice this by testing. > > Backported fixes could be tested by filing in the fix to a current 3.5 > and then updating it to current 3.6. If it breaks, then we could figure > out why, and either fix it so that it would be smooth sailing to 3.6, or > decided that it's not worth the effort. New 3.6 changesets could be > tested to ensure that they work with a current 3.6, and a 3.5 updated > to current 3.6. > > This would admittedly be more work for those in charge of the update > streams, probably too much I thought about only allowing updates from > a final 3.5, so the 3.6 update stream only had to be tested against a > final 3.5 and a base 3.6, but this wouldn't work if some earlier 3.5 > changeset caused problems that precluded later updating, since that > changeset couldn't retroactively be removed from the update stream. I > guess the best option would be to just not load any final updates to > 3.5. > > Still, I don't like the idea of 3.5 final possibly being a short > dead-end branch, especially when it is not made clear to users that > this is the case (a newbie would have no way of knowing that loading > updates to 3.5 after the branch to 3.6 might make it impossible to > later update to 3.6). At the least, the rollover message could > warn that to accept further 3.5 updates voids the guarantee that > a later update to 3.5 will work fine. > > > On another note, some people might ask "why do you keep important stuff > > in your image anyway?" > > Because the important stuff consists of morphs. Where else would I keep them, > and still have them handy to modify? I haven't had perfect luck in the past > with exporting and re-importing morphs between different versions of Squeak, > and it would be a lot of extra hassle keeping track of all the exported files. > > Joshua > > > > > Daniel > > > > Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> wrote: > > > I originally posted this to squeak-dev, but it probably should have > > > been sent here. > > > > > > > > > ----- Forwarded message from Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> ----- > > > > > > Date: Wed, 19 Mar 2003 21:59:18 -0500 > > > From: "Joshua 'Schwa' Gargus" <schwa(a)cc.gatech.edu> > > > Reply-To: The general-purpose Squeak developers list > > > <squeak-dev(a)lists.squeakfoundation.org> > > > To: Squeak Mailing List <squeak-dev(a)lists.squeakfoundation.org> > > > Subject: updating to next version after declining alpha > > > User-Agent: Mutt/1.2.5.1i > > > Delivered-To: mailman-squeak-dev(a)lists.squeakfoundation.org > > > List-Id: The general-purpose Squeak developers list > > > <squeak-dev.lists.squeakfoundation.org> > > > List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, > > > <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=unsubscribe> > > > List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeak-dev> > > > List-Post: <mailto:squeak-dev@lists.squeakfoundation.org> > > > List-Help: <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=help> > > > List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeak-dev>, > > > <mailto:squeak-dev-request@lists.squeakfoundation.org?subject=subscribe> > > > Errors-To: squeak-dev-bounces(a)lists.squeakfoundation.org > > > > > > I have a comment about Squeak version releases that may or may not > > > have been discussed already. My concern relates to beginning a new > > > alpha branch before the previous version is finalized. This happens > > > every time, and I think that it is unavoidable. > > > > > > I currently have a 3.5 beta "living" image where I keep a lot of > > > important information. I don't want to advance it to 3.6 alpha > > > because I can't afford to mess it up. So, I chose to only receive > > > the final fixes for the 3.5 release. However, some day 3.6 will > > > be stable enough to switch to. My problem involves the uncertainty > > > about being able to successfully update from a 3.5 final release > > > (which may include updates after the choice about whether to go > > > 3.5 or 3.6). > > > > > > Can we manage the update streams in such a way that we can be certain > > > that such updates are possible? In most cases, it probably works fine > > > on its own. However, I think that it is important for users to be > > > able to rely on this invariant. > > > > > > Comments? > > > > > > Joshua > > > > > > ----- End forwarded message ----- > > > _______________________________________________ > > > Squeakfoundation mailing list > > > Squeakfoundation(a)lists.squeakfoundation.org > > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

re: Decision time: Are SCG the steward ofthekernel as proposed?
by Daniel Vainsencher 21 Mar '03

21 Mar '03

Distributing the decision making is something I care about as much as you do. However, we need to be careful of oversimplifying ideas that will keep us from making progress. I think this applies in two ways to our process. 1. Distributing decision making doesn't have to be an all or nothing proposition. 2. An artifact and it's set of policies, to remain viable over time need to be coherent. This does (IMO) preclude a number of different groups each pulling in their own direction. The weaker version of this argument, which I'll be far less hesitant about defending, is that making a *product release* at a specific date, precludes a number of groups each with commitment power. To avoid going all theoretical, I'll note that Linus does distribute a lot of the decision making in Linux kernel development, but still, nobody puts anything into his tree without his say so. BTW, the infrastructures and the communities and the their leaders are very different, but I think this much does apply to us too. And in our specific case, you don't see me telling KCP or MCP *what* to do. They both control that aspect. I do give guidance on what will make their work easier to accept into the mainstream, and mostly in terms of process, not content. If they decide to make radical changes, they'll have to convince people it's worthy, and provide an upgrade path we can support, but I won't tell them "no" a priori. Daniel goran.hultgren(a)bluefish.se wrote: > Craig Latta <craig.latta(a)netjam.org> wrote: > > > > Daniel writes: > > > > > To add another reason againt a vote on this (not that I care very > > > strongly): I didn't see a need for it because I think we can send the > > > right message without providing an official moment of decision - > > > after all, people do take their risks whatever we might decide, even > > > officially. > > > > > > If SCG fubars it, we won't merge their stuff. If they bring us good > > > patches (the much more likely outcome), we'll merge them whether they > > > have any "officially decided" status or not. Just remember this - > > > once we've made decisions on a topic, we'll always be making > > > decisions on that topic (paraphrasing Frank Herbert, in one of the > > > Dune books). IMHO, giving advice is worth doing permanently, giving > > > official badges isn't. > > > > I agree with this, and it's why I abstained. (By the way, Göran, when > > one abstains, it's called an "abstention".) > > Not to start another fruitless discussion (but that is probably exactly > what I am doing), but I thought the idea of having someone as a Steward > for a piece of Squeak was that the Steward had the "final saying" on > that piece. You know, delegated responsibility. Otherwise the point of > having Stewards seems a bit... moot. > > That is also why the "trust" part is important. Of course, we could say > NO, but that would probably essentially mean that we lost that Steward. > And hopefully before that the arguments pro and con had time to boil > down to something good. But having us say NO should be a very, very > uncommon thing. > > It still feels like the Steward should take the decisions - I mean, why > should people otherwise be interested in being Stewards if it still > means that everything needs to be crosschecked with us? The idea is to > *distribute* the responsibilities but if no power of decisions comes > with those responsibilities then the incentive of becoming a Steward is > lost. IMHO. > > Well, perhaps I have missed something here. > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to get to the triad)
by Daniel Vainsencher 21 Mar '03

21 Mar '03

I'll tell you what I think is worth doing, which is what I intend to do - - Play an XP "customer" for anyone that wants to do something that I think is important. By this I mean trying to find the "business value" of different features in what they're doing, and helping to clarify what's important. Where my added value is as someone in the "business" of making Squeak better, not too technically involved in any specific solution. - Occaisonally start discussions about those larger, harder to integrate pieces of work, like network rewrites, compiler changes and so forth. Again, representing the position of how do we make Squeak better, without getting into a mess. - Raising awareness - both by summerizing what's been discussed, and by following up on things that happen. I don't think these roles are very coupled - we can definitely share in them. Daniel goran.hultgren(a)bluefish.se wrote: > Doug Way <dway(a)riskmetrics.com> wrote: > > Well, I think the general idea is that, for each release, we want to > > come up with a "release plan" containing a small handful of items which > > we predict will be included in that release. Maybe we don't exactly > > need a "release boss" for this. Maybe a discussion moderator. Or not. > > Well, I want a person. Obviously I struck the wrong chord by writing > "Release Boss" but I simply meant someone that moderates the discussion > and makes sure we get the general plan straight. > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to get to the triad)
by Daniel Vainsencher 21 Mar '03

21 Mar '03

[Tests are already failing, is it relevant to harvesting?] No. Solutions are harvested, not problems. BUT - tests are supposed to be relevant earlier in the process - to what people work on, and submit fixes for, and claim is [su] compliant. But to help with that, the tests have to be more visible. [Testing server would add visibility and help us USE our measures] I agree. I think such a server would be a great opportunity. Note that one you have the technology of a server that brings up images, configures them, and runs tests, you can also use it to do many other things: - SLint reports on the image, or other metrics - running graphs of results over updates. Anyway, something that would be able to just: - Get a latest image - Load updates - load test packages - run them - email results to list Would be great. I think a first iteration could be in the form of an SM package, that once loaded, performs the rest of the process. It could be platform specific and use OSProcess to start the other image. The first release needn't even be completely automatic - it could helps automate this process for a person that runs it manually every week, and adds comments on the results. This would already make the tests much more visible. Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > Another Question is what to do about failing Testcases... the baseimage > testing package allready accumulated 16(!) failing tests. > > Will this be of any relevance to the release process? > > Somehow I have the impression that a central testing server would help > a lot: If we'd get an email every week (or even day), we would have > much more pressure to actually harvest the existing bugfixes. > > > Marcus > > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to get to the triad)
by Daniel Vainsencher 21 Mar '03

21 Mar '03

I've said before that I think a "release boss" is either something we can't have, or a misnomer. Raising awareness of projects that people are starting already is just fine, but IMO, we can't, and shouldn't, do much more. Let me explain how little is too much - when we posted 3.5a, and released it with two fixes that people asked for, that was probably too much. Yes, I know I was one of the people for it, but consider this consequence - 3.5 is in beta, soon in gamma. Have we heard one voice on any squeak list saying "gee guys this actually works"? not that I noticed. It's already in. The advocates for it have "won". If there's a screw up (for example, it clashses with another recent change), we'll find it when we're into 3.6. If we don't actually test releases, there's no point in having release cycles at all - it just generates fruitless discussion. We could for that matter just stop every 300 updates or 3 months and call it a release, and the name would be worthless. I think the solution is a strict "if you want it, you test it" policy. Bug fixes don't go into the image unless they're externally tested and so forth. Heck, adding code that's very broken is much healthier (in alpha phase) - at least it's likely to bug enough people that they'll make sure it gets fixed (at least while avoiding the "it's so central/complex nobody can fix it" syndrome of 3.3 modules). Generally, I think we can have either a real policy (fixed standards), or a real leadership (human voice telling people what direction to go), not both. Since more people in the community already want to pull a specific direction, than want to apply specific standards, I think our policies and actions as Guides should complement by focusing on setting standards. If we need to help specific directions materialize, it is more by giving direct, quick feedback and help to people that want to do them, than by proclaiming it should be done. That might just be a bias on my part talking, but it'll definitely color what I'm going to focus on. Daniel Ned Konz <ned(a)bike-nomad.com> wrote: > On Thursday 20 March 2003 12:36 am, goran.hultgren(a)bluefish.se wrote: > > And btw, who of us guides should be in charge of making sure that > > we pin down the list of planned things for 3.6? I have seen > > numerous posts on this subject but someone needs to collect these > > into a "big list" that we can condense somewhere and come up with > > "The Grand 3.6 Plan". In short - who should be the "Release Boss" > > for 3.6? :-) > > > > And the gist of that plan should of course be summarized on this > > page: http://swiki.squeakfoundation.org/squeakfoundation/79 > > I've started this process by putting some things on the Swiki. > -- > Ned Konz > http://bike-nomad.com > GPG key ID: BEEA7EFE > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation March 2003