[MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
eero.tamminen at nokia.com
Fri Sep 24 02:51:03 PDT 2010
<my own opinions of course>
Tamminen Eero (Nokia-MS/Helsinki) wrote:
> Dandrada Daniel (Nokia-MS/Helsinki) wrote:
>> As for your last question, the answer is probably "yes". That makes me
>> wonder if it makes sense to announce fixes for Nokia bug reports in such
>> a wide distribution (MeeGo) list since only people with access to
>> projects.maemo.org bugzilla can see the corresponding bug reports.
> There's a short (automatically generated) bug description associated
> with these bug numbers and I would hope commit messages to list these
> bug numbers too so that you can see what actually was changed although
> you don't see the bug report details.
Quick comment on the stuff raised in the bug about MTF bugs openess:
Why internal bugtrackers must die:
1. I have to follow too many bugtracker instances, but I only want to
follow *one*. Then, I configure this *one* instance to support *my*
workflow. It is unreasonable to expect developers to waste even more
time with bugtrackers, which means: bugs.meego.com will *not* get much
more attention from the actual developers. Not now, and not in the
2. Worse: bug fragementation. The same bug is discussed on different
trackers! Also, I cannot as easily add dependencies/blockers.
Each bugzilla instance is a considerable resource investment
(from a developer pooint of view), with vastly dimishing returns.
1) Nokia developers have to track the internal bug tracker anyway.
(With this argument you're actually saying they shouldn't participate
in public one...)
2) Although libraries & frameworks are open, many/most of the internal
Nokia applications built on top MTF are proprietary like on Maemo.
They're not available publicly before the device(s) come out and
therefore their bugs aren't public either. Therefore their bugs on
MTF need for dependency reasons to be on internal bug tracker.
And there are _a lot_ more of them than the bugs on public one.
There's nothing preventing you from filing what ever bugs you think
need to be reported for the publicly available code and setting
dependencies on them.
I've participated on this stuff in the bugs.maemo.org and I don't see
this as major obstacle because reported public bugs are so few compared
to what we handle internally. It just needs a "bug master" like on
Maemo who makes sure that appropriate triaging is done, keeps these
two things in sync as needed and prods internal people when needed.
The main issue with bugs.maemo.org bug handling was that the internally
fixed issues weren't immediately available publicly in some unstable
testing repo, they came only with the infrequent larger public Maemo
releases. If that's not an issue in MeeGo or everybody's fine at this
stage with compiling stuff themselves, this should IMHO be fine.
While I agree that having two bug trackers is bad, use of internal bug
tracker is unavoidable until devices with rest of the SW using MTF are
available. Even after those are out, there will still be two bug
trackers for the same reasons (future devices etc) although
(hopefully) much larger part of bugs are handled in the open.
(Note: I'm not involved in MTF development.)
More information about the MeeGo-touch-dev