Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (3)
to General by Kalatti - 16 hrs, 14 mins ago - more...
 |
|
2009-01-05
, 13:04
|
|
Posts: 1,137 |
Thanked: 402 times |
Joined on Sep 2007
@ Catalunya
|
#12
|
Originally Posted by GeneralAntilles
Ok, to me it has been completely useless.
Generalizing isn't useful here.
Better now?
 |
|
2009-01-05
, 16:58
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#13
|
Originally Posted by luca
Not really, because now I think you're willfully ignoring the benefits you've received (if somewhat indirectly) from work done in the productive products of Bugzilla.
Ok, to me it has been completely useless.
Better now?
Unless you only use products which have poor track records in bugs.maemo.org (which is laughably unlikely), then you've benefitted from it and it's certainly not be useless to you.
__________________
Ryan Abel
Ryan Abel
 |
|
2009-01-05
, 17:40
|
|
Posts: 1,665 |
Thanked: 1,649 times |
Joined on Jun 2008
@ Praha, Czech Republic
|
#14
|
Originally Posted by igor
If you have something specific in mind that I can do (well, you know best about what is NOT possible currently, e.g. changing internal workflows) feel free to send me an email. And yes, I have an NDA in place. ;-)
I can only say that I wish there was a better integration with the internal bugzilla.
Originally Posted by igor
I fully understand this. The sooner the Fremantle Alphas and Betas get released the better this will become again.
Currently I can only ignore external bugs, but otoh maybe it's just because they can only be about stuff that is out of scope for the work ongoing: the lower layers of Fremantle have so little in common with their counterpart in Diablo that it's useless to even consider if a bug would still apply.
__________________
maemo.org Bugmaster
maemo.org Bugmaster
|
|
2009-01-05
, 17:49
|
|
Posts: 1,665 |
Thanked: 1,649 times |
Joined on Jun 2008
@ Praha, Czech Republic
|
#15
|
Originally Posted by igor
In the long run we must have exactly one bug tracking system. Suse e.g. have one bugtracker and use the "insider group" functionality in Bugzilla to have bug reports and/or comments/attachments only visible to employees if chosen, but they only deal with software.
And if the bug is assigned originally to component B, but then it is discovered to belong to component A, what happens to all the previous discussion? Does it get censored?
Having secret hardware information too makes this a much more complicated problem to solve. Fixing some upstream issue in Mozilla Bugzilla e.g. about being able to set the visiblity of specific fields (hardware info etc) might help.
Originally Posted by igor
Of course I got exactly the same problem here. Often being silent by non commenting. And a small number of my "I don't know" comments in the public Bugzilla are actually lies, thanks to the NDA.
Or, even worse, bug in component X, from a previous sw release is obsoleted by the fact that component X is going to be dropped/replaced but that is not public yet. What should we do?
__________________
maemo.org Bugmaster
maemo.org Bugmaster
|
|
2009-01-05
, 22:57
|
|
Posts: 1,137 |
Thanked: 402 times |
Joined on Sep 2007
@ Catalunya
|
#16
|
Originally Posted by GeneralAntilles
Why is it unlikely?
Unless you only use products which have poor track records in bugs.maemo.org (which is laughably unlikely), then you've benefitted from it and it's certainly not be useless to you.
Of the stock programs I only use microb, xterm and the rss reader.
The rss reader, I didn't bother to report/follow any bug (though it annoys me that it's endlessly loading images I didn't consider it worthwhile to file a bug), xterm I didn't feel the need to report any bug (it works well enough for me), and about microb (the application I use around 99% of the time) among the bugs I reported/followed I saw a grand total of 0 bugs fixed in diablo (I don't consider "fixed in fremantle" of any benefit to me).
 |
|
2009-01-05
, 23:05
|
|
Posts: 4,930 |
Thanked: 2,272 times |
Joined on Oct 2007
|
#17
|
Originally Posted by luca
Well, others have filed bugs in all of those. And some of them have been fixed, benefiting you.
Why is it unlikely?
Of the stock programs I only use microb, xterm and the rss reader.
The rss reader, I didn't bother to report/follow any bug (though it annoys me that it's endlessly loading images I didn't consider it worthwhile to file a bug), xterm I didn't feel the need to report any bug (it works well enough for me), and about microb (the application I use around 99% of the time) among the bugs I reported/followed I saw a grand total of 0 bugs fixed in diablo (I don't consider "fixed in fremantle" of any benefit to me).
__________________
World's first inductively-charged N900!
World's first inductively-charged N900!
| The Following 3 Users Say Thank You to Benson For This Useful Post: | ||
|
|
2009-01-05
, 23:31
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#18
|
Originally Posted by Benson
Any platform bugs, too, Maemo isn't just composed of applications.
Well, others have filed bugs in all of those. And some of them have been fixed, benefiting you.
__________________
Ryan Abel
Ryan Abel
| The Following 3 Users Say Thank You to GeneralAntilles For This Useful Post: | ||
 |
|
2009-01-09
, 17:22
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#19
|
Looking at these stats (thanks Andre!) I can only say that they are way better than anybody could have imagined exactly a year ago (thanks Bugsquad Team and many others for kicking the snowball!).
... and continuing. The long Fremantle release process will hopefully give us time to clean the bug database of dormant legacy. The current bugs will be tested against Fremantle and those relevant still not FIXED will be filed in the internal bugzilla against the Fremantle program, while still being in the development and bugfixing phases. Something that never had happened before.
(...)
Untill Harmattan the platform layers are getting many changes that contain new signals about hardware, technology selections and consumer features. This creates many frictions between open development and marketing/product management.
I wish (and I have moderate reasons to think) that once Harmattan is released the pace for open development will be simpler since the platform will be more consolidated and we hopefully will be able to disclose/launch new software features without the pressure of not unveiling features of the Device XXX to be launched. Like Symbian/S60 do nowadays, and I expect them to do even more going open source. Or like Qt did in the times of Trolltech and keeps doing in the times of Nokia.
The next stop of that train is open development for open source components, and this is the one where we need to focus now. I don't know if that train will ever lead to that single bugzilla but it's clear that without open development it doesn't even make sense.
Being in the product management team I know perfectly what you mean. Again, moving to open development is the best remedy for this, although not an automatic solution. The Fremanle pre-alpha release is a concrete step in the good direction and hopefully during the Fremantle release we can do a lot more progress solving those inconsistencies.
This is a quest that needs to be done team by team, area by area. Platform+OSS goes first. Applications+Closed perhaps never gets there.
... and continuing. The long Fremantle release process will hopefully give us time to clean the bug database of dormant legacy. The current bugs will be tested against Fremantle and those relevant still not FIXED will be filed in the internal bugzilla against the Fremantle program, while still being in the development and bugfixing phases. Something that never had happened before.
Originally Posted by igor
I also call this progress. More steps without any precedent in Maemo (and Nokia?) will be done before any device is launched. It's not easy to set these precedents but I think they are solid ones. This is why Harmattan still will get more unprecedented steps, probably.
Recently we have recieved permission to publish kernel code at a level that was not even imaginable before
but there are still certain areas - which i cannot mention for obvious reasons - that are still considered to be a marketing advantage and therefore cannot be published.
Or, even worse, bug in component X, from a previous sw release is obsoleted by the fact that component X is going to be dropped/replaced but that is not public yet. What should we do?
I wish (and I have moderate reasons to think) that once Harmattan is released the pace for open development will be simpler since the platform will be more consolidated and we hopefully will be able to disclose/launch new software features without the pressure of not unveiling features of the Device XXX to be launched. Like Symbian/S60 do nowadays, and I expect them to do even more going open source. Or like Qt did in the times of Trolltech and keeps doing in the times of Nokia.
From my point of view it would be much simpler if there was _one_ bugzilla system, open to everybody, where i could debate anything regardless of who might be seeing it.
But, coming to reality, I have already stated this several times internally, and the problem is that the people who enforce certain closedness are the same ones who also support the external bugzilla and ask developers for more partecipation.
Once we can speak freely about everything, we'll try to do it.
 |
|
2009-01-10
, 10:37
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#20
|
Originally Posted by qgil
The funny (not) thing here is that the development is already more open than bugzilla itself. At least for what concerns the kernel.
The next stop of that train is open development for open source components, and this is the one where we need to focus now. I don't know if that train will ever lead to that single bugzilla but it's clear that without open development it doesn't even make sense.
OTOH the info about the HW is closed.
Till the service point repair guide leaks to the internet.
So what would make sense, imho, would be to just open the bugs to the public once the HW is made public and for sales. This actually _would_ lead immediately to the one single bugzilla.
I see no reason why we couldn't do it, other than we are embarassed to show to outsiders our internal struggles in bouncing, squashing, reopening bugs.
Same goes with the publishing of the source code for the kernel. I think it would make much more sense to publish the entire set of git trees with all the history, than just the tarball with the latest source code.
Last edited by igor; 2009-01-10 at 10:39. Reason: Reworded the sentence about HW closedness
When I speak I tend to refer to my POV, which is quite low level respect to the whole Maemo stack and, being more tied to the HW, is also probably of less interest to the Maemo community, for what i have seen.
Maybe it would make more sense that the Bugzilla components for the Kernel and similar low level items are made available only once the device&related SW are actually out in the hands of the consumers.
Anyway, being these components more generic, our developers are more likely to interact in the proper discussion places, rather than in some Maemo related website.
The kernel is a good example for this.
Therefore I invite whoever wants to do serious development in such low level areas - as Jaffa was suggesting - to not bother with Maemo and instead to join the real community for the omap kernel or whatever is the more appropriate one for the itch that is going to be scratched.
The goal is to have every major project to be compilable and runnable on our devices without need for patching or hacking the community code.