No subject

upstream software - like the Telepathy components for example.
Telepathy has its own bug tracker, although Telepathy bugs have been
also filed on dev.laptop.org. New releases of telepathy-gabble and
telepathy-salut may contain fixes or improvements relevant to OLPC
and/or Sugar - they almost certainly will contain changes unrelated to
OLPC. Someone makes a judgement along the way about whether a
particular release of these is the best version to be shipped by OLPC.

When QA isn't done systematically, things do fall through the cracks:
Fedora 10 shipped with a version of telepathy-gabble which had a
regression in Tubes, the functionality for Sugar collaboration -
although it was not noticed when tested with Empathy, the
telepathy-based GNOME desktop Instant Messaging client.

> There are ~ 500 just under the Sugar component and there are several
> other relevant components, not to mention activities and bugs with a
> different component which also affect Sugar.
>
> I want the ability to track release blockers quickly (and hopefully some
> gradation of polish or important but not hard blockers). Let me know
> what the right way to do that is in your trac. It would really help if
> we can synch up with the tagging/Trac conventions in dev.laptop.org so
> we have one standard.

We do not need all of the OLPC trac conventions in the
dev.sugarlabs.org instance - many of the "Next Action" states are very
specific to OLPC's style of project management.

We should however find a way to agree on priorities, so that if
something is an OLPC blocker it gets appropriate priority in the Sugar
Labs bug tracker.

> We can chat about that on the next 9.1.0 meeting Wed.

You want to discuss bugs at 8pm (euro time) on Christmas Eve?

> Also, we should pick some quality criteria which helps ensure that this
> release is "more stable" than the last one. I can dig up a definition of
> that I wrote for 8.2, but I'm open to suggestions. Reliability and
> stability are critical concerns for our users.
>
> Can you pick a representative to sit in on XO bug triage meetings? We
> don't have a regular time chosen yet, but I expect we will go to daily
> bug triage at some point in January.
>
> Is there a Sugar 0.83/0.84 bug triage meeting which needs a regular XO
> representative?

