Active Topics
-
Extra softwares in Sailfish using CLI, repositories, etc (118)
to SailfishOS by nieldk - 58 mins ago -
Paths (0)
to Maemo 7 / Leste by teroyk - 22 hrs, 22 mins ago -
Is there a section to talk about Java ME? Apps, etc. (4)
to General by teroyk - 23 hrs, 32 mins ago - more...
 |
|
2009-01-10
, 14:06
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#22
|
Originally Posted by qgil
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.
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.
 |
|
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.
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.
|
|
2009-01-10
, 20:40
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#24
|
Originally Posted by qgil
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.
If you play by these rules, there is not a fundamental difference between a tarball released and the corresponding git tree.
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.
|
|
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.
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.
|
|
2009-01-11
, 16:04
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#26
|
Originally Posted by qgil
Since I know you, I will not take this as a marketing speech, but it awfully sounds like one.
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.
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
http://maemo.org/profile/view/qgil/ + http://qt-project.org