On Wed, Mar 23, 2011 at 6:09 PM, Carsten Munk <[email protected]> wrote: > Guys, > > I think this discussion and (passive?) agressiveness has gone on for too > long. I would propose that if you have a problem with decisions made, present > a dispute to the TSG stating your exact objections, potential solutions to > the issue and let it be evaluated and let the answer to the dispute from TSG > be the final word. It is a role of the TSG to solve these kind of disputes. > +1 > We can't be bogged down with flamewars forever and we do need to make sure > that when a decision is made by people nominated in roles where they should > make the hard decisions, it is followed. Or we'll go nowhere with MeeGo. > Not trying to troll, but you sent this email just when I was about to email my thoughts and ask about my concerns for where MeeGo is heading.....
> Before any of you point out that Imad from Intel is the only person in TSG at > the moment, that TSG meetings are public and that decisions made are public > record. I personally trust that Imad will be objective and resolve the > dispute properly. > ++1 I'd also like to add that regardless of way the new architectural decisions were made, he's communication of the decision was excellent IMHO. I'm not sure this was not like this before, but his announcement was first of kind for me at least following the project.... Sometimes you need to use 'older' wheels and improve them until exhaustion before recreating them... and I think his approach could not be more healthier for the project not to mention improve release schedule and feature completeness per release. Also another note that I am trying to make through for a while about using wiki specs like Ubuntu does. I know that there's bugzilla. I don't think there could be worser tool to track specifications, not allowing you insert inline photos and images like in a proper wiki. I would like again, to propose using specs to plan ourselves ahead. it caters for easy to reach documentation (bugzilla couldn't be worse in that regard as well) for wide participation (everybody uses wiki's this days, bugzillas coward even me at times). I feel there is great objection to use proven tools and methodologies from other projects that evolved over the conservative ways of work of the open source projects of the 70s, like Ubuntu , Debian, Linaro and others similar. I can't understand why. I will try to serve as an example with my projects, but it would be great to have this for the core arch of meego. I fantasize of reading through the spec like Linaro has, understanding why decisions were made, how, what did they affect and how they are implemented. Architectural overview like we have is nice, maybe for a vendor decision maker, but not for someone interested and the bolts and bulbs of some inner subsystem like the watchdog, or DSME (we keep getting question about it , as Jeremiah asked not long ago) or policy kit etc. If those have specs upstream, then we should link them for easy access. I ask you, is it feasible to have a spec like I linked from the email I sent some time ago (a spec with drawing and charts together with text ). Or better, hover to linaro's wiki and wander through the other specs. I think if we work that way, this would be a leap forward and how we architect meego. Also, in conferences we should have bofs per spec to discuss with the people involved of its design and attack plan for implementation. -Sivan _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
