[Sugar-devel] Sugar 0.84 and 9.1 sync (was] [ANNOUNCE] Sucrose 0.84 Feature Freeze)

[Greg Smith]

Hi Morgan and Simon,

Thanks for the replies.

However, I'm not sure if Morgan's is the definitive answer.

For now I'll assume that when tested on the XO we want people to file 
bugs in dev.laptop.org. Let me know if the consensus or decision on that 
changes.

I understand that most people wont make the Wed. 2PM US ET 9.1 meeting. 
Same time next week too. I'll be there so anyone is welcome.  If I can 
get Ed I'll call it a quorum.

Have a great holiday.

Thanks,

Greg S

Simon Schampijer wrote:
> Morgan Collett wrote:
>> On Mon, Dec 22, 2008 at 19:14, Greg Smith <gregsmitholpc at gmail.com> 
>> wrote:
>>> Hi Simon,
>>>
>>> On this:
>>>  > 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.
>>>
>>> I don't know how we will separate bugs only relevant to XO from the
>>> rest. Can you give me some examples or criteria?
>>>
>>> Another option is to file everything Sugar related in your Trac and then
>>> people can push them back if they are deemed XO specific.
>>
>> In my opinion, this is the reverse of what we planned for: File the
>> bug on the tracker relevant to the system you are testing. For
>> example, if someone finds a bug in Sugar on Ubuntu, the process is to
>> file a bug in the Ubuntu bug tracker. The team that does the Sugar
>> packaging on Ubuntu then check if it is Ubuntu-specific, and if not,
>> they refile it upstream and watch that bug report. When they see it is
>> fixed upstream, they then get that fix and (if possible) apply it to
>> the appropriate Ubuntu package. The same process would apply for Sugar
>> on Debian, Sugar on Fedora, etc.
>>
>> Since OLPC is effectively another distribution, I think it makes the
>> most sense to do the same - namely, file bugs in dev.laptop.org as a
>> result of finding them in an OLPC build. If they are XO-specific
>> issues, they can usually be fixed by whoever is going to look after
>> the OLPC packaging of Sugar (on Fedora's OLPC-4 branch). If they are
>> relevant to all distributions, they can then be refiled in the Sugar
>> Labs bug tracker. The bug would probably be fixed in a future sucrose
>> release, say 0.83.3 for example. When it gets closed in the Sugar Labs
>> bug tracker, the OLPC packager can then get that release into a
>> joyride or release stream build, and when OLPC QA signs off on it,
>> close the dev.laptop.org bug.
>>
>>> Are you going to copy all Sugar bugs from dev.laptop.org to your trac 
>>> db?
>>
>> I'd recommend that old bugs should be left on dev.laptop.org unless we
>> have a good reason to refile them on dev.sugarlabs.org. There are a
>> lot of them and we have valuable history there, including date filed
>> and all the comments.
>>
>> I don't see how they can be auto-imported into dev.sugarlabs.org -
>> certainly we don't know which are OLPC-specific without looking at
>> each one.
>>
>>> We should get the timing of that right so we don't update bugs in the
>>> wrong place and lose info.
>>
>> If we do refile them, they will still exist on dev.laptop.org, and the
>> Sugar Labs bug would represent the work necessary upstream in Sugar to
>> fix the problem, and the OLPC bug would represent the work to get that
>> into an OLPC build and QA it.
>>
>>> From a project management perspective, Sugar would be more like other
>> 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.
> 
> Published yes, but they have not been linked. In the beginning we 
> probably need another meeting to discuss triage policy and similar (the 
> meeting will happen in the new year since too many people are 
> unavailable those days). After that we want to do weekly triage meetings.
> 
> Best,
>    Simon
> 
> http://sugarlabs.org/go/BugSquad/Meetings/Minutes
>