http://sugarlabs.org/go/BugSquad/Meetings is the appropriate place to
watch. There is an embedded calendar, but I don't see scheduled
meetings on it yet. The most recent meeting
(http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17) was
supposed to discuss a regular time slot but the minutes haven't been
published yet (http://sugarlabs.org/go/BugSquad/Meetings/Minutes) so I
don't know what the outcome was.

Regards
Morgan

> Thanks,
>
> Greg S
>
> Simon Schampijer wrote:
>> Greg Smith wrote:
>>> Hi Simon,
>>>
>>> Thanks for the follow up! You are definitely welcome at every 9.1
>>> planning meeting as is everybody who is interested in working on the
>>> next major software release for the XO. Consider yourself personally
>>> invited :-)
>>
>> :)
>>
>>> I added a line to the 9.1.0 schedule to note 0.83 freeze. See:
>>> http://wiki.laptop.org/go/9.1.0_requirements#Schedule
>>
>> Great.
>>
>>> That schedule needs a lot of work which I hope we can track in our
>>> weekly meeting.
>>>
>>> On this:
>>>  > dev.laptop.org should have bugs that are only relevant to the OLPC
>>>  > platform in the future. Currently, I guess there are still some bugs
>>>  > that other distributions would profit as well
>>>
>>> I'm still not quite clear. Let me ask it this way. I want to list,
>>> triage, prioritize and track all the important bugs for XO Software
>>> Release 9.1.0. That includes the Sugar bugs. Which trac system do I
>>> use for that? Maybe both?
>>
>> En gros: So, bugs that are unique to the OLPC distribution should go
>> into OLPC trac. Other bugs should be filed upstream - in sugarlabs.org
>> trac. This has the advantage that other distribution are aware of this
>> as well and - more eyes watching, better chance it gets fixed.
>>
>> Then there are different ways of tracking. You could file a bug at olpc
>> trac and that then traces the changes of the upstream bug for example.
>> We discussed different ways it in our last BugSquad meeting
>> http://sugarlabs.org/go/BugSquad/Meetings/Minutes/2008-12-17. I am sure
>> we will figure out the details with mel in the upcoming weeks.
>>
>>> On release notes, features and this:
>>>  > Time left is short for this release. What we are currently working on
>>>  > can be seen in our development TODO list
>>>  > http://sugarlabs.org/go/DevelopmentTeam/TODO.
>>>
>>> Our QA needs to know what bugs and features will be in the release
>>> before the release is done in order to be able to test them in
>>> advance. If I understand correctly, you only post the feature list in
>>> the release notes after its final.
>>
>> We have 6 to stabilize weeks after feature freeze. I hope that this is a
>> decent amount of time to do the testing. By then, you know for sure what
>> features are exactly in. If you want to start testing before, you need
>> to take the information provided in the release announcements - those
>> list all the fixes that went in.
>>
>>> Where can I get a list of things that QA (volunteer or otherwise)
>>> should test before we finish?
>>
>> see above
>>
>>> Let me know if those questions are not clear or you need any more info.
>>
>>> BTW I'm not complaining. Your documentation is definitely getting
>>> better and I appreciate the work everyone is doing. I'm just trying to
>>> work out the details so we can make another quality release.
>>
>> Sure, please keep asking.
>>
>> Best,
>>    Simon
>>
>>> Thanks,
>>>
>>> Greg S
>>>
>>> PS - Should this thread be on the OLPC devel list? Can you post your
>>> Sugar announcements stuff to that list? That way I can reply there and
>>> try to conform to Tomeu's list usage strictures.
>>>
>>> (kidding about "strictures" T-man, I'm just trying to do the right
>>> thing :-)
>>>
>>> Simon Schampijer wrote:
>>>> Greg Smith wrote:
>>>>> Hi Simon,
>>>>>
>>>>> I looked at the schedule. Its helpful but I'm not sure I fully
>>>>> understand all the milestones.
>>>>>
>>>>> What is the definition of "final release"?
>>>>
>>>> This is the golden image. It is the last coordinated release. After
>>>> that we only deliver updates for components.
>>>>
>>>>> Once the feature set is frozen, how do I know what is in the release?
>>>>
>>>> Each release in the cycle has it's release page with the relevant
>>>> features and fixes for the specific release. After Feature Freeze we
>>>> might wrap up what big changes/features went in, in the announcement.
>>>>
>>>> Is
>>>>> that the list of Trac IDs in 0.83.1 release notes?
>>>>
>>>> Would be the sum of the releases in the cycle before the feature freeze.
>>>>
>>>> (btw the bug ID URLs
>>>>> on that page link to the wrong Trac system).
>>>>
>>>> Fixed.
>>>>
>>>>> Also, are all XO relevant bugs tracked in the OLPC Trac bug system:
>>>>> (dev.laptop.org)?
>>>>
>>>> dev.laptop.org should have bugs that are only relevant to the OLPC
>>>> platform in the future. Currently, I guess there are still some bugs
>>>> that other distributions would profit as well.
>>>>
>>>>> Are you joining our weekly 9.1.0 meeting (Wed. at 2PM US ET IRC on
>>>>> freenode.net #olpc-meeting)?
>>>>
>>>> I take this as an invitation - and will try :)
>>>>
>>>>> I don't have it on the schedule for this week but I think we should
>>>>> put a "synch up with Sugar schedule" discussion on the agenda ASAP.
>>>>
>>>> Time left is short for this release. What we are currently working on
>>>> can be seen in our development TODO list
>>>> http://sugarlabs.org/go/DevelopmentTeam/TODO.
>>>>
>>>>> Stability is a top priority for XO users. The only way I know of to
>>>>> improve stability is lots of testing time and focus on bug fixes. We
>>>>> need to get that scheduled soon if we want a new sugar release in XO
>>>>> Software Release 9.1.0 in March.
>>>>
>>>> That is why we set the feature freeze in mid January - that we have 6
>>>> weeks left to stabilize. By January I hope to have the BugSquad [1]
>>>> then in place to handle all the incoming bug reports from testing.
>>>>
>>>>> My impression is that we made a big step forward on improving
>>>>> stability in 8.2.0. I hope we can do it again.
>>>>
>>>> Sure :)
>>>>
>>>>> Thanks,
>>>>>
>>>>> Greg S
>>>>>
>>>>
>>>> Best,
>>>>    Simon
>>>>
>>>> [1] http://sugarlabs.org/go/BugSquad
>>>>
>>>>
>>>
>>
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>