Hi,
After the recent chat between Alexander Lazarević and Chris Cunnington, I had a brief look at the Squeak wiki to see if I could find any checklist a release manager could use to orchestrate a new Squeak release. (This is fairly timeous, I reckon, given that 4.3's already over 6 months old.) I couldn't find anything. Where would one find such a list? (*) If there isn't one, we really ought to write one. If there isn't an automated "make a new tag on Mantis for the release" script we can at least have a "nag a Mantis admin to make a release" item. frank (*) No, I'm not volunteering for releasing 4.4! Sorry :/ |
On 7/16/12 6:59 AM, "Frank Shearar" <[hidden email]> wrote: > Hi, > > After the recent chat between Alexander Lazarević and Chris > Cunnington, I had a brief look at the Squeak wiki to see if I could > find any checklist a release manager could use to orchestrate a new > Squeak release. (This is fairly timeous, I reckon, given that 4.3's > already over 6 months old.) > > I couldn't find anything. Where would one find such a list? (*) If > there isn't one, we really ought to write one. If there isn't an > automated "make a new tag on Mantis for the release" script we can at > least have a "nag a Mantis admin to make a release" item. > > frank > > (*) No, I'm not volunteering for releasing 4.4! Sorry :/ Seems the job Ralph and me was unnoticed See http://wiki.squeak.org/squeak/5919 and several more related. Once we have a Release Team and for no good reasons we don't have one now. So Squeak is on comatose and few care about. Edgar |
On 16 July 2012 12:03, Edgar J. De Cleene <[hidden email]> wrote:
> > > > On 7/16/12 6:59 AM, "Frank Shearar" <[hidden email]> wrote: > >> Hi, >> >> After the recent chat between Alexander Lazarević and Chris >> Cunnington, I had a brief look at the Squeak wiki to see if I could >> find any checklist a release manager could use to orchestrate a new >> Squeak release. (This is fairly timeous, I reckon, given that 4.3's >> already over 6 months old.) >> >> I couldn't find anything. Where would one find such a list? (*) If >> there isn't one, we really ought to write one. If there isn't an >> automated "make a new tag on Mantis for the release" script we can at >> least have a "nag a Mantis admin to make a release" item. >> >> frank >> >> (*) No, I'm not volunteering for releasing 4.4! Sorry :/ > > Seems the job Ralph and me was unnoticed > > See http://wiki.squeak.org/squeak/5919 and several more related. > Once we have a Release Team and for no good reasons we don't have one now. Hi Edgar, I saw several such pages. Those tell me what went into 3.10, 4.3, etc. I'm not talking about those. I'm talking about a checklist that anyone can follow to produce/manage a new Squeak release. For example * Warn of a code freeze no later than 4 weeks before the due release date Pre-release planning and announcements * Ensure that all tests pass. Any failing tests that cannot be fixed marked as expected failures * and * so * on Release time * Add a new category to Mantis for the release * Prepare release notes, published to squeak-dev for comment. In the absence of comments, assume that the notes are fine. * Publish the artifacts to ___. Post-release cleanup * Unmark the expected failures marked earlier, so someone can actually fix them Also, of course we have a release team. We just don't have a _dedicated_ release team. And we shouldn't, for good reason: a dedicated release team is an excuse for everyone else to assume that the release team bears full responsibility for the process. frank > Edgar > > > |
On 7/16/12 8:10 AM, "Frank Shearar" <[hidden email]> wrote: > > Hi Edgar, > > I saw several such pages. Those tell me what went into 3.10, 4.3, etc. > I'm not talking about those. I'm talking about a checklist that anyone > can follow to produce/manage a new Squeak release. For example > * Warn of a code freeze no later than 4 weeks before the due release date > Pre-release planning and announcements > * Ensure that all tests pass. Any failing tests that cannot be fixed > marked as expected failures > * and > * so > * on > Release time > * Add a new category to Mantis for the release > * Prepare release notes, published to squeak-dev for comment. In the > absence of comments, assume that the notes are fine. > * Publish the artifacts to ___. > Post-release cleanup > * Unmark the expected failures marked earlier, so someone can actually fix > them > > Also, of course we have a release team. We just don't have a > _dedicated_ release team. And we shouldn't, for good reason: a > dedicated release team is an excuse for everyone else to assume that > the release team bears full responsibility for the process. > > frank All you said was the process followed... And a dedicated release team is not excuse for people wishing a better Squeak. Edgar |
On 16 July 2012 12:27, Edgar J. De Cleene <[hidden email]> wrote:
> > > > On 7/16/12 8:10 AM, "Frank Shearar" <[hidden email]> wrote: > >> >> Hi Edgar, >> >> I saw several such pages. Those tell me what went into 3.10, 4.3, etc. >> I'm not talking about those. I'm talking about a checklist that anyone >> can follow to produce/manage a new Squeak release. For example >> * Warn of a code freeze no later than 4 weeks before the due release date >> Pre-release planning and announcements >> * Ensure that all tests pass. Any failing tests that cannot be fixed >> marked as expected failures >> * and >> * so >> * on >> Release time >> * Add a new category to Mantis for the release >> * Prepare release notes, published to squeak-dev for comment. In the >> absence of comments, assume that the notes are fine. >> * Publish the artifacts to ___. >> Post-release cleanup >> * Unmark the expected failures marked earlier, so someone can actually fix >> them >> >> Also, of course we have a release team. We just don't have a >> _dedicated_ release team. And we shouldn't, for good reason: a >> dedicated release team is an excuse for everyone else to assume that >> the release team bears full responsibility for the process. >> >> frank > > All you said was the process followed... I think we're not talking about the same thing. I would like to see a checklist that a release team can follow. I don't know where I can find such a checklist. There might be one buried on the Swiki, but I couldn't find it. frank > And a dedicated release team is not excuse for people wishing a better > Squeak. > > Edgar > > > |
On Mon, Jul 16, 2012 at 12:40:34PM +0100, Frank Shearar wrote:
> > I think we're not talking about the same thing. I would like to see a > checklist that a release team can follow. I don't know where I can > find such a checklist. There might be one buried on the Swiki, but I > couldn't find it. I think you're right, and it is important to have this. IIRC the information is going to be in various emails on this list, and possibly also on the dedicated lists that were used in previous releases. If that information can be captured in the form of a checklist as you suggest, that will be very useful. Dave |
In reply to this post by Frank Shearar-3
> ... I had a brief look at the Squeak wiki to see if I could
> find any checklist a release manager could use to orchestrate a new > Squeak release. (This is fairly timeous, I reckon, given that 4.3's > already over 6 months old.) > > I couldn't find anything. Where would one find such a list? (*) If ... I made a page when I did the 4.2 release and encouraged everyone to participate. http://wiki.squeak.org/squeak/6160 There is also ReleaseBuilder which *should* provide the exact method to run against the last alpha which will configure and save it as the new final release. That is how I did 4.2. HTH, Chris |
On 19 July 2012 23:00, Chris Muller <[hidden email]> wrote:
>> ... I had a brief look at the Squeak wiki to see if I could >> find any checklist a release manager could use to orchestrate a new >> Squeak release. (This is fairly timeous, I reckon, given that 4.3's >> already over 6 months old.) >> >> I couldn't find anything. Where would one find such a list? (*) If ... > > I made a page when I did the 4.2 release and encouraged everyone to participate. > > http://wiki.squeak.org/squeak/6160 OK, so part of the general release process is finding out what's actually going to go into the release. I agree, that's important. I was mainly looking for documentation such that some victim^Wvolunteer could have a checklist that tells him/her exactly how to prepare and deploy a new release such that (a) the barrier to being a release manager is much lower and (b) we don't have accidental slips like not having a Mantis tag for the release. (ChrisC, I keep mentioning this not because it's a big deal - it's really not - but just because it's a nice simple example.) Having said that, we _should_ start a conversation around what will become Squeak 4.4. I'd like to see a greater emphasis on modularity, myself: if not having Environments in the base image now, then at least identifying the worst entanglements and working on cutting those. And tests. Tests, tests, tests. The tools especially need some kind of framework within which to test. A mock environment permitting one to test lovely things like #removeClass would be fantastic. (There are building blocks all over the place, but nothing assembled in the base image.) frank > There is also ReleaseBuilder which *should* provide the exact method > to run against the last alpha which will configure and save it as the > new final release. That is how I did 4.2. > > HTH, > Chris > |
Free forum by Nabble | Edit this page |