[maemo-developers] Unsatisfied with bugs.maemo.org

[From: Eero Tamminen]

Hi,

ext Till Harbaum / Lists wrote:
> sorry, but i don't get your point. You say that you'd need tests and things
> for the themeing and thus you don't do it at all? You mean it's acceptible
> to not theme them at all and have them look ugly but it's not acceptible
> to give them a quick/untested themeing? Why?

To theme something, there needs to be something on which it can be
tested.  You cannot have a theme for something that doesn't exist
on the device (from a graphics artist point of view).

UI & graphics design is something that starts much earlier than SW
development and it moves to future releases much earlier than
the SW develoment / bugfixing.  By the time there's a public release
and public bugs based on it, I don't think there's anymore anybody
allocated to do graphics work for that particular release.


> You basically say "either we do things perfectly or we do them in
> the worse possible way".

UI designers aren't clairvoyant.  They don't know what specific thing
community will want to have been themed few years later.

Bugs for previous releases could of course be used as input for this
(still needs a test SW though!), but they don't always exist or be
appropriate and I don't think that has really been done for graphics
like it was done for SW and some UI issues. So, we should improve here.

With Fremantle we've started providing regular pre-releases so that
things like this can be tested by the community before the release,
when there's still time to do also feature requests & non-critical
fixes for that release.

(With the pre-releases you won't see final graphics, but at least it can
be tested whether some widget is lacking themeing.)


> I'd say:
> If you don't support that feature, then remove it entirely from the libs 

That would be making them deliberately API & ABI incompatible which
would kind of make moot the point of using open source components.
So, no.


> and from the api docs. But distributing a library containing stuff you just 
> won't support is pretty odd.

But I think it would be appropriate to note in API documents which
widgets aren't supported by our UI guidelines / with themeing.

Can you make a bug about that so that can be fixed for Fremantle
(or Harmattan) API docs?


> You could avoid a lot of internal testing if you'd actually make use of
> the fact that bugs.maemo.org gives you a bunch of external testers.
> Actually that's what happening here: You provide a library containing
> functionality that is incomplete and untested.  And the community did 
> the testing for you and now tells you that what you deliver is incomplete.

For graphics the testing needs to happen way before public release
of the device.  Unfortunately before Fremantle that wasn't possible.


> And what do you mean by wanting this to be a community project?
> Is there an easy way the community can replace nokia provided core
> libraries and theme files?  Or do you suggest people should switch to mer
> if they are unsatisfied with some half-hearted nokia implementation? 

As the bug is wontfix for Diablo, obviously the only alternative for
Diablo is something done by the community.  Maybe a new theme based
on the default themes on which the app requiring it depends on?
Gil, does our theme license allows derivatives?

For Fremantle and later releases, community can provide information
and working test-cases (applications) for what additional
widgets/features should be themed.


> You say you only fix those features that are actually a problem 
> for your own product and you don't care  for widgets that are "only" 
> used by third party applications. Are you serious? Nokia really isn't interested
> in supporting third party apps?

I was saying that UI designers and graphics artists can fix only
problems that they know about, and only if they get to know about
them when they still have time to do something about that.  Which
in case of theme graphics unfortunately is way before the product
is released.


 > Support is only provided if there's also
 > a benefit for nokias own applications? Wow ...

You can test whether something works, only if you have something
that you can test it with.  Should be obvious. :-)


	- Eero

PS. It was really annoying/frustrating (not only for 3rd parties,
but Nokia developers too) that in earlier products we didn't have 
regular pre-releases which mean that by the time people were able
to test the software and file bugs about it, there wasn't anymore
much that could be done about it e.g. feature-wise.  Things are
much better now with Fremantle.


> Till
> 
> Am Freitag 05 Juni 2009 schrieb Eero Tamminen:
>> Bug 4630 & 1504 are about themeing a single Gtk widget aspect.
>>
>> There are many other Gtk widgets and icons which aren't (at least fully)
>> themed although they otherwise work fine.  This is because it would
>> require (internally):
>> * UI specifications about these widget features and their themeing
>> * Themeing these things (gtkrc & graphics) for all themes according
>>    to the specification
>> * Writing test programs for these features
>>    (as they're not used by the product itself)
>> * Regular testing that the widget features and themeing work
>>    (in all themes) according to the specification
>>
>> Which is quite a lot of extra work for things that aren't used at all
>> in the product itself.  So, it's not done.
>>
>> If the community wants the extra widgets / widget features and icons to
>> be themed because they actually have some program(s) that use them, I
>> think its better to handle that as a community project...?
>>
>>
>>>> Why is there a bug reporting system if so many bugs end up with WONTFIX? This
>>>> doesn't make much sense to me.
>>> Again, don't kill the messenger.
>>>
>>> Maemo 5 bug handling has been already a lot more efficient than in
>>> previous versions, thanks to people reproducing old bugs in the
>>> Fremantle pre-releases. We expect the good responsiveness to be kept
>>> once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting
>>> the fixes out in new updates.
>>>
>>> What we have is a bag of bugs still open affecting mostly Diablo.
>>> Because of many reasons those bugs were not handled in time or there
>>> were no resources to fix them at the time.
>> The main reason was that we didn't have regular pre-releases of the
>> software before Fremantle.
>>
>> The situation of what happens after the official release, is similar as
>> with the other Linux Distros, once e.g. Ubuntu releases a new version of
>> its distribution, implementing feature bugs and minor bug fixes happen
>> to  the next release having new features (currently Fremantle on Maemo),
>> the old release will get only bugfixes to security and other critical
>> issues and eventually even those stop.  Ubuntu does new releases at
>> fixed 6 months schedule and the bugfixes to them stop for them pretty
>> quickly except for the LTS releases.
>>
>> Our schedule differs (much) more. Also, we don't currently provide LTS
>> releases (partly because Nokia business model is different, we sell
>> products whereas most other Linux distros basically sell services).
>> Unlike Ubuntu we have a few bugfix releases (like e.g. Debian has)
>> because our releases happen at longer intervals.
>>
>> Because of the more radical HW platform differencies between the device
>> targets of the Maemo SW releases, we cannot (at least currently) offer
>> as good backwards HW compatibility support as can be done on x86.  This
>> is something that we need to work with the community (and is currently
>> being done e.g. in context of Mer).
>>
>>
>>> Now we are cleaning those
>>> bugs week after week and yes, this brings lots of WONTFIX among those
>>> that are not an issue anymore in Fremantle. It's more a consequence of a
>>> past problem than a reflection of a current problem, though.
>>
>> 	- Eero
>>
> 
> 
>