Page 3 of 3 12 3
Reply
Thread Tools
qgil's Avatar
qgil is offline qgil
2009-01-10 , 12:23
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#21
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.
I still don't see this day. It's not easy to disclose internal information, and internal bugs are just that. Bringing development and testing to the outside is probably an easier and more logical path. Yes, I know there are 1001 obstacles tied with unannounced hardware and features there as well. Still, there are more business reasons to show your bugs when it's the right time to fix them than once the products are out.

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.
This day is around the corner and actually when it comes depends a lot on... you? It is not a coincidence that maemo.org git support and contribution guidelines are being put in place as we speak.
__________________
http://maemo.org/profile/view/qgil/ + http://qt-project.org
 

The Following 2 Users Say Thank You to qgil For This Useful Post:
igor's Avatar
igor is offline igor
2009-01-10 , 14:06
Posts: 198 | Thanked: 273 times | Joined on Jan 2006 @ Helsinki, Finland
#22
Originally Posted by qgil View Post
This day is around the corner and actually when it comes depends a lot on... you? It is not a coincidence that maemo.org git support and contribution guidelines are being put in place as we speak.
Maybe I am just dense, but i don't understand how come the internal information present in the description of a patch is less important than the internal information present in bugzilla, since often they have similar information and can refer to eachother.
 
qgil's Avatar
qgil is offline qgil
2009-01-10 , 20:30
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#23
Someone could say that changelogs refer only to FIXED bugs and tell in most cases little about the rest and about the comments written in an internal context.

But actually I take this from a very different angle: the internal bug tracking system is a central piece of the release process and affects many teams and processes. Instead, where and how you handle your code is mostly your decision as long as you follow the steps to release it and you keep your duties with the release program. If you play by these rules, there is not a fundamental difference between a tarball released and the corresponding git tree.
 
igor's Avatar
igor is offline igor
2009-01-10 , 20:40
Posts: 198 | Thanked: 273 times | Joined on Jan 2006 @ Helsinki, Finland
#24
Originally Posted by qgil View Post
If you play by these rules, there is not a fundamental difference between a tarball released and the corresponding git tree.
Which means we should take extra effort and purge the git tree ... and waste a couple of months doing so. I can already see people rioting the moment i announce something like that.

Let me give you an example: when i implemented dvfs for the n810 i went through 3 different implementation. I think if you ask around you'll still find people pissed off by the first 2 incarnations.

All of that gets lost in the tarball.

The implementation was not deemed to be good enough to be merged in the main linux omap tree (which incidentally as of today still lacks dvfs support) and publishing the git tree would have made available the history of trial and errors to whoever wanted to pick up the activity.

But i am not fanatic enough to go through every commit (including others') to make sure they are acceptable.

Either we put out the real thing and behave consistently with what we preach or it's probably better to shut up and stop pretending to be open.
 
qgil's Avatar
qgil is offline qgil
2009-01-10 , 20:57
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#25
I know, and all these good arguments add to the idea that open development goes first. Also, different teams/components have different circumstances.

This is why I'm personally not too obsessed about a single bugzilla or even about getting the developers directly involved in bugs.maemo.org. Open development for open source components is the main goal, and once you are developing your code publicly then all the rest will adapt sooner or later to that.
 
igor's Avatar
igor is offline igor
2009-01-11 , 16:04
Posts: 198 | Thanked: 273 times | Joined on Jan 2006 @ Helsinki, Finland
#26
Originally Posted by qgil View Post
Open development for open source components is the main goal, and once you are developing your code publicly then all the rest will adapt sooner or later to that.
Since I know you, I will not take this as a marketing speech, but it awfully sounds like one.

Anyway unless the HW goes open from the beginning (i cannot believe it will ever happen), the only alternative is that all the history of the development is published with the code. Which goes against the idea of not disclosing internal info.

That's a the next puzzle for you to solve ;-)

And please don't repeat that you want open development, since it is already happening for the kernel.

What is missing, and it's for _you_ to obtain it, in your role of Mr Maemo, is the permission to walk the last mile and publish the internal development info, which is specific to our HW and otherwise will never go out as part of the so much invoked "open development".

Checkmate.

:-P
 
Reply
Page 3 of 3 12 3

Tags
bug, bugzilla

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 19:27.

Contact Us - Home - Archive - Top