Hi,
Disclaimer: these are speculation & personal opinions from somebody
not involved with the MTF development!
ext Sean Kelley wrote:
There needs to be a separation between Nokia Device development and the
libmeegotouch framework development. At this stage it is tightly
coupled with Nokia's own handset development.
I would assume that coupling to continue until the first Nokia product
with it is released. If somebody knows better, please comment.
Going forward this is not
sustainable if we would like to gain traction in the greater community
both commercial and open. There is nothing wrong with device developers
having a separate internal and private issue tracker. But seeing as how
Nokia device developers are sharing sensitive information with
libmeegotouch development internally, there is clearly a lack of a
firewall separating the framework development.
Nokia is currently the one with most MTF applications & testing which
provides the fast feedback loop on issues that applications developers
are encountering when using it.
I.e. I think in this MTF "maturization" period there's some benefit
of this tighter coupling.
Anybody wanting to effect the direction and changes sees the code &
changes and can do API review, report issues etc and that would be very
much appreciated by the MTF team, I have no doubt about that.
In a nutshell, MTF needs to be a part of Qt with all the implications of
more separate governance.
<http://labs.qt.nokia.com/2010/06/03/qt-and-open-governance/>
I would also assume something like that to happen later on, but I guess
it also depends on the Symbian side developments to some extent.
If meegotouch is merged to Qt, it probably means API changes...
ext Michael Leibowitz wrote:
> On Fri, 2010-09-24 at 06:21 -0700, Eero Tamminen wrote:
>> And how do you differentiate which of the bugs are specific for
>> Harmattan[1] and which are for MeeGo? I think currently more of
>> the Nokia (MeegoTouch) development & testing effort happens for
>> Harmattan than MeeGo and I doubt MeeGo people would be very happy
>> if MeeGo bug tracker would be flooded by a huge amount of bugs that
>> may be specific to Harmattan and nobody's tested how much they
>> apply to MeeGo releases...
>
> The flip side, is that I don't know why things were changed in the
> library that we use for MeeGo components.
Changes in underlying libraries (like Qt), issues application developers
are reporting, performance & memory usage... Currently MTF is unstable
(v0.x, not yet used in any available product), so rate of change is
higher.
> I don't see any MeeGo bugs[1] fixed in the ChangeLog.
> Are MeeGo bugs duped by NB bugs that I don't know about?
Is there a bug master like on Maemo who takes care of synching
the issues?
> How does one make a decision to upgrade to the new version?
If you have issues that need fixing (and you've reported them[1]) or
your code builds with the new version without issues[2], why you would
need to specifically decide this?
[1] Also here with pointer to bug, if there's no response in
bug tracker...
[2] API changes are announced separately so you can separately
decide when to upgrade to new API version
> Do I have to read all the diffs?
That's never a bad idea. If you see something objectionable,
comment on the list. :-)
- Eero
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
