Re: [IAEP] Announce: OLPC software strategy.
On 12 July 2010 19:27, James Cameron qu...@laptop.org wrote: I'm still unconvinced that this is worth changing, given the additional work that it will cause. I'd like to hear from the heavy users of trac, in particular Chris (cjb), Daniel (dsd), and Paul (pgf). I think our current system made sense temporarily at the time it was introduced, but now we should switch to what Martin is suggesting, which in my experience is how the rest of the universe works. It is also the approach used previously by OLPC when there was a larger engineering team, and worked well (though trac in general was the subject of continuous refinement, of course). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
why would you want to know what tickets were closed as part of work toward a particular release? Let me give an answer from the user's perspective (I'm seconding what Martin's response said): Consider build 800 versus build 802. Suppose I as an user had a problem on build 767 which prevented me from accomplishing a task. If that task was important to me, I would have liked to know if build 800 would already let me perform that task, or if I had to wait for build 802. Release notes list significant bugs fixed - but not all the bugs fixed. If build 800 had a different version number from build 802 (I forget if that was actually the case), I should be able to look up the ticket and see in which version that fix got released to users. In this regard, sometimes a developer marks a ticket as fixed as soon as he delivers a commit. But that ticket status does not help the user - not until that fix gets incorporated into a build which gets into the user's hands. I think that a problem ticket closed as 'fixed' should identify the particular release where the fix was made available. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On 13 July 2010 06:17, Daniel Drake d...@laptop.org wrote: On 12 July 2010 19:27, James Cameron qu...@laptop.org wrote: I'm still unconvinced that this is worth changing, given the additional work that it will cause. I'd like to hear from the heavy users of trac, in particular Chris (cjb), Daniel (dsd), and Paul (pgf). I think our current system made sense temporarily at the time it was introduced, but now we should switch to what Martin is suggesting, which in my experience is how the rest of the universe works. It is also the approach used previously by OLPC when there was a larger engineering team, and worked well (though trac in general was the subject of continuous refinement, of course). Thinking more, I think the changes are simple: Rename 1.5-software-final to 10.1.0 Rename 1.5-software-update to 10.1.1 Rename 1.0-software-update to 10.1.2 (a handful of tickets will need reshuffling, but not many) In my opinion, our process is already somewhat similar to what Martin is describing. Our trac milestones don't fully describe the changes of each release but they at least do a very good job of describing our intentions and the important things we're working on, and improving the accuracy is something we can step towards improving. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Sun, Jul 11, 2010 at 10:08 PM, James Cameron qu...@laptop.org wrote: You're asking me to rejustify decisions made in November 2009 when the environment was somewhat different. I understand the situation was weird in Nov 2009. But that's behind us, and I'd say we got to make good use of the tools we have... We had informal unpublished plans to release but we had no release name chosen. That's fine, we can always use a tentative milestone name. The change I made months ago was to facilitate testers and bug reporters ... to increase the data quality by removing the version numbers from a popup list, and encouraging use of the keywords field. ... The naming scheme was chosen because people had been logging tickets using the milestone as a version field. Hmm, I understood the *other* reasons, but I don't buy that one. Of course, users should use the 'version' field for that. But they cannot possibly use the milestone field (if milestones are well managed) because they cannot be running something that has not been released yet :-) Trac allows any use of the milestone field; And guns can be aimed in various directions. Sure. in software project management one does not always map a milestone to a release name. Conflating the two was causing confusion. Of course. But reusing the same milestone name is recipe for confusion. I wanted to be rid of the old milestone values too, but the argument against that was that the old data was harmless and occasionally useful. NO. Please, not kidding, I really mean this: It is a key usage of trac (and any other useful bugtracker) to query for the 'changelog' as tasks/bugs closed in release X'. Yes, the written release notes are nicer, but they gloss over a ton of things. Key question: How do we query 'tickets closed in 10.1.0'? How about in 10.1.1? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Mon, Jul 12, 2010 at 09:59:58AM -0400, Martin Langhoff wrote: Key question: How do we query 'tickets closed in 10.1.0'? How about in 10.1.1? Can't. Not even if milestones were release version names. When tickets are closed we do not capture a meaningful closed as part of work toward release x. You appear to be hoping for a query without any process to create the data to query on. Question back at you; why would you want to know what tickets were closed as part of work toward a particular release? -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Mon, Jul 12, 2010 at 5:37 PM, James Cameron qu...@laptop.org wrote: Question back at you; why would you want to know what tickets were closed as part of work toward a particular release? I regularly 'datamine' the SCM repos and bug/task-trackers of the components I use. This is enormously important when making decisions downstream. [ As a result of this, and some other factors, I was one of the earliest adopters and hackers of git. ] This kind of datamining is key when you are downstream, and your cost of updating to the new release is high -- because you have customisations, you want to perform your own QA, or because you have a large number of machines in the field (say, 360K) -- and you know each update will break (in real and/or subjective ways) for some users. Imagine you are a downstream on 10.1.x wondering whether 10.1.z is worth the (high) cost. If/when we release something like a 10.2.x / 11.1.0 (say, based on F-13, a big delta with more potential for grief); when you are downstream your questions are: - Does it fix problems / add enhancements I care about? [ This breaks down into are we monitoring any of those tasks? and can I spot anything there that I am interested in?. - What areas are affected / have been worked on? (Where should I focus my QA?) - What patches will I have to rebase / features to rework? It is a very hard, multi-dimensional cost-benefit analysis. Yes, you can diff the rpm changelogs, but that is shipping lots of trees to someone who wants a postcard of a forest. This is an important use of trac. Of course the data in trac is not perfect, but it can give us (with current practices -- plus the change I suggest) a very-close-to-correct picture of what's been worked on, and considered 'done' for a given release. And I don't see any downside to the change I suggest. Maybe I am a bit shortsighted here, but I've seen similar practice in various projects with no ill effects. Some projects do have a fuzzy future release milestone, as well as the next one, and initially tag all tasks (except urgent bugfixes) for the FR milestone. Then when it's clear that a particular task will get done in the next release (because it is a blocker/high pri, or is close to completion), they change the milestone to the actual release/milestone it will land on. So they get the benefit of both our 'fuzzy future, no specific promise' and the 'task/bug accounting'. It would be a mix of explicitly using 'Future release', most of the time, and explicit release names (10.1.2) as we are nearing the release and stuff lands. Would something like that work? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
I'm still unconvinced that this is worth changing, given the additional work that it will cause. I'd like to hear from the heavy users of trac, in particular Chris (cjb), Daniel (dsd), and Paul (pgf). -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
It may be worth looking at http://trac.edgewall.org/roadmap for how the trac team itself uses it. In particular, if you check the Show completed milestones box, and then on some old milestone (like, say, http://trac.edgewall.org/milestone/0.11.3 ) you can drill down into any component and see what bug fixes it contained. FWIW, at litl we use two fixed milestones for Future (stuff we're likely to do in the next release or two) and Far Future (stuff we'd really like to do, but admit isn't going to happen any time soon). At the beginning of each release cycle, we mine the Future and Far Future milestones for stuff we expect to include in our next release, and then close/move those bugs as the release approaches. (We don't use trac, but the methodology is similar.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Thu, Jul 8, 2010 at 00:01, Chris Ball c...@laptop.org wrote: Hi, Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the Known Problems section of the 10.1.1 release notes¹ into the 10.1.2 release. XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM and Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in action here⁴. It's an exciting time for software development at OLPC. Many thanks for all of your support and efforts! Congratulations on the excellent work done to date by you all and on the sound (and well
Re: [IAEP] Announce: OLPC software strategy.
On Thu, 2010-07-08 at 11:02 +0200, Tomeu Vizoso wrote: Congratulations on the excellent work done to date by you all and on the sound (and well communicated) plan. I couldn't agree more. On top of this, interaction between OLPC, the Fedora community and the Sugar Labs community has been fantastically smooth and productive. (this is just my own perception, of course. As always, suggestions to improve our collaboration processes are very welcome). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Announce: OLPC software strategy.
On Wed, Jul 7, 2010 at 3:01 PM, Chris Ball c...@laptop.org wrote: Hi, Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the Known Problems section of the 10.1.1 release notes¹ into the 10.1.2 release. XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM and Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in action here⁴. It's an exciting time for software development at OLPC. Many thanks for all of your support and efforts! - Chris, on behalf of the OLPC Engineering team. Footnotes: ¹:
