Re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
Hi Scott, Good catch. We did talk about the question of marking bugs. Sorry I missed that in my notes. I think it was agreed that we talk about those in the weekly software status meeting. Also, that bugs which are considered blockers should have the keyword: blocks:8.2.0 This is documented along with the current agreement on bug tagging in general on the Trac home page: http://dev.laptop.org/ conventions section. My thinking is that new features and functionality are tracked via: http://dev.laptop.org/report/18 Problems with existing features which don't work as they did in previous releases or don't work according to documentation are flagged as critical items for resolution by keyword: blocks:8.2.0 Let me know if you that plan doesn't work for you. Thanks, Greg S C. Scott Ananian wrote: On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith [EMAIL PROTECTED] wrote: We talked about what this page offers that we don't already have. The conclusion was that its a high level view of the main features in the release. Each item on this page should include a list of relevant bug id that give the next level of granularity. Greg asked if this is too much process and no one said it was, definitively. I also expressed concern that this view of the process doesn't include an explicit means for tracking blocking bugs and regressions. I think the idea was generally accepted that a feature-driven list like this is most useful early in the release cycle and at decision times when decisions to cut features have to be made, but that later in the process features are expected to be done and the most important release driver is blocking bugs. (Now switching back to expressing personal opinion:) For the moment, I'm personally concerned with how close are we right now to release which (to me) means, how many blocking bugs and regressions are left in joyride. Taking the extreme view, I don't care how many features are complete in it -- I'm perfectly willing to cut some features if that's the shortest path to fixing a bug and getting most of the features out on time. (Unfortunately, many of our current blocking bugs are caused by big already-landed features in a way that would be more work to back out the feature as it is to simply fix the bug.) Maybe I'm premature in switching to a blocker-oriented view, but I certainly want to ensure that we don't lose sight of the big bugs as we congratulate ourselves on landing or partially-landing features. IMO we made the feature view decisions several weeks ago, when we (among other things) committed to basing 8.2 on F9. Now that we've done so, the blocker view deserves to be foregrounded to drive the bugs out. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
Hi All, Marco, Greg, Kim, Joe, Paul, Eben, Chris, Scott, Jim, Denis, Michael and others people met on Tuesday July 1 at 2PM US ET via IRC, phone and in person. Sorry for the long e-mail but it was a very productive meeting and I want to keep everyone in the loop. Agenda is at: http://lists.laptop.org/pipermail/devel/2008-June/015961.html Here are a few basic notes and a list of action items. Notes: Lesson learned: Don't hold a meeting via phone and IRC at the same time. Choose one, preferably IRC if you want the broadest audience. We opened the meeting mostly in person and on the phone then moved to IRC when we realized we couldn't do both simultaneously. The first part talked about What is Release 8.2.0. Worked from the definition at: http://wiki.laptop.org/go/8.2.0 We talked agreed its a time based release and talked about what that means (it goes when it reaches the right quality regardless of what features are in). Further definition at: http://wiki.laptop.org/go/Release_Process_Home#Time-based_Releases We talked about target customers, features and the definition of support. We agreed that the goal is to get it to G1G1 if its available in time. Then we started walking through the Release Contracts page: http://dev.laptop.org/report/18 AKA Target Feature Set Including Status page linked from: http://wiki.laptop.org/go/8.2.0 We agreed that the relationship between the release contract and the roadmap is fuzzy. One is what we wanted originally: http://dev.laptop.org/milestone/8.2.0%20(was%20Update.2) the other is what we plan to do: http://dev.laptop.org/report/18 Its not 100% clear how they map top each other and that needs to be explained better. Focusing on the Target Feature Set Including Status page we covered a definition of what is a release contract. Paraphrasing, its an understanding between Michael and a developer that they can and will deliver a feature in time for the release. Target Feature Set Including Status page (http://dev.laptop.org/report/18) lists everything which has a chance to make the release. We agreed that if you want to get something else on that page you should e-mail Michael the details. We talked about what this page offers that we don't already have. The conclusion was that its a high level view of the main features in the release. Each item on this page should include a list of relevant bug id that give the next level of granularity. Greg asked if this is too much process and no one said it was, definitively. Greg also got agreement that each item on the Target Feature Set Including Status page needs a link to some documentation saying what the item includes. Consumers of this feature description are developers to comment on design, QA to write test cases, and product management to share with the plan with users. It can be a link to an existing web page (e.g. new Sugar UI). Greg noted that we do not have much time to redesign the items listed so design changes on them may be deferred at the discretion of the feature owner. The meeting mostly to IRC at this point and a discussion of where we are in the process and what freeze means. There was reference to the new release process: http://wiki.laptop.org/go/Release_Process_Home and to other process draft pages. Kim tried to drive consensus on how know what in this list will actually make the release: http://dev.laptop.org/report/18 There was discussion of the need to build a release candidate ASAP just to see where we are. and other in draft processes and a picture: http://teach.laptop.org/~mstone/d5.svg Also a lot of discussion of how to pick a candidate build, when to pick one, how to build one and other good engineering details. The result was encapsulated in two action items below. I pasted all the IRC info I captured here: http://wiki.laptop.org/go/8.2.0#Paste_of_part_of_IRC_Status_Meeting_Held_on_July_1 I missed much of it :-( Anyone else who has a log please post it. Aside from the communication challenges. It was a great meeting from my perspective. Thanks everyone! When I say we agreed above it means that the people in the meeting agreed. If you feel otherwise its never too late to speak up. Any feedback, comments, complaints, issues, edits, revisions of the notes or other input gratefully accepted, as always. * Action item - Joe to help create and send out for review the release criteria by July 14. - Kim will list all relevant builds in the 8.2.0 wiki page (http://wiki.laptop.org/go/8.2.0). - Kim will write a definition of support including the meaning of backward compatibility in http://wiki.laptop.org/go/8.2.0 - Greg will improve of workflow of the web pages by July 15 - Kim will check with Peru and Greg will check with Uruguay teams to ensure that they do not plan to upgrade to 8.2.0. Action item due by July 20. - Greg will check Kim's whiteboard for list of future customers and check if they are going to use the
Re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith [EMAIL PROTECTED] wrote: We talked about what this page offers that we don't already have. The conclusion was that its a high level view of the main features in the release. Each item on this page should include a list of relevant bug id that give the next level of granularity. Greg asked if this is too much process and no one said it was, definitively. I also expressed concern that this view of the process doesn't include an explicit means for tracking blocking bugs and regressions. I think the idea was generally accepted that a feature-driven list like this is most useful early in the release cycle and at decision times when decisions to cut features have to be made, but that later in the process features are expected to be done and the most important release driver is blocking bugs. (Now switching back to expressing personal opinion:) For the moment, I'm personally concerned with how close are we right now to release which (to me) means, how many blocking bugs and regressions are left in joyride. Taking the extreme view, I don't care how many features are complete in it -- I'm perfectly willing to cut some features if that's the shortest path to fixing a bug and getting most of the features out on time. (Unfortunately, many of our current blocking bugs are caused by big already-landed features in a way that would be more work to back out the feature as it is to simply fix the bug.) Maybe I'm premature in switching to a blocker-oriented view, but I certainly want to ensure that we don't lose sight of the big bugs as we congratulate ourselves on landing or partially-landing features. IMO we made the feature view decisions several weeks ago, when we (among other things) committed to basing 8.2 on F9. Now that we've done so, the blocker view deserves to be foregrounded to drive the bugs out. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith [EMAIL PROTECTED] wrote: - Kim will check with Peru and Greg will check with Uruguay teams to ensure that they do not plan to upgrade to 8.2.0. Action item due by July 20. Why don't we want them to use 8.2? I suspect some words were left out, and what you really meant was, their schedules for adopting 8.2 are not pressing? If we don't expect our two largest deployments to adopt our release, why are we making it? Something's not right here. Incidentally, on the blocking bug front, I notice that Uruguay's wireless problems with 703/708 were nowhere to be found on the roadmap for 8.2. This is a blocker to our producing something useful for the kids. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes
My thoughts in-line... Kim On Tue, Jul 1, 2008 at 6:16 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith [EMAIL PROTECTED] wrote: - Kim will check with Peru and Greg will check with Uruguay teams to ensure that they do not plan to upgrade to 8.2.0. Action item due by July 20. Why don't we want them to use 8.2? Two reasons for Peru to stay with 8.1: 1 - Peru has 'blessed' their build for the next 75k laptops and we got it into production for them. It is 703+peru activities (which you knew, but may not have thought about the reason we ECO'd it into production was so they don't have to upgrade before giving them out to students). 2 - Peru has created and printed their User Manuals based on the UI of 8.1. We should expect and encourage them to continue on this path. We will support 8.1 until we ship 9.1, which should work for them. That's that part that I will confirm when I visit them. Greg has agreed to check in with Uruguay on where they are in their roll out to teachers and students. I suspect some words were left out, and what you really meant was, their schedules for adopting 8.2 are not pressing? If we don't expect our two largest deployments to adopt our release, why are we making it? KQ - We have many, many more deployments, trials, pilots, possibly G1G1, who will be just getting their laptops when 8.2 is ready or soon there after. This release is for them. Even in the case of G1G1, if those laptops go out with 8.1.1, they can MUCH more easily be upgraded to 8.2 than was possible with earlier releases. Something's not right here. Incidentally, on the blocking bug front, I notice that Uruguay's wireless problems with 703/708 were nowhere to be found on the roadmap for 8.2. This is a blocker to our producing something useful for the kids. KQ - Do you have a specific bug in mind? Let's make sure it gets listed when we start listing/triaging blocking bugs (which I agree we can start doing at any time); and make sure it is getting addressed. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
