Re: [MeeGo-dev] Some questions about the Technical Steering Group & TSG meetings
Hi, ext Sousou, Imad wrote: > to be honest with you, both Valtteri and I are spending 200% of our time > getting the initial MeeGo sources out so there is something to ground > the discussions... And we are working to get detailed architecture as soon as possible. This can come before a first integrated release and would already help a lot focusing discussions on technical matters. Still, there is a % of discussion that doesn't depend on source code release (Carsten's example is good: should we have a web forum?) and we need to find the way to balance the role of the TSG. It's good that the TSG has an overall vision over the project and makes sure such vision is implemented, but the TSG members (specially if they are 2 at the moment) have surely better things to do than engaging in the discussion about a web forum. >> We need to show newcomers there's an actual project going on - right >> now it feels a bit like there's no approachability to the TSG or the >> project governance, which is not what it should be in the long term, >> hence my questions. >> >> First off, it is not clear who is exactly in the TSG. Is this Imad & >> Valtteri or do they organisationally sit on top of TSG? > > For now, its both... until we get things going > >> If they organisationally sit on top of TSG, how is TSG chosen (I >> understand there might be an initial one chosen already, question is >> for the 'next TSG', and will this selection also include non-technical >> merit such as community work? > > Your question presumes a specific slice of the community; IMO, those of us > involved in MeeGo need to address the various "slices"... meaning the > operating system developer community, the app developers community, the > user community, etc... but going back to your question; yes, we need all > the above to be well represented in the structure and governance... In our case the TSG is not even supposed to lead or be the meritocratic authority in many areas. Imad and Valtteri are not going to be the ones with the keys of the repository looking at the incoming patches to give them a green or red card. Their leadership role is more strategic and organizational. The sooner they can start nominating and delegating into an official MeeGo staff the better. If we imagine the noisy day to day in MeeGo, it should be originated mostly by the work around - the code (repos, bugzilla, dev blogs...) - the releases (SDK, images, developer support, testers, contributors...) - the working groups (strategy, planning, tough discussions) Most of the daily decisions will happen around these contexts without requiring any TSG direct approval. Hopefully the current bootstrapping / bottleneck situation can ve overcome soon. I have no doubt about the good willingness of the TSG and I'm seeing these guys working really hard 24/7, but it is true that all this activity behind the doors can't be seen from the current MeeGo channels. >> When will the first public TSG meeting start and will they be held in >> #meego-meeting on FreeNode IRC? > > In the next week or two... not sure whether we should do on IRC or maybe > we can also try a real voice conference and see how that works Question: how does the Linux Foundation operate with meetings and discussions? The W3C consortium is another organization that comes to mind (working groups, individual & corporate involvement...) fwiw the first MeeGo IRC meeting was quite productive and the use of http://wiki.debian.org/MeetBot resulted in very cool automatic minutes: http://meego.mkdir.name/logs/meego-meeting/2010/meego-meeting.2010-02-24-20.04.html -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Some questions about the Technical Steering Group & TSG meetings
meego.com still need some RSS love, so here is a link to http://meego.com/community/blogs/valhalla/2010/towards-day-one where some questions are answered by Valtteri. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] meego-sdk list created
Hi, new list for the sdk specific discussions: http://lists.meego.com/listinfo/meego-sdk -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] First TSG meeting on Friday @ 20h UTC
Hi, http://meego.com/community/blogs/qgil/2010/first-technical-steering-group-meeting The Technical Steering Group is having the first IRC meeting on Friday, 19 March 2010, 20:00:00 UTC time [1]. The meeting will be held in the #meego-meeting IRC channel. * MeeGo architecture update. * MeeGo release plan. * Release program setup. * Technical Steering Group setup. * Community working group proposal. * Localization working group proposal. * Appointments * AOB The meeting will be moderated and instructions will be posted in the chat room topic. http://timeanddate.com/worldclock/fixedtime.html?day=19&month=3&year=2010&hour=20&min=0&sec=0&p1=0 -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Working Group at Linux Collaboration Summit 2010
Hi, ext Sivan Greenberg wrote: > Hey List, > > Does anybody know who is going to attend this WG from MeeGo ? I will be there as well. Perhaps someone can start a wiki page to coordinate our presence there? > What are > the subjects and matters going to be discussed/worked on ? That was also my question some days ago as well. Basically what happened is that the MeeGo launch timing didn't play well together with the Collaboration Summit call for participation. Dirk Hohndel from Intel "secured" the track and actually some MeeGo related proposals were submitted through the regular process. But that was not enough to fill the schedule and it was too late to make an MeeGo-level call for participation here. So Dirk asked Dawn Foster to look for the remaining session and she is finishing the details. The schedule will be available soon at http://events.linuxfoundation.org/lfcs2010/meego-workgroup > Is this event > going to have any significance to the project development wise? It will be good to catch up there and discuss over drinks and in corridors in a way no email discussion can substitute. Other than that I don't expect any crucial discussion and even less decisions. For that we need to wait to the MeeGo Summit. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
Hi, ext Jeremiah Foster wrote: > I guess backporting a lot > of development that happens in MeeGo to the N900 is not in Nokia's > plans at the moment. The N900 is a MeeGo reference platform. This means that MeeGo testing needs to be done against this hardware. This means that MeeGo needs to work on the N900. And this is a goal a team coordinated by Nokia is trying to accomplish already now. > Although the N900 > already has an awesome OS in Maemo, "official" support for MeeGo on > the OMAP3 will probably not be done by Nokia. I think the community > will have to pull down the kernel sources and build them and add in > any functionality the community thinks is missing themselves to the > N900 if they want a pure MeeGo release. A pure MeeGo release (an open source stack from kernel to apps) is precisely what is expected to come from the MeeGo project (in practice, a task assumed by a team coordinated by Nokia). -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Open drivers (was Re: N900 Questions...)
Hi, ext Adrian Yanes wrote: > We asked to Nokia when was Maemo, this is the response: > > http://wiki.maemo.org/Why_the_closed_packages > > Arguments like "brand" and "differentiation" are present in the > official response. > > So before involve other vendors, would be nice if your company clarify > their own components. As it is pointed out in the wiki page you are linking, if you want a Nokia closed component to be open, please see http://wiki.maemo.org/Open_development/Licensing_change_requests This is meego-dev and you are asking about binaries in Maemo based Nokia products. We had this discussion plenty of times at maemo.org and you are free to continue it at maemo.org. Please limit your discussion here to the MeeGo stack and how it plans to handle closed binaries officially supported. > The fact is that now Intel and Nokia are together. They can obtain > these components, even without money. Do you mean that without money one can write the best drivers for latest hardware? I'm not a big fan of closed binaries for hardware adaptation but I understand that companies involved in this complex and highly competitive activity want to pay salaries and bring benefits to shareholders. > Perhaps the world is not perfect but it doesn't mean that we should > not have the best intentions to improve it. Looking at the IT & mobile industries it looks like Intel and Nokia are actually championing with best intentions when it comes to investments in open source. This is only my personal opinion, but I think open source adoption in the mobile industry is going as fast as it gets evolving without breaking the business models in this industry. The argument pushed sometimes by free software enthusiasts (also in this thread) is that big corps like Nokia or Intel could push the free licenses further thanks to its predominant position in the market. Even if that would be true, the execution would remove a bunch of smaller innovative players from the map (acquired, bought out, pushed out of business). If that would be a better world for software freedom, I don't know. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
ext Adrian Yanes wrote: > I understand your arguments, but we need change the vendors mentality > ( didn't change Nokia?, the others can ). Nokia and Intel *have* changed vendors mentality and they keep changing it with projects like MeeGo no matter how long this thread goes. Adrian, if you want to change any mentality then this is not the best place since all here we are convinced already. You could invest your time seeing how to convince Imagination & co that open drivers would be beneficial for their business. You can also inquire Nokia about Nokia binaries if you wish, following the process described at http://wiki.maemo.org/Open_development/Licensing_change_requests -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Transitional development questions
Hi, ext Matthieu Chaton wrote: > Le 26 avr. 2010 à 10:10, Dave Neary a écrit : >> As I understand it, to call yourself MeeGo, you have to have all the >> core components of the platform & applications as defined by the MeeGo >> project, and must use them all. RPM is part of the core platform definition. >> >> Nothing is stopping someone from re-packaging all the MeeGo components >> using deb, but you wouldn't be able to call it MeeGo. > > I'm not sure about that, Maemo 6 will be called MeeGo, and it will use deb > packages Ibrahim [1] from The Linux Foundation is coordinating the work to define and test MeeGo compliance. Please give them some time to come up with their conclusions. Maemo 6 and Moblin 2.2 development plhases were caught in the middle of the MeeGo announcement, with committed deliveries and deadlines. Both are taking some compromises in order to fit within the MeeGo definition, and both Nokia and Intel are doing the steps to deepen in one single and common MeeGo stack. Hopefully everybody understands that this doesn't happen overnight when you have to ship releases without delays. It is actually nobody's interest to focus in the differences of Harmattan (the former Maemo 6) in order to tear it apart, as long as it offers a MeeGo API and a simple tool for developers to deal with rpm/deb and the Ovi Store. After the transition period MeeGo based devices from Nokia will ship with a pure MeeGo stack, and problem solved. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Transitional development questions
Gil Quim (Nokia-D/Helsinki) wrote: > Hi, > > ext Matthieu Chaton wrote: >> Le 26 avr. 2010 à 10:10, Dave Neary a écrit : >>> As I understand it, to call yourself MeeGo, you have to have all the >>> core components of the platform & applications as defined by the MeeGo >>> project, and must use them all. RPM is part of the core platform definition. >>> >>> Nothing is stopping someone from re-packaging all the MeeGo components >>> using deb, but you wouldn't be able to call it MeeGo. >> I'm not sure about that, Maemo 6 will be called MeeGo, and it will use deb >> packages > > Ibrahim [1] from The Linux Foundation is coordinating the work to define Sorry, forgot the link: [1] http://meego.com/community/blogs/ibrahim/2010/introducing-myself-meego-community > and test MeeGo compliance. Please give them some time to come up with > their conclusions. > > Maemo 6 and Moblin 2.2 development plhases were caught in the middle of > the MeeGo announcement, with committed deliveries and deadlines. Both > are taking some compromises in order to fit within the MeeGo definition, > and both Nokia and Intel are doing the steps to deepen in one single and > common MeeGo stack. Hopefully everybody understands that this doesn't > happen overnight when you have to ship releases without delays. > > It is actually nobody's interest to focus in the differences of > Harmattan (the former Maemo 6) in order to tear it apart, as long as it > offers a MeeGo API and a simple tool for developers to deal with rpm/deb > and the Ovi Store. After the transition period MeeGo based devices from > Nokia will ship with a pure MeeGo stack, and problem solved. > -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Projected timelines for full openness
Hi, ext Glen Gray wrote: > > By openness I mean > code available, for me to download, compile and work on. Some code was > released for Day 1 as regards the base operating system but the project > is still largely being designed and developed behind closed doors. The > plan is for this to move to an open model which includes the MeeGo > community. What I'm asking for is timelines on when this will happen. The plan is to have in few weeks a first complete MeeGo release followed by a roadmap to work on the next release. Once this is out the MeeGo project shouldn't have any obstacle to have all the daily work and routines in the open. There might still be some areas under the shadow, but always related to new developments e.g. imagine the arrival of a new cool UX category or key platform feature. Once they are released they go to open business as usual. All this is related to two main factors: - One that is quite unique now: two big teams having to sync on 1001 little things before going public & common. - One that will be around basically always: marketing factors making company X or even the MeeGo project itself to go for a sound release instead of an open development since the first line of code. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
Hi, ext David Greaves wrote: > quim@nokia.com wrote: >> Hi, >> >> I think we have a mismatch between the name and the content. How to >> call this? Names carried from maemo.org or moblin.org would be >> "Downloads", "Extras" or "Garage". "Apps", "Addons", "Catalog" are >> also used in similar contexts. None of them is perfectly accurate >> but calling it "Universe/Multiverse" is probably not the best >> solution either. :) > Heh :) > >> So what about "Downloads" as a compromise between clarity and >> accuracy? > I agree the name is actually quite important; now we almost have the > scope we can address it. Personally, I like "Surrounds". I find > "Downloads" a little mundane and non-inspirational? Surrounds clearly > says "not core" and is nicely embracing and quite positive :) I reckon "Downloads" is mundane. So descriptive that everybody understands it. ;) "Surrounds" is indeed poetic but I don't believe it "clearly says" anything to most of us here, leave alone people seeing the project from the outside. About people downloading apps, music, videos, etc... the only thing we know for sure they download are... Downloads. Let me insist on "Downloads", then. :) > >>> * Isn't this covered in the MeeGo 'Core' project structure? >> At least I don't see it. The Program Office has a clear mission >> which consists on shipping great MeeGo > releases every 6 months. The proliferation of a great offering of > additional software is a different mission that deserves its own > focus. Fully agree. My only 'worry' was that the 2 types of surround > (individual applications and 'universe') would be split apart. Why split apart? The Downloads team is responsible of the QA and distribution of any downloads distributed from meego.com not comprised in the official release, including dependencies. It was good to have Mike's feedback. Now, can we have at least Bob's feedback? What is the current status and how to help and continue the work? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
ext Graham Cobb wrote: > why don't we call this the "Community Repositories Team". +1 Being picky someone still could say that since all MeeGo is community all repos are community repos. Still, most people do understand that one thing are the repos of software officially supported making a MeeGo release, and another thing are the repos of software containing software from all kinds of third parties. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Projected timelines for full openness
Hi, ext Graham Cobb wrote: > On Tuesday 27 April 2010 10:16:07 Quim Gil wrote: >> The plan is to have in few weeks a first complete MeeGo release followed >> by a roadmap to work on the next release. Once this is out the MeeGo >> project shouldn't have any obstacle to have all the daily work and >> routines in the open. > > I am very disappointed in this. I really expect a project which is sponsored > by the Linux Foundation to have **all** discussion on public mailing lists. > No exceptions. That is my expectation too. However, there is a difference before and after a first release. I'm not defending the current situation of closed development prior to the first MeeGo release, but this is the reality. Before the first MeeGo release there is a lot of code being developed behind Intel or Nokia closed doors or in some public repo somewhere. Those pieces of software are being developed more or less by the same teams that were developing them before the MeeGo launch and without much changes. The release dates are around the corner and those teams from Intel or Nokia are not really in a condition to receive and process much feedback at this point, noting that such feedback might include prospective contacts from potential industry partners, media sensationalism, users asking when that piece of software will be available for their devices, etc. Then in few weeks a full MeeGo stack will be released, news and blog posts with screenshots will fly, deep and superficial feedback of happy and unhappy people will circulate, etc. All good! A roadmap for the next release will be published and the project will be finally in a situation to build a daily routine based on plain simple open development. > Each MeeGo subsystem should have its own mailing list, > visible for anyone who is interested. This is a comment aside but yes, we need to discuss how the daily routine of project discussion is held. The current approach is to concentrate on the current lists (-dev, -sdk and -l10n) and spin off new ones only when the traffic deserves that. In the Linux Collaboration Summit a speaker of IBM explained that at some point they forbid internal technical discussions about development of open source components, forcing their own engineers to go and have those discussion in the upstream projects channels. I find that is an excellent idea: after the MeeGo release discussions about OSS development through private emails should be a well justified exception and not the norm. It really helps nobody: not to the development of those OSS components and not even to the interests of Nokia/Intel. > I have no problem with benevolent dictators -- I have a problem with calling > MeeGo an "open project" if decisions being made behind closed doors, > particularly technical decisions. If there is some concern over the amounts > of traffic on public lists then you could require some sort of qualification > or sponsorship for the privilege of sending to the lists: but the > conversations must be visible for all! Improvising a bit here, the reasons for having private discussions prior to the first MeeGo release are: - Building common proposals first. Nokia and Intel don't aim to have everything polished before discussing every bit publicly, but having a common plan in place and going through the first rounds of discussion internally before makes some sense. - Having public roles first. The average Nokia or Intel employee working on something specific wants to know what is his/her official MeeGo role so they know when are they speaking for themselves, as upstream maintainers, as company employees... Having a full release out makes things easier for everybody. - Having clear instructions from managers first. The average Nokia or Intel employee working on something specific probably has a manager concerned on deliveries for release X. Depending on managers and teams, open development is already assumed - or not. Everybody know we need to change this culture but when it comes to pressure, having the first release still clearly wins. - Anything with a UI is still very sensitive, specially in the Handset UX. In theory you could indeed go to a public mailing list and just start discussing. In practice, the moment you do this you need to be prepared for a significant amount of feedback and noise coming from users and media. We have seen examples of this every other week. A lot of new development in MeeGo has to do with these areas (desktop & apps). Nobody wants to be the guy quoted in the media before it's the right time. - Having consolidated/specialized channels? I'm wondering myself, but there might be some personal resistance (combined with the two points above) to go to meego-dev to share some development info and opinions if there is a remarkable risk of starting a long thread with high noise to signal ratio originat
Re: [MeeGo-dev] Projected timelines for full openness
Forgot another important aspect. See below. :) Gil Quim (Nokia-D/Helsinki) wrote: > Hi, > > ext Graham Cobb wrote: >> On Tuesday 27 April 2010 10:16:07 Quim Gil wrote: >>> The plan is to have in few weeks a first complete MeeGo release followed >>> by a roadmap to work on the next release. Once this is out the MeeGo >>> project shouldn't have any obstacle to have all the daily work and >>> routines in the open. >> I am very disappointed in this. I really expect a project which is >> sponsored >> by the Linux Foundation to have **all** discussion on public mailing lists. >> No exceptions. > > That is my expectation too. However, there is a difference before and > after a first release. I'm not defending the current situation of closed > development prior to the first MeeGo release, but this is the reality. > > Before the first MeeGo release there is a lot of code being developed > behind Intel or Nokia closed doors or in some public repo somewhere. > Those pieces of software are being developed more or less by the same > teams that were developing them before the MeeGo launch and without much > changes. The release dates are around the corner and those teams from > Intel or Nokia are not really in a condition to receive and process much > feedback at this point, noting that such feedback might include > prospective contacts from potential industry partners, media > sensationalism, users asking when that piece of software will be > available for their devices, etc. > > Then in few weeks a full MeeGo stack will be released, news and blog > posts with screenshots will fly, deep and superficial feedback of happy > and unhappy people will circulate, etc. All good! A roadmap for the next > release will be published and the project will be finally in a situation > to build a daily routine based on plain simple open development. > > >> Each MeeGo subsystem should have its own mailing list, >> visible for anyone who is interested. > > This is a comment aside but yes, we need to discuss how the daily > routine of project discussion is held. The current approach is to > concentrate on the current lists (-dev, -sdk and -l10n) and spin off new > ones only when the traffic deserves that. > > In the Linux Collaboration Summit a speaker of IBM explained that at > some point they forbid internal technical discussions about development > of open source components, forcing their own engineers to go and have > those discussion in the upstream projects channels. I find that is an > excellent idea: after the MeeGo release discussions about OSS > development through private emails should be a well justified exception > and not the norm. It really helps nobody: not to the development of > those OSS components and not even to the interests of Nokia/Intel. > > >> I have no problem with benevolent dictators -- I have a problem with calling >> MeeGo an "open project" if decisions being made behind closed doors, >> particularly technical decisions. If there is some concern over the amounts >> of traffic on public lists then you could require some sort of qualification >> or sponsorship for the privilege of sending to the lists: but the >> conversations must be visible for all! > > Improvising a bit here, the reasons for having private discussions prior > to the first MeeGo release are: > > - Building common proposals first. Nokia and Intel don't aim to have > everything polished before discussing every bit publicly, but having a > common plan in place and going through the first rounds of discussion > internally before makes some sense. > > - Having public roles first. The average Nokia or Intel employee working > on something specific wants to know what is his/her official MeeGo role > so they know when are they speaking for themselves, as upstream > maintainers, as company employees... Having a full release out makes > things easier for everybody. > > - Having clear instructions from managers first. The average Nokia or > Intel employee working on something specific probably has a manager > concerned on deliveries for release X. Depending on managers and teams, > open development is already assumed - or not. Everybody know we need to > change this culture but when it comes to pressure, having the first > release still clearly wins. > > - Anything with a UI is still very sensitive, specially in the Handset > UX. In theory you could indeed go to a public mailing list and just > start discussing. In practice, the moment you do this you need to be > prepared for a significant amount of feedback and noise coming from > users and media. We have seen examples of this ever
Re: [MeeGo-dev] Projected timelines for full openness
ext Glen Gray wrote: > On 27 Apr 2010, at 10:16, Quim Gil wrote: > >> The plan is to have in few weeks a first complete MeeGo release >> followed by a roadmap to work on the next release. Once this is out >> the MeeGo project shouldn't have any obstacle to have all the daily >> work and routines in the open. >> > > > Thanks for the honest reply Quim. > > I think a LOT of misunderstandings and anxiety about what's happening > could have been avoided if this had been clearly stated from the get > go. We've been getting mixed messages as others have commented on > today. Sure, but this assumes that we knew exactly how things would roll out. :) This is the first time we do a merge like this and there are actually not many precedents to look at. At any point we have said what we actually believed that would happen. Then some things happen when and how you expect and some others go in different ways. Even if this is sometimes uncomfortable, all in all is not a huge deal since the direction is clear, the will is there and we will go through this. Also, there seems to be a perception that Intel and Nokia now form a single united team sharing all the information and clear plans and hiding most of it to the community. I take this as a variant of the conspiracy theories around corporations. ;) But this merge also brings "mixed messages" and perceived "lack of information" to Joe Developer at Intel and Nokia. A natural part of the process: consolidates teams of people sharing common managers, company structures and knowledge of confidential corporate plans now are meant to collaborate fluently and in the open with developers from other companies and individual contributors. In practice this is easier for developers used to these dynamics in upstream projects (Kernel, BlueZ, etc) and less easy for others (future reference applications, system UIs still not shipping in any product, etc). >> - One that is quite unique now: two big teams having to sync on >> 1001 little things before going public & common. > > I'm sure having discussions out in the open would have actually aided > in that. There still seems to be a lot of misunderstanding between > the teams from Intel and Nokia which is seeping through to the public > level. Even from departments within Intel. That's my perception > anyways. Yes, all in all open discussions do help. But some of them do not help if you need a well founded decision with a tight deadline. I mean, there have been some hot topics that now we have settled but a regular open project would still be discussing ad aeternum. Now they can still be discussed (ad aeternum if you wish), but the fact of knowing that Intel and Nokia as main current promoters have agreed on something does help moving forward. Again, after the first MeeGo release the backbone is in place and probably there will not be any technical discussion stopping the show for the rest of the project. We will also know each other better so the risk of "personal damage" in public discussion will be smaller. Then there is also an "empty disco dance floor" effect. Even if many people is willing to dance, the dance floor is mainly empty and you look left and right to see if any of your friends will jump first. (To make the analogy more complete, in such situations usually you see the first ones jumping to the floor with quite extrovert attitudes and questionable dancing skills - which doesn't help your motivation to do the step). ;) But every night the dance floor ends up full with plenty of fun, and at that point is plain easy for anybody to just get in and add to the mess. We are getting there, slowly. >> - One that will be around basically always: marketing factors >> making company X or even the MeeGo project itself to go for a sound >> release instead of an open development since the first line of >> code. > > This is something that is of great concern to me. We've seen this > before plenty of times. Specifically, partner releases, which > coincide with the main product release. Yes, we have seen this. But this is one point I really love about MeeGo: time based releases. Products have to align to the MeeGo timeline, not the other way around. > It seems incredibly unfair > and disrespectful to a community to deny them access to the product, > many of whom would possibly like to further the use in a commercial > setting. But at the same time to provide access to "key partners" in > order to have a big reveal for launch day. Confidential projects from a company will always exist: one company is developing something and they decide the day when they want to start sharing publicly. But this is fair, isn't it. What would not be fair is that the MeeGo project is used as a curtain
Re: [MeeGo-dev] how to start developing on MeeGo?
Hi, The meego-dev mailing list is for discussions about development of the MeeGo platform. Topics about application development on top of MeeGo have 2 better places: Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk -- MeeGo SDK mailing list Discussion and coordination about the meeGo developer offering, but you can also ask your questions there if you wish. http://lists.meego.com/listinfo/meego-sdk Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ext An Yang wrote: > Hi Glen, > > 在 2010-04-30五的 10:03 +0100，Glen Gray写道： >> >> On 30 Apr 2010, at 03:31, An Yang wrote: >> >>> hi Gray, >>> >> >> >> It's Glen >> >>> >>> I did install meego on my eeepc manually. >>> >>> >> >> >> Yes, manual installs are possible, but clearly wasn't going to be an >> adequate answer to the person asking about what to do with those image >> files. > > Somebody just want use hard disc, manual install is the only way to > install meego image to hard disc, until meego release the installation > scripts-:) > maybe the scripts just do the same job with my manual install suggestion. >> >> >> -- >> Glen Gray >> mailto:sla...@slaine.org>> >> >> >> >> >> >> >> ___ >> MeeGo-dev mailing list >> MeeGo-dev@meego.com <mailto:MeeGo-dev@meego.com> >> http://lists.meego.com/listinfo/meego-dev > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Beginer level Qt on meego.
Hi, The meego-dev mailing list is for discussions about development of the MeeGo platform. Topics about application development on top of MeeGo have 2 better places: Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk -- MeeGo SDK mailing list Discussion and coordination about the meeGo developer offering, but you can also ask your questions there if you wish. http://lists.meego.com/listinfo/meego-sdk Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ext Efan... wrote: > Thanx Tom, > > I got it. But this is talking about Maemo Not Meego. Will an application > compiled for Maemo run On Maego on same device? > I think yes, just wanted to check if you have had chance to run any > application on Meego? > > Thanx for your help > > On Mon, May 3, 2010 at 11:34 AM, lists4pghanghas > mailto:lists4pghang...@gmail.com>> wrote: > > On Monday 03 May 2010 10:17 PM, Efan... wrote: >> Hi Tom, >> Thanx for your help, But unfortunately I dont see Mobile SDK 2.0 >> on there site. I Get other SDK but mobile one. >> http://qt.nokia.com/downloads >> >> Can you please point me to correct link. >> >> Thanx again for your help. >> >> BR >> >> Efan >> >> On Sat, May 1, 2010 at 5:57 AM, Tom Arnold > <mailto:g...@rocketmail.com>> wrote: >> >> Download Nokias Qt mobile SDK 2.0 beta. It has a emulator and >> device support (and stuff). Really neat. >> >> >> >> *From:* Efan... > <mailto:efanhar...@gmail.com>> >> *To:* meego-dev mailto:meego-dev@meego.com>> >> *Sent:* Fri, April 30, 2010 11:53:02 PM >> *Subject:* [MeeGo-dev] Beginer level Qt on meego. >> >> Hi, >> I have installed meego on my N900. Now I want to run some of >> Qt example on this. >> Can some body please help how can I do this. >> Do I need to cross compile Qt for N900 and so is my example? >> >> I will really appreciate if some of you can help me with the >> steps I need to do to see my Hello world Qt application >> running on N900 with meego >> >> -- >> Efan Harris >> >> >> >> >> -- >> Efan Harris >> >> >> ___ >> MeeGo-dev mailing list >> MeeGo-dev@meego.com <mailto:MeeGo-dev@meego.com> >> http://lists.meego.com/listinfo/meego-dev > Hi Efan, > > this links contains all that you need including a download link > > http://labs.trolltech.com/blogs/2010/04/27/nokia-qt-sdk-what-is-in-and-what-is-not-and%E2%80%A6-what-is-it/ > I suggest you add this blog to your feed reader if you are > interested in qt development. Really nice articles appear here. > > PSG > > > > > -- > Efan Harris > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt application on Meego
Hi Efan, You sent the same email at the same time to meego-sdk. Please avoid cross-posting. meego-sdk is the right list for application developers since meego-dev is for development of the platform itself. Alternatively you can also use the Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 Thank you for your interest in MeeGo and I hope you get the right answers. -- Quim Gil ext Efan... wrote: > Hi all > > Any one got any chance to build and run any Qt application on Nokia N900 > having Meego??? > > I did installed Nokia mobile sdk but that does not seem to be helpful > for Meego. > I have installed Meego on Nokia N900 but really dont know How to build > and run my Qt application on it. > > Nokia mobile sdk tutorial does not talk about Meggo at all, > > Highly appreciate any help in this. > > -- > Efan Harris > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt application on Meego
ext Xu Cheng wrote: > Hi, Tom: > I have same question as Efan. What's MADDE? Is a IDE? http://wiki.maemo.org/MADDE Coming soon to MeeGo and its developer documentation. Good that MeeGo also starts with M so we don't need to rename anything. ;) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Projects Bug Jar 2010.19
ext Stephen Gadsby wrote: > A Quick Look at MeeGo Projects in Bugzilla (http://bugs.meego.com/). > 2010-05-03 through 2010-05-09 Great stuff! Thank you Stephen. Life in MeeGo was missing something without the weekly bug jars. > 20 bugs were opened - > ( > https://bugs.maemo.org/buglist.cgi?bug_id=1614,1657,1658,1699,1710,1711,1718,1745,1765,1766,1770,1779,1798,1803,1804,1805,1807,1813,1847,1852 A bug in the script, that still creates URLs pointing to bugs.maemo.org instead of bugs.meego.com Looking forward now to the implementation of votes in bugs.maeego.com so we can also get weekly updates on the most popular bugs and enhancement requests. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] List of MeeGo compatible devices
Hi, erkanyilmaz start this useful wiki page http://wiki.meego.com/Compatible_devices_with_MeeGo Please help completing it. "Is compatible with MeeGo?" is one of the FAQ from people with a mobile device (mainly netbooks) or thinking of buying one. Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] List of MeeGo compatible devices
ext David Greaves wrote: > Robin Burchell wrote: >> On Mon, May 10, 2010 at 9:50 AM, David Greaves wrote: >>> Quim Gil wrote: >>>> Hi, erkanyilmaz start this useful wiki page >>>> >>>> http://wiki.meego.com/Compatible_devices_with_MeeGo >>>> >>>> Please help completing it. "Is compatible with MeeGo?" is one of >>>> the FAQ from people with a mobile device (mainly netbooks) or thinking >>>> of buying one. >>> You mean like this one: >>> http://wiki.meego.com/Devices >> They're the same page, Compatible devices is a redirect to Devices. > No, actually Devices was there first, had a different (logical) structure and > has Devices/N900 subpage with a template and instructions ... not just a lot > of > wikipedia links... > > http://wiki.meego.com/Devices/N900 > > http://wiki.meego.com/Special:Log/delete Sorry, the new page was the result of http://forum.meego.com/showthread.php?t=83 and collected more information pretty fast. The older one was still orphan and had minimum differences. These things sometimes happen in active wikis. I have changed the N900 link to http://wiki.meego.com/Devices/N900 - not a big deal? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Voting in bugs.maemo.org
Hi, we are considering the addition of Bugzilla's voting feature at http://bugs.maemo.org http://www.bugzilla.org/docs/2.22/html/voting.html This feature serves a very good purpose in http://bugs.maemo.org and other bug reporting tools out there. It is an indicator about interest that might be taken into account by development teams and contributors. All people involved in the discussion has agreed on the usefulness of the feature and we decided to ask here just to check with the developers. The enhancement request is filed at http://bugs.meego.com/show_bug.cgi?id=1080 . Since you can't vote in bugs.meego.com the OP created a thread with a poll at http://forum.meego.com/showthread.php?t=96 :) Please give your feedback in any of those channels. We will decide in a week, latest. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Voting in bugs.maemo.org
Quim Gil wrote: > Hi, we are considering the addition of Bugzilla's voting feature at Of course I meant http://bugs.meego.com Sorry, too much time typing some URLs > > http://www.bugzilla.org/docs/2.22/html/voting.html > > This feature serves a very good purpose in http://bugs.maemo.org and > other bug reporting tools out there. It is an indicator about interest > that might be taken into account by development teams and contributors. > > All people involved in the discussion has agreed on the usefulness of > the feature and we decided to ask here just to check with the developers. > > The enhancement request is filed at > http://bugs.meego.com/show_bug.cgi?id=1080 . Since you can't vote in > bugs.meego.com the OP created a thread with a poll at > http://forum.meego.com/showthread.php?t=96 :) > > Please give your feedback in any of those channels. We will decide in a > week, latest. > -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 hw adaptation project goes open
ext Dave Neary wrote: > Thanks Harri! > > harri.hakuli...@nokia.com wrote: >> First, to make it absolute clear for everybody: This is about open MeeGo >> adaptation to N900 device. >> Like any other MeeGo project, it is open source project for all >> applicaple purposes, and does NOT directly have links to any potential >> Nokia product or potential product plans. So, based on this or any other >> of my posts, please do NOT start or continue speculation of upcoming >> Nokia MeeGo releases. That is practically not helpfull, and mostly only >> takes our time when we need to explain our words and actions in detail >> to various directions. > > Are you in a position yet to say which components will be closed, and > which will be supported by the open source project? Even a list with > some gray area (say some components where you're not sure) would be > useful, I think. Your question is a bit confusing (at least to me). Harri's team is working on taking the MeeGo Core + Handset UX releases (100% open source) and making them to work in the N900 hardware. Until now they have released a 100% free image (freedom at the expense of some functionality/performance) and an image with binaries provided by Nokia (functionality/performance at the expense of some freedom). As far as I know the proprietary binaries used are already present in Maemo 5 since they belong to their N900 hardware adaptation. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development
Hi, CCing TSG members just in case and sharing my personal take below. ext Carsten Munk wrote: > So, this is primarily an e-mail to ask some questions to the two > members of the TSG, that I think would not be sufficiently covered in > a TSG meeting and answers might be better suited for the e-mail form. > > Now, there is currently in the MeeGo project what I've heard described > as a 'big reveal mentality' by someone - regarding Handset, Netbook > UX, etc. Now, I can understand why the project needs to do this - the > press would tear you apart if not done right, so the UX'es are not > what I'm here to discuss. > > What I'm here to discuss is what it does to the project. A big reveal > obviously requires a great deal of secrecy for the parties involved. > In this case, it's two or more big companies and well, maybe > unintended, most of the MeeGo project structure (release management, > OBS/repositories, bug tracking, testing, developer documentation, > etc.). The secrecy seeps through almost every single aspect of MeeGo > and it -is- hurting our idea of public R&D. I have plenty of examples, > but this is not important to the topic. > > We're not working in the open like we're supposed to - even though as > has been said - Intel, Nokia and we all know how to do it! But when > there's a big reveal mentality active, the mode of the people > participating switches to internal/private development, even if you > are only tangentially related to the object/UX being revealed. > > And I think that's the main source of all our so called 'openness' > problems - not malice, conspiracy, laziness or whatever. For the near > future until UX'es are out, the big reveal mentality will have to stay > - and I respect that. I want a blazing start on a good future in this > project with big fanfare. It's the future I'm worried about. > > Finally, my questions to the two members of the TSG are: > > Would you agree that the big reveal mentality has been hurting the > MeeGo project extensively in terms of having public R&D up to now? > > What will you actively do to prevent the same working patterns where > people have not worked in the open due to the big reveal mentality, to > continue after the UX reveals? > > In the future, in case you get another need to do a big reveal, how > will you ensure that active, public development/work/process will not > regress to not working in the open? Should the work for big reveals be > done initially outside the MeeGo project framework? > > Thanks in advance for your answers. Actually I don't think big reveals around platform development are useful for the MeeGo project. Once the project is deployed with all working groups and related UXs and a public roadmap process in place, MeeGo should be build on simple and plain open development. Indeed, we are not yet there. But in a few weeks we will have the sensitive UXs out, the MeeGo project structure will hopefully be populated with names in the couple of layers below the TSG, the plan for the Q4 release will be out and also the official processes will be public. In such context, the news around software development will be hopefully more based on features implemented and testable rather than about big reveals. The MeeGo big reveals should come mainly from business centric announcements: devices launches, companies announcing MeeGo involvements, and so on. On the software development side, if there is a big reveal from specific vendors / projects it will be around items developed for a while on a private or public side and then offered or contributed to the MeeGo project. Since the MeeGo roadmap and plan for the next release will be public, nothing disruptive AND secret should be in the pipeline distorting the development of the ongoing unstable release. The success of MeeGo is build on top of openness and predictability. Big reveals are not very useful for vendors having to plan their products well in advance. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo compliance (was Re: Questions for TSG regarding big reveals...)
Hi, please keep the "MeeGo compliance" part in the subject of this spin off thread - thanks! Ibrahim from The Linux Foundation is driving the MeeGo compliance definition. Hopefully we can have a first version of the guidelines published soon, currently under private drafting and review to sync legal, technical, marketing and resourcing aspects. ext Cornelius Hald wrote: > So how far may companies go if the differentiate the UI? What is allowed > to still be called Meego or Meego-Compatible? Is it only theming or can > they provide their own UI framework? The main objective behind the MeeGo compliance is to guarantee binary compatibility for applications across multiple MeeGo products. All the rest (definition of the official MeeGo API, architecture...) is a consequence of this basic goal. This gives a lot of freedom to whoever wants to deploy a MeeGo based product. The MeeGo project doesn't go after a single user experience common to all MeeGo based products. Then again, if we do things right the MeeGo reference user experience will be a good default candidate and any vendor having to rationalize resources will probably think it twice before departing from it at own cost and risk. It's a choice for platform developers. > How will you manage that users always have a consistent look & feel even > with 3rd party applications? And how should a developer face this issue > - it's surely not a solution to implement every 3rd party application > for every vendor specific UI framework. Thinking out loud only, but we can see two basic trends in application UIs: the ones prioritizing platform look&feel integration and the ones pushing their own look&feel across different platforms. It's a choice for application developers. Going back to the original point, what really matters is that MeeGo users can enjoy the combination of MeeGo devices and applications of their choice no matter what choices have been made by the developers of those devices and applications. > Too many questions, I know :) But good ones! :) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development
Hi, ext JD Zheng wrote: > As far as I understand, UI/UX part is basically the most important > component(s) that MeeGo is creating by itself, but now it sounds like > MeeGo will NOT design UX by MeeGo community, at least not most, instead, > it will incorporate UX components from "upsteam" like Intel UX or Nokia > UX or others. You seem to be mixing streams. MeeGo is upstream and whatever implementation Nokia, Intel and others do based on MeeGo will be downstreams. I agree that currently, before the MeeGo UXs have been published, the waters are not clear but have no doubt about the role the MeeGo project will have maintaining and pushing its reference UX. Then MeeGo downstreams will probably customize their own UXs. Some of those customizations will be limited to preferences, themes, graphics and other details actually not contesting the upstream UX development. Some might be heavier customizations but still without having the vendor willing to challenge the upstream plans. But of course it is expected that the vendors bringing MeeGo based UXs to real users will have opinions and enhancement plans, and some of them will directly contribute or contest the upstream plans. As it usually happens. > My question is whether MeeGo will have its own UX teams/projects to > develop UX by itself or decide which UX will be chosen as MeeGo > *official* UX. Each MeeGo platform and application component needs to have teams and collaboration channels publicly documented. Anybody should be able to go to the right place and convince the right people with words, mockups, code... Anybody should have a chance to become a maintainer or responsible of an area based on own merits. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Hi, ext David Greaves wrote: > A conversation earlier today got me the action to submit a request for > the TSG: > > http://wiki.meego.com/Technical_Steering_Group_meetings#Backlog_of_Proposed_Topics I really believe that it is useful to discuss all topics well in advance before throwing them to the TSG agenda. I keep repeating myself that mantra from Arjan: "If a topic reaches the TSG it means that the rest of channels have failed". Can we please discuss first this packaging policy proposal here, involving the right people actually knowing all the technical aspects and process details? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo devel docs licensing
ext Dave Neary wrote: > Hi, > > Quim Gil wrote: >> I really believe that it is useful to discuss all topics well in advance >> before throwing them to the TSG agenda. I keep repeating myself that >> mantra from Arjan: "If a topic reaches the TSG it means that the rest of >> channels have failed". > > Sorry to hijack the thread - just wondering whether you feel there is > more discussion needed on MeeGo documentation licensing - it feels like > this is an issue that can be rubber-stamped at this stage. I feel Dawn and Ibrahim have spent plenty of time on this and they should be the ones deciding how to proceed. > If so, then the obvious next step is to request that Maemo documentation > which is currently licenced GNU FDL change its licensing to match > MeeGo's - what would you suggest is the best way to start that process? That is the easy part. File a bug at bugs.maemo.org and CC me as soon as it is clear what is the license you want. I wonder though how relevant is the Maemo 5 documentation in the MeeGo context, but we can discuss this elsewhere - in the bug report? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Hi, There is a thin line between CMS pages that only some editors can touch and protected wiki pages that only some editors can touch. Proposal: get first such page ready in the wiki and then we can discuss case by case where each one belongs to. In this case: ext Warren Baird wrote: > Would it make sense to have something like meego.com/policies that > hosts the *approved* versions of the policies, while the drafts are > maintained on the wiki? Looks like food for http://meego.com/developers . Let's avoid the proliferation of subdomains and first level subdirectories, specially for stuff you really don't need in a primary navigation bar. Now please go back to the real discussion: the content of http://wiki.meego.com/Packaging/Policy :) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of hildon?
Hi, ext Alberto Garcia wrote: > On Sun, May 23, 2010 at 02:34:43PM -0700, Arjan van de Ven wrote: > >>> So is there some plan to include hildon into meego? >> there is no plan for this at this time. >> >> I would have said "something great for the cummunity repo" if it >> wasn't for hildon patching core GTK in an incompatible way ;-( > > Can you elaborate a bit more on this? > > Hildon is a library different from GTK. > > If you're talking about the Maemo branch of GTK: yes, it contains > changes for features that were necessary but unavailable in upstream > GTK. > > But the policy was not to touch GTK unless it was completely necessary > in order to keep it as close as possible to the upstream version > (something that btw received some criticism at the time). > > Porting those changes to the latest upstream version of GTK does > indeed require some effort, but I don't think there's anything > inherently incompatible, since that same task has already been done in > the past (e.g. for Maemo 5). There are no plans to support Hildon officially in MeeGo, no matter what is the status of GTK+. This brings no changes compared to the Hildon status in Harmattan, announced as 'community supported' last year at the Desktop Summit. I also wonder what is the real status of this community support, and the willingness of the current Hildon and/or GTK+ maintainers and developers to bring Hildon and Hildon based applications to the MeeGo community repositories. There has been some discussion about this at GNOME's mobile-devel-list but honestly I had expected a more concrete or articulated answer by now. See the whole "What would you do to encourage application developers on GNOME Mobile?" discussion starting at http://mail.gnome.org/archives/mobile-devel-list/2010-April/msg3.html and even my own post back in February that got basically no traction from anybody involved in GTK+ development - http://mail.gnome.org/archives/mobile-devel-list/2010-February/msg00010.html Nokia gave a substantial fund to the GNOME Foundation with the main goal of promoting GTK+ based applications for Maemo 5 and also to help building a future path for them in future releases - now in practice MeeGo Handset UX releases. There is still not a concrete plan for that budget that I know, which is not, er, optimal considering how fast time passes both for Maemo 5 and MeeGo. Conclusion: if you think that we as Nokia still could to do something else to ease the transition of Hildon based applications to MeeGo please let me know. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of hildon?
Hi, ext Cornelius Hald wrote: > I don't know it either, but I expect it > to be basically non-existent and probably for a good reason. I don't > think it makes sense to work at Harmattan's Hildon before we know how > the Harmattan UI will look and (more important) work. That's probably > not really a technical problem, but more a motivational problem. (...) > What I think will happen is this: At some point people with big > Maemo5/Hildon applications will get a Harmattan device or SDK and then > they will try to get their applications running. Therefore they will > compile a recent version of GTk, try to apply Hildon patches, etc. I see your point. However, your motivational path is simpler if you focus on the public MeeGo Handset UX and compatible devices (coming soon) instead of waiting for the mysterious Harmattan device from Nokia. > At that point we will see whether or not it is feasible to bring Hildon > to Harmattan. Well, at least if it is a _real_ community effort. If > however Nokia did sponsor some Gtk developers and provided them with > some Harmattan UI material it might look differently. At least from a theoretical point of view it made sense to work out the support for GTK+ and Hildon related activities with the GNOME Foundation, since it's an organization able to invoice that has the overall responsibility of the GNOME and GNOME Mobile projects. The fund given to them should be enough to kickstart the work and more. >> There has been some discussion about this at GNOME's mobile-devel-list >> but honestly I had expected a more concrete or articulated answer by >> now. See the whole "What would you do to encourage application >> developers on GNOME Mobile?" discussion starting at >> http://mail.gnome.org/archives/mobile-devel-list/2010-April/msg3.html >> and even my own post back in February that got basically no traction >> from anybody involved in GTK+ development - >> http://mail.gnome.org/archives/mobile-devel-list/2010-February/msg00010.html > > It would have been nice to inform people on the maemo-devel list about > those posts. True, my fault. Maybe I was too optimistic at that time about Hildon/GTK+ maintainers taking the ball and moving forward, or at least showing interest and asking the right questions to proceed. There was also http://talk.maemo.org/showthread.php?t=36687 and this was discussed elsewhere in the Maemo community as well (can't remember now exactly where). But no post to maemo-developers, true. Then again, the GNOME project is where the GTK+/Hildon hackers are supposed to be found. I'm sure the maintainers and related developers that actually have the skills and potentially the interest of doing something like the topic discussed here were aware of these posts. > That might now be the job of the Gnome Foundation and not of Nokia. But > this is what I think should happen. > > 1.) Provide people with some time and/or money to bring all Gtk changes > that are needed for Hildon upstream into the real Gtk. > 2.) Let them make sure that the current Maemo5-Hildon compiles against > that new Gtk. > 3.) Give them insight into the Harmattan UI spec, to make it possible to > adapt the look and feel. The bal is now in the GNOME Foundation's field. Our fund went there with a proposal/recommendation of the types of activities to do, but it is now their budget and their decision. > Personally, I really really want to have Hildon on MeeGo. Not because I > think it's the future or that it is superior to Qt. No, simply because > it would be so frustrating to see my volunteering work of over a year go > into oblivion. If I had the time (3-4 month full time), I would rewrite > my application using Qt. Unfortunately this is completely unrealistic. > > Still hoping for Hildon on Meego! Having an evolutionary path for GTK+ & Maemo 5 apps into MeeGo Handset (and touch friendly UXs in general) makes total sense, and this is why we are here (and in gnome.org) discussing in these terms. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Technical Steering Group Meeting 26 May 2010 at 19:00 UTC
Hi, ext Dave Neary wrote: > To be clear: Maemo documentation is licenced under GNU FDL, which is > incompatible with all Creative Commons licences (including the similar > CC BY-SA). To allow reuse of existing Maemo documentation, we would need > Nokia to relicence these docs to Creative Commons BY. I was contacted by Ibrahim about this question. I don't see the problem: - What existing documentation in maemo.org makes sense to re-publish in meego.com? - Any new documentation produced by Nokia to be published in meego.com will follow the licensing model agreed by the MeeGo project. - If there is a corner case let's look at it. If Nokia is the only contributor then let's just copy&paste it to meego.com. If there are several contributors involved and we don't know where they are... maybe we'll finish before linking to that page or rewriting the content (extreme case). Are there more issues? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Is Meego aimed to defeat iphone?
Hi, On 05/31/2010 12:26 PM, ext Jianchun Zhou wrote: > Is Meego aimed to defeat iphone? How long will it take? Please consider starting a new thread at http://forum.meego.com/forumdisplay.php?f=2 Thanks! This is a mailing list focusing on the development of the MeeGo platform. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Summit - Structured brainstorming format in the form of BOFs and Wiki Specs.
Hi, On 06/03/2010 12:05 PM, ext Dave Neary wrote: > Hi, > > Dirk Hohndel wrote: >> On Sat, 29 May 2010 02:04:23 -0600, Andrew Flegg wrote: >>> Firstly, this would probably be best on the forum - or meego-community >>> at a push - as this is where the conference is being planned. >> >> Is it? That's a bummer as I am hardly ever on the forum (email based >> person - never figured out how to be able to track an active forum and >> not miss stuff). What Andrew means is that the MeeGo Conference is an activity coordinated by the Community Office, and the default channel of communication of this team is http://forum.meego.com/forumdisplay.php?f=5 There are several threads about the MeeGo Conference there already and until today nobody had questioned that. meego-dev is about platform development so definitely it doesn't look the right place to have all the conference planning discussions. If you have better alternatives please raise them up. >> Some searching on the forum seems to indicate a bunch of threads on >> location (that's settled - it's Dublin), on social events (outstanding), >> but I don't seem to see any current discussion on format or content of >> the conference. Am I missing something? What is missing is you starting that discussion since you are the coordinator of the conference content. :) > Last I heard there was a small group of 4 people responsible for > content. I don't know how/where they're working. That group is Thiago, > Carsten, Mr. Meeks and (ahem) you. Yes, as explained at http://forum.meego.com/showthread.php?t=95 PS: you can subscribe to forum threads and get an email whenever there are updates. Not perfect but useful if you don't want to check the forum regularly. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Summit - Structured brainstorming format in the form of BOFs and Wiki Specs.
Hi, On 06/03/2010 01:03 PM, ext Thiago Macieira wrote: > Em Quinta-feira 03 Junho 2010, às 10:42:31, Dirk Hohndel escreveu: >> So in your vision the MeeGo Conference would be where all the features >> for the next version of MeeGo are decided? Given that we are currently >> targeting two releases a year but just one conference a year... that >> seems mismatched. I also wonder if this process is actually the best use >> of time for the conference, but I'm open to discussion here. > > I think we should have this kind of gathering, to decide together on the main > direction to take in the next 6/12/24 months. But it's *not* what we have > planned for the MeeGo conference. One day there will be a public roadmapping process done at a MeeGo project level. On top of this specific projects may have their own planning activities. No mater how, ideally the plan for the release is public and fully committed by the time the release starts. The MeeGo Conference is indeed a good venue to discuss the direction of the MeeGo platform and related projects, but waiting for a MeeGo Conference to agree the roadmap of a next release sounds too risky. > I don't think it's feasible to have it right now twice a year -- let's get up > and running first. And it's a high cost to send the people who are relevant > to > these discussions, as opposed to presenters and only those who are interested > in the event itself. > > On the other hand, it makes sense to attach this developer gathering to the > conference, to save costs. > > So I propose that, for this year, we stick to the format we have planned and > use the unconference day for this kind of work. I suggest that the people > interested in this thread organise themselves: prepare a section of the wiki > for registering the unconference sessions. The organisation can help you find > out how many rooms there will be available. I won't be surprised if another MeeGo events emerges by the time the first 2011 release is out. There haven't been discussions about this but it makes sense. Probably smaller and more focused on the project maintainers and platform developers directly involved. Maybe in the future we even have it the other way around: the big massive conference happens in Spring when the Northern Hemisphere enjoys good weather and then in the dull Autumn we have the smaller one with basically full time employees closed in a big room during 3 days because anyway it's dark and raining outside. ;) Or find alternative Southern venues and meet every six months but always in Spring. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Forum / mail integration (was MeeGo Summit - Structured brainstorming...)
((Cross-posting on purpose with meego-community since it is the topic of discussion)) Hi, On 06/04/2010 01:15 PM, ext Dave Neary wrote: > Is there a good reason not to use Google Groups, aside from, you know, > the whole Google thing? By Google Groups do you mean Usenet newsgroups? It's been a while I haven't used Usenet but isn't it that Usenet as great gateways for both web and email integration? If you have a Google account you can use the interface via Google Groups (but really, we cannot require to have a Google account to be involved in MeeGo discussions). An idea to consider. But let me go down to things we can fix right now. I agree with Dawn that the Forum/Mail thing is not resolved and we need to have one channel useful for the core purpose it needs to accomplish. I have personally no problems with mailing lists or forum (I start to have problems about Mail/Forum discussions though) ;) Concrete proposal by-passing the concerns about "a forum is also important": - The maemo-community mailing list is the one and only channel for the Community Office coordination - http://wiki.meego.com/Community_Office coordination. Anything related to Community Office meetings and tasks is discussed and coordinated there. If you are responsible of a Community Office task you need to be there. If you want to push your agenda to the Community Office you have to do it there. - Every task committed chooses the best channel to get things done. The default is a report at http://bugs.meego.com, but meego-community, http://forum.meego.com or else can also be used when they make more sense. Up to the owner of the committed task. - Community Office decisions and meeting minutes are communicated to the rest of the project via meego.com blogs (details to be defined). - In addition to this, anybody can start any community related discussion in meego-community or forum.meego.com. For instance, someone not interested in the Community Office activity can stay in the forum and forget about the mailing list. Someone interested only in the Community Office activity can stay in the mailing list and forget about the forum. This guideline can be revised when we have a better technical setting, but they could be implemented right away with the current infrastructure. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Next TSG meeting on August 18
Hello, We don't have quorum for tomorrow's Technical Steering Group meeting. The participation of the key people is confirmed for next Webdnesday, August 18. Let's chat next week, then. More details at http://wiki.meego.com/Technical_Steering_Group_meetings -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] meego pad
Hi, are you asking me? On 08/27/2010 02:17 PM, ext Randolph Dohm wrote: > quim, is it true, that nokia meego pad will be available for 1&1 ? > http://www.heise.de/newsticker/meldung/1-1-laesst-SmartPad-auslaufen-1068272.html > are there any strategic alliances besides automotive? First, my knowledge of German is good enough to see no relation between your question and that page. Second, your question is totally of topic in this busy mailing list about MeeGo platform development. Please stay on topic. If you want to have light discussion about MeeGo consumer topics http://forum.meego.com might be a better start. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Interesting discussion. Thank you! On 09/08/2010 09:28 PM, ext Arjan van de Ven wrote: > I think there's a more general "what is MeeGo" thing behind this. Yes. Let's agree first in the concept and then sorting out the technical aspects will be easier. > For some, MeeGo is *the* distribution, there is only one, and because of > that, things that add to one will add to all of MeeGo > > For others, MeeGo is "the reference", where the assumption is that many > companies will make variants that they all want to call "MeeGo", but > that are all different in some ways. Here we are talking about libraries and apps. The backbone is the MeeGo official API, provided by the MeeGo Core. I guess we all agree that no matter how many variants companies and communities do around MeeGo that official API needs to be there as a minimum requirement. Well, this is a starting point. Let's look first at MeeGo Extras: If the developers targeting MeeGo Extras want to support libraries not present in the MeeGo architecture then they should be able to do so, as long as their packages work on top of MeeGo Core. And this should allow developers targeting MeeGo Extras to use those libraries. The MeeGo Community OBS and the MeeGo Extras QA process should help porting, developing and maintaining these libraries and apps not sitting directly on top of the official MeeGo API, but functional in a stock MeeGo OS. The open development of MeeGo allows the maintainers of this Extras components to test them against new releases and fix/negotiate in case of breakage. In practice, this Extras maintainers are some of the earliest and best testers of the unstable platform. Now, what about the MeeGo vendors? Those vendors sticking to the pure MeeGo stack with only some UX customization on top can benefit directly from MeeGo Extras - or their users can if they wish and their system is open enough to add the Extras repo. If they are not interested, no problem. Those vendors adding their own libraries on top of pure MeeGo can solve the problem of collisions with MeeGo Extras by assigning a top priority to their repos (I guess) or taking more drastic measures promoting their own packages and basta. Or just like the MeeGo maintainers, they can fix/negotiate with the Extras maintainers. Those vendors doing deeper changes in the fringe of MeeGo compatibility know anyway that they are playing with fire. If they want to get the benefit of Extras they will need to do some homework. If they just want a closed system without Extras input then there is no problem to solve. In any case if there is a conflict the guidance comes automatically from the MeeGo API and the MeeGo Core. The open development and the explicit willingness to sit on top of newest releases as soon as they are ready for production just makes the conflict resolution easier. > The first model is what Maemo used to be, there was only one Maemo; the > second model is what Moblin used to be, with many variants. I think there is a way to benefit from the beautiful aspects of both platforms. The versatile architecture of Moblin (compared to Maemo) was beautiful. The proliferation of application developers and community libraries (compared to Moblin) was beautiful too. > Frankly, I see MeeGo only be able to follow the second model; there is > more than one company doing products with MeeGo (heck, Novell already > has a variant), and thus there will be variants. > The moment you have variants, where you allow the variants to add their > own stuff on top, you can't have an "Extras" repository that works for > all of these variants anymore, only one that works > for the reference. But we can't stop Extras because of the variants. On the contrary, a strong and useful Extras will only help those variants to differ from the MeeGo reference only when there is a good business reason to do so. Any step you do out of the MeeGo way might cost you hundreds of apps not available to your users. Lat but not least: since the MeeGo launch and even before "open source innovation" has been a driver of this 'joint platform developed under the auspices of the Linux Foundation'. Limiting the MeeGo umbrella to the official stack and API and limiting that innovation to companies able to create their own ecosystems is imho limiting the MeeGo potential too much. And for no good reason? > And once that's the case. you really can't say "oh but you can > depend on anything that's in Extras". Or even "you can depend on things > that are not in the required set" to be honest. I agree: the MeeGo project should put the emphasis on the official MeeGo API as the only reliable dependency. This doesn't mean that we must cut the Extras initiative pushing them out of the MeeGo umbrella. -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote: > It sounds reasonable to me. Keeping all non-Core dependencies within > each application package would be the best and the most clean technical > solution of many issues, but it has some drawbacks (as it was discussed > in the thread): > - potential conflicts of single instance services; This is why having MeeGo Extras within the MeeGo project as a reference is more useful than having no reference at all. The Extras maintainers must follow the MeeGo unstable releases and make sure the packages maintained there just work. If Vendor X needs to provide packages that are not part of the official MeeGo, their default reference will be MeeGo Extras. > - wasted disk space that is essential for some devices; Having MeeGo Extras as a reference helps resolving the conflicts and duplications there, instead of just pushing lazy/ugly hacks bloating users memory space. > - extra security risks in view of the fact that all instances should be > updated by all providers independently; Again, this enforces everybody's interested on having a MeeGo Extras QA process where anybody can look and report issues. And where a system is in place to demote packages, push updates, etc. > - lack of tool support that is required to make the approach easy-to-use > for application developers. If an app developer is looking for the easy-to-use then they must go for the official APUIs and SDK, which will probably include an easy way to publish to the AppUp, Ovi, etc. Developers that decide not to go through the official route can still find a reasonably easy process to get their packages at MeeGo Extras-devel, and from there promoted through the QA process. Hundreds of app developers have done this already at http://wiki.maemo.org/Uploading_to_Extras-devel The MeeGo Community OBS might make this process even simpler. > At the same time, the MeeGo Extras way leads to some concerns as well: > - How to guarantee acceptable quality and ABI stability of shared > packages from MeeGo Extras? Is it enough to just explain to application > developer consequences of her/his choice? The last I have heard was that the idea is to have a QA process in place. See http://wiki.maemo.org/Extras-testing to learn how Maemo has been organizing the community QA process. There have been some discussion to implement a process taking the lessons learned from the Maemo experience. What you see in that wiki page may not translate directly to the MeeGo Extras QA process. Tero Kojo is the person responsible of this. See http://wiki.meego.com/Proposal_for_Community_Application_Support > - Should MeeGo Extras packages be compliant themselves? Define "compliant" in this context, please. :) > - Should we impose MeeGo Extras package naming scheme to MeeGo vendors > and vice versa? (Otherwise, different names of the same package may lead > to issues with simultaneous installation of applications depending on > that packages) See my point above about having Extras as a reference and place to negotiate solutions to conflicts and avoid the lazy/ugly hacks. > - Should we have several grades of MeeGo compliance applications? And > what is a purpose of the "MeeGo compliant application" concept? For clarity, I would restrict the word "compliance" to the official MeeGo compliance based on the official API. "A MeeGo compliant app runs on any MeeGo compliant device". If we dilute this we are opening a Pandora's box. The MeeGo Extras stable repository would contain apps tested to work on top of official MeeGo releases. No "compliance" word needed: they are "extras". Vendor specific compliance requirements not shared by the rest of MeeGo have nothing to do with MeeGo and are out of scope here. -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/13/2010 01:28 PM, ext Warren Baird wrote: > On Mon, Sep 13, 2010 at 3:53 PM, Quim Gil wrote: >> >> >>> - Should we have several grades of MeeGo compliance applications? And >>> what is a purpose of the "MeeGo compliant application" concept? >> >> For clarity, I would restrict the word "compliance" to the official >> MeeGo compliance based on the official API. "A MeeGo compliant app runs >> on any MeeGo compliant device". If we dilute this we are opening a >> Pandora's box. >> >> The MeeGo Extras stable repository would contain apps tested to work on >> top of official MeeGo releases. No "compliance" word needed: they are >> "extras". > > Hmm. That does solve the problem --- but it seems to me that having > Extras - which might well be the vast majority of MeeGo apps, at least > initially - not have some kind of official 'stamp' is a weakness, at > least on the PR side... If the 'commercial' apps can't capture the energy of a successful MeeGo Extras then we have a problem elsewhere, but still you are making a good point. Well, an app in MeeGo Extras passing the MeeGo compliance test *is* a MeeGo compliant app in its full right. Maybe there is a way to distinguish those? A Good Thing is that any commercial store know that these apps run on top of MeeGo without needing additional dependencies, and they also know these apps have gone through a transparent QA process. > App developers might well view it as a slight that their apps aren't > compliant, and users might well be less inclined to run apps that > aren't officially compliant... Still, the apps in MeeGo Extras relying on unofficial toolkits and libraries would still "work" and even be "stable" but I still think the term "MeeGo compliant" should be avoided. Developers and end users interested in those should understand the implications. > > I think it's valuable to have a set of rules to define "A well behaved > app that should be safe for a user to install" while not going as far > as the current definition of 'MeeGo Compliance', and some kind of > official recognition of such apps. > > I've seen other programs like this that have different levels of > compliance... I could see something like: > MeeGo Conforming App: depend only on things in Extras, compile > successful on the build system and pass a series of automated tests, > etc. > MeeGo Compliant App: what's currently in the compliance spec. > > Apps on the app store would need to be compliant, apps on Extras need > to be Conforming. > > Thoughts? I think we agree on the principles even if we still need to fine tune the words. :) -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/13/2010 01:58 PM, ext Arjan van de Ven wrote: > so here is a catch; if it is part of Extras and "real apps" depend on > it, suddenly "no security updates" is absolutely not an option. If it's part of Extras then it's not part of the official MeeGo release and the MeeGo project is not committed to provide official security updates. The MeeGo Extras maintainers must commit to a QA process that would include a procedure to handle security issues, but that's all. > if apps can depend on Extras being there, suddenly the OS size for the > device becomes much bigger. Not the amount present at ship time, > but the amount the OEM needs to reserve for the OS... because now that's > no longer as well known or bounded. Valid concern. Not having MeeGo Extras will solve this problem, though? The pressure from users to install more stuff is a clear trend. In a perfect MeeGo world all app developers would be happy with the official API but at least today it's not the case. Technical solutions exist. If a vendor wants to have a well constrained device then he can simply restrict the repositories via Security Framework. Another solution is to run unsupported libraries on the extended memory à la Maemo /opt http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs More solutions? If we agree on the principle we probably will find more ways to tackle the specific problems. -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Don't mix app compliance with enabled repos (was Re: Meego spec - for comment)
> > if you really think that Nokia will enable Extras on operator subsidized > > phones... I think you underestimate how much operators will not like > > that. > > > > So why do we want to pander to that in meego.com? Isn't this about open > source values, or did I misunderstand why helping the Maemo Community out > with the OBS was such a huge issue? > > Please don't mix the discussion about application compliance with the discussion about enabling repositories. They are orthogonal. The MeeGo project will offer to MeeGo vendors a flexible approach starting with the Security Framework (allowing fully open and fully closed options) and ending to the gateways to Extras, AppUp, Ovi and whatever else comes. But it's up to the vendors to decide the openness ans the allowed sources for each product. There is nothing really to be discussed about this here at meego-dev. Let's keep the discussion in the MeeGo Compliance until we are all in the same page, please. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Fri, 2010-09-17 at 08:58 +0200, Kellomaki Pertti (Nokia-MS/Tampere) wrote: > This may be completely left field, but from the discussion so far it > seems that it could in fact be a lot easier to bless repositories (or > sets therof) as MeeGo compliant, rather than single packages. Actually I think it's a very relevant comment. A lot of posts are describing a situation Commercial Stores vs Extras/Surrounds when the core question is to restrict application compliance to apps directly based on the official MeeGo API or not. MeeGo Extras/Surrounds would benefit from separate repos for apps depending directly on the official MeeGo API (Qt / WebRuntime) and all the rest. It might make a lot easier for MeeGo vendors to include the 'strict' meego.com repo in their products or marketing. On the other hand, what are the deep issues underneath this long discussion? Let me try: - The belief that the MeeGo official AOPI is not enough to satisfy developers. If this is true then it's a problem in itself and needs to be fixed by improving the API. - The belief that there will be a significant amount of apps using other APIs / toolkits. Which ones, though? PySide? KDE libs? Hildon? This discussion would be better grounded if sustained by real maintainers of these toolkits & bindings. - The belief that having a "Compliant" flag will open the door of these apps not depending directly on Qt / WRT to make it to the AppUp, Ovi and etc. However, I doubt so. For these stores keeping a consistent catalog for Qt & WRT across different UX, architectures, products and vendors is already a considerable headache. They will look at any options helping them to increase number and variety of apps, but probably not before those alternative APIs and toolkits have proven themselves. - Even the perception that the Compliance restrictions go somehow against free software development. I would accept this one if the MeeGo project would refuse the idea of hosting an own Extras/Surrounds repo. But if this exists then developers concerned about software freedom can use them, and users concerned about software freedom can buy devices open enough to run that software. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote: > Forcing Extras out of compliance means you are disenfranchising your > community. No. Hosting any kind of free software apps and libraries regardless of their official/unofficial , compliant/non-compliant and unstable/stable status means that everybody is welcome at meego.com. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo?
On Fri, 2010-09-17 at 14:19 +0200, Kellomaki Pertti (Nokia-MS/Tampere) wrote: > Are there any plans re upstart in MeeGo? I'm asking because we have test > scripts that use initctl to control daemons, so the scripts need to be > modified if there is no upstart. Now there is a meego-architecture list devoted to discuss topics like future technology selections. http://lists.meego.com/listinfo/meego-architecture Please continue this thread there. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
On Mon, 2010-09-27 at 14:58 +0200, Tamminen Eero (Nokia-MS/Helsinki) wrote: > Do you have an escalation route for driving this issue? > Who's responsible for MeeGo bugs & QA in general? http://meego.com/about/governance/quality-assurance -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] TSG meeting cancelled - sorry
Hi, There was a TSG meeting starting in few minutes but we must cancel it due to lack of quorum. Sorry about that. We will communicate the new date and agenda as soon as it's ready. For more information about TSG Meetings check http://wiki.meego.com/Technical_Steering_Group_meetings -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of N900 as a MeeGo platform?
Hi, On Tue, 2010-10-12 at 16:49 +0200, ext Dave Neary wrote: > Hi, > > I just noticed in the agenda for the TSG meeting tomorrow (which I won't > be able to attend) the following agenda item: > > * Nomination: Nokia N900 hardware platform maintainer: Carsten Munk. > * Valtteri Halla/Nokia is proposing to nominate Carsten to replace > Harri Hakulinen in this role. Carsten is a renowned developer and > founding maintainer of the mer project. Nokia supports Carsten and > development of MeeGo for N900 in various ways including allocating a > team of developers led by Harri and providing technical support. > > > What does this mean for the N900 as a reference platform for MeeGo > development? Please feel free asking at the TSG tomorrow, but in the meantime: Nothing new? > Does it mean that Nokia are basically moving on, and > leaving Carsten in place as a life-buoy for the N900 version? No, it means that the guy that is doing a great job gets the corresponding role explicitly assigned. > As a > casual observer, it could look like Nokia are withdrawing official > support for development & maintenance of MeeGo on N900 and leaving it to > be "community" supported. But "casual observers" were saying that the MeeGo meritocracy requires key roles being taken by non-Nokia and non-Intel contributors... Carsten is on top of these releases and he knows every single detail of them. Just check in bugzilla, mailing lists, IRC... It's a logical step and I'm willing to see more roles taken by non-Intel/Nokia people as they become the experts and drivers in their areas. > Can those involved elaborate on what this would mean for N900 MeeGo > users, please? For N900 users? Definitely nothing. The future of the N900 as official MeeGo hardware platform depends on the availability of more suitable ARM hardware to test. At the moment there is nothing in the horizon challenging the N900. This has nothing to do with Harri or Carsten being in charge of the releases for the N900. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Trademark compliance, name usage, etc.
On Thu, 2010-10-14 at 17:40 +0200, ext Greg KH wrote: > Of course, a "real" cease-and-desist order would have to be filed for > any of this to be able to be properly discussed, which I think, is the > proper next step of the Linux Foundation if they really wish to persue > this issue. Greg, do you enjoy legal escalation? I'm sure nobody in this list does. In marketing terms "Smeegol" is a perfect example of MeeGo brand dilution. You wouldn't have called it Smeegol if there would not have been MeeGo in the first place. Have you acted with malice? No Have you done it secretly? No Are you pursuing a success damaging the MeeGo project? No For all this reasons a cease-and-desist would be a bad (and probably pointless) approach. This is about common sense and community dialog now. You warned about your intentions in this list weeks ago. Somehow the Linux Foundation & MeeGo TSG didn't react at the time in the way they did when the posts about the Smeegol release came under their radar. Yes, this problem could have been solved with a simple rename weeks ago. Now you have extra work with a name change and the corresponding explanation. Still, Smeegol *is* a precedent of brand dilution and bad precendents are really bad for young brands. Ultimately your project depends on a bruight and successful MeeGo project and we kindly ask you to help on that by renaming your even younger project. Please pick something unrelated to "MeeGo", keep using the software following the linceses of each component, keep helping to the propagation and improvement of that software and all we will be happy in this happy MeeGo family. At the end, is it a big deal? Anybody in the free software community has seen plenty of project re-brands for various reasons, most of them without much hassle or big deals. Sorry for the hassle and thank you for your understanding. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions on N900
On Tue, 2010-10-19 at 21:49 +0200, ext jaume dominguez faus wrote: > Hello list. This mail might seem a bit off-topic. But I don't know a > better place to find the answers I need than from the people who is > daily dealing with this. It is off-topic. :) If you need to know anything about Maemo and the N900 you should search and ask at http://talk.maemo.org . Similar questions have been made already there. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote: > This is why I was wondering why we're not using hardfp *now* for 1.1.0. > > We shouldn't be breaking binary compatibility. > > We shouldn't be softp either. Just reminding the obvious, but as for today there is no major MeeGo products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras for MeeGo. Even the MeeGo SDK itself is in its first iterations. I see Arjan's point made from an architecture consistency point of view - but from a marketing point of view 1.2 and following releases will be a lot more used and scrutinized than 1.1.x releases. If this soft-hard break is unavoidable then it seems that now it will create a lot less hassle than in 6 months or later. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] About Final Meego1.1 Release
On Wed, 2010-10-27 at 14:31 +0200, ext Rohit Baravkar wrote: > Hi, > As per release engineering plan, final Meego 1.1 was planned to > release between 25th to 27th of October. > Is there any change in plan? When the source packages for final Meego > 1.1 will be accessible in Meego source repo? No changes in the plan. You can follow the meego.com release publishing status at http://wiki.meego.com/Community_Office/Marketing/Meego.com_1.1_update -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo 1.1 Handset Calrendar name bug ?
On Thu, 2010-10-28 at 20:27 +0200, ext Pain Chung wrote: > Calendar app shows wrong name. It shows 'meego-handset-calendar' > instead of 'Calendar'. > I found this wrong name below file. > > > '/usr/share/applications/meego-handset-calendar.desktop' > "Name[en_US]=meego-handset-calendar.desktop" > > > Is it any reason ? Please check if there is a bug filed for this at http://bugs.meego.com and if not you are encouraged to file it yourself. The same goes for other localization issues and any bugs you find in the 1.1 release. This is a high traffic mailing list and actually Bugzilla is a much more efficient way to report the problems to the people that can actually fix them. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Answering the original question: On Thu, 2010-11-04 at 12:25 +0100, ext Bogdan Cristea wrote: > On Thursday 04 November 2010 13:20:03 you wrote: > > Not to be a smart-ass, but define "compliant", please > > By that I mean smartphones on which MeeGo has been successfully installed and > the APIs with various sensors (GPS, video) are more or less working. A > similar > list exists for Linux distros, hardware from vendors known to work with some > distro. Usually, these lists are made by users. We ask everybody to help keeping http://wiki.meego.com/Devices up to date. It includes a Handset category. You might find more experimentation at http://wiki.meego.com/ARM - a page that also welcomes all the editing love and lists the progress done with some hardware that might qualify as 'smartphone'. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Compiling MeeGo roadmaps, plans, backlogs...
Hi, public roadmaps easy to find are an essential part of an open project. If your MeeGo project team has some kind of plans please make sure they are publicly documented and listed at http://wiki.meego.com/Roadmap I'm chasing the owners of Core, SDK and the UXs but there are more plans around and I'm not sure if I've caught all of them. Note also that keeping your roadmaps updated is just as important. Some of the pages linked at the Roadmap page are already old. Thank you. -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NQS vs MeeGo SDK [Re: MeeGo 1.1 SDK beta released]
Please continue this (very interesting) discussion to meego-sdk, where it belongs. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] "MeeGo" vs. "Platform" API ambiguity
On Thu, 2010-11-11 at 14:45 -0700, ext Wichmann, Mats D wrote: > meego-dev-boun...@meego.com wrote: > > On Thu, Nov 11, 2010 at 01:27:44PM -0800, Andy Ross wrote: > >> The subject of how the "MeeGo API" is defined came up in the TSG > >> yesterday, and against my better judgement I managed to inject myself > >> into a discussion about standards. > >> > >> The way it's currently phrased, the MeeGo API is a very limited set of > >> libraries (Qt, QtMobility and GLES, plus the web framework). > >> Everything else is reserved for the "Platform API", which carries no > >> promise of future availability. > > > > I have just recently read the developer pages on this very > > subject, and I was surprised to find the distinction, that Meego Touch > > Framework and the Web Runtime are in a "Platform API" with > > warnings against using them. More clarification is indeed > > needed, as far as I am concerned. > > In the case of these two, it's a question of maturity. > Since the current versions aren't fully mature, it can't be promised > they won't change in the next version. There's nothing to prevent, > and indeed it's the intent, to promote these to high-guarantee status > once the right level of maturity is reached. Actually this is not accurate. The mid term future of MeeGo Touch Framework and Web Runtime is not clear next to Qt / Qt Quick and HTML5. The components are in MeeGo 1.1 and the APIs are there for developers, but a good advice for new projects is to check Qt Quick first. About deeper APIs in the platform, the reason to push a well controlled set of APIs around Qt and Qt Mobility is not only based by the fact the components "will be there" in the future. It's also related to the possibility to manage the MeeGo API properly, offer a compatibility promise towards future releases, simplify the developer story, documentation, training materials... For the big majority of application developers targeting MeeGo, the Qt / Qt Mobility APIs should suffice (plus OpenGL ES for the specific segment willing to use it). If any of these developers is not finding what he is looking for, then bugs against Qt Mobility are welcome (I asked the maintainers and this is the answer they gave). The MeeGo Compliance needs to sit on a clear principle, and the MeeGo API described at http://meego.com/developers/meego-architecture/meego-architecture-api-view is clear. If the implementation of the principle has some problems today (functionality not covered by APIs, or APIs not connected the MeeGo backend) then we need to know what is missing and work on the implementation and fixes. Bypassing a problem by hooking directly on a deeper API solves a problem today, but still the bug reports are needed to help the Qt Mobility team working on the right items. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Packaging Guidelines group tag for end user applications
On Tue, 2010-11-30 at 11:26 +0200, ext Niels Breet wrote: > Hi, > > It seems that the list of group tags are specified in the Packaging > Guidelines: > http://wiki.meego.com/Packaging/Guidelines#Group_Tag > > This list looks like it needs some attention as the options are very > limited and some are not relevant for a mobile devices platform like > MeeGo. > > Can we come up with a list of categories which can be used in > application store like apps and websites to sort end-user > applications? A definitive list in the packaging guidelines would > prevent unrestricted growth of groups used by developers and would > make it a lot easier to discover apps through category lists. Very good point. This was a topic of discussion in maemo.org some time ago: http://wiki.maemo.org/Task:Package_categories (I'm not sure if this is the most recent page) Input from AppUp and Ovi would be useful. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
On Wed, 2010-12-01 at 09:21 +0100, ext Till Harbaum / Lists wrote: > Hi list, > > i would really like to release some ready-to-run beagleboard meego image. But > unfortunately we are missing a place to store files in the gigabyte range for > public download. > > Other meego projects and even the n900/n8x0 adaption teams are facing the > same > problem. > > Can we please have such a place? Can you please submit a request at http://bugs.meego.com ? It's ok to send an email to meego-dev pointing to that request so anybody interested can chime in and follow, but discussing this whole request here is a bit overkill (with thousand of subscribers). Even meego-community would be more on-topic since it's there where the community infrastructure is discussed. Thank you for your understanding. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Agenda of TSG meeting *today*
Here is the agenda for the Technical Steering Group meeting held today - actually in a bit more than one hour, at 20:00 UTC. * MeeGo Compliance discussion update (Mark Skarpness). http://wiki.meego.com/Quality/Compliance * Quality Team nominations (Veli-Pekka Vatula). http://wiki.meego.com/Quality/meetings/QANominations101201 * Toolchain Change Proposal for MeeGo Release 1.2 (Jarmo Kant). http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal * Next TSG Meeting * All other business (Open Items and General Questions) More information about Technical Steering Group meetings at http://wiki.meego.com/Technical_Steering_Group_meetings See you there! -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo Conferece: non-commercial proposals are also welcome!
CROSSPOSTING ON PURPOSE - please reply only to meego-events. Loud and clear: 100% community - non-profit - hobbyist submissions are also welcome at the MeeGo Conference http://sf2011.meego.com/program/call-session-proposals Just like in Dublin. Hurry up! I'm sending this because I just realized at #meego IRC channel that many people thought the San Francisco conference was *exclusively* for commercial parties and topics like e.g. apps.meego.com or the community OBS were not wanted. Good that I asked and we found the problem. I'm not part of the content committee but I believe everybody in the conference organization assumes that any relevant community activity related to the MeeGo project is worth a submission proposal. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] improvement things of Symbian 3, Meego for mobile phones should have fixed
On Thu, 2010-10-28 at 18:44 +0200, ext Randolph Dohm wrote: > N8 is a cool mobile phone, but has only one hardware button. Your email is totally off-topic in this list and the MeeGo project context. The MeeGo project doesn't develop any devices. If you have feedback about Nokia products you might want to try http://conversations.nokia.com/ -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Where to post bug reports for MeeGo 1.2 Harmattan?
(((This topic goes beyond meego-dev - I'm answering you here but if you have further questions I encourage you to go to forum.meego.com - Handset or Application Developer Support. Thanks!))) As explained at http://forum.meego.com/showpost.php?p=22953&postcount=77 & http://forum.meego.com/showpost.php?p=22981&postcount=87 http://developer.nokia.com/bugs This bug reporting tool focuses on *developer issues*: platform, SDK, documentation, etc (the open source components). However, we have added a component "Device" where the developers getting the devices can also file bugs they are finding as testers of the device. After all the discussions (I still remember 'Bug 630' by heart) I think the best is to offer the bugzilla setup in relation to open source platform components and the Nokia support setup for the 'user experience' part. OSS savvy people understand bug reporting, may have a grasp on whether a bug belongs more to downstream or upstream, might look at source code, think of building a patch, discussions on features can happen in the relative OSS channels... Motivated users willing to get their voice heard by Nokia can go to Nokia Support Discussions or Nokia Care directly. Their ideas or complaints can't be addressed openly in a bug tracker as we have seen. And actually an organization like Nokia Care does a good job at summarizing and reporting up the feedback received through different channels (I have seen the reports and I wouldn't have done them better after following 100s of posts and bugs in maemo.org). On 6/22/2011 7:40 AM, ext Carsten Munk wrote: Submit them to your vendor, ie, Nokia (you'd have to ask them for where, because I don't know). Then they will submit it further to any upstream projects they use. The reasoning for this (even when ignoring the complete Harmattan mess) is these steps: 1) A vendor might have modifications to the upstream packages/software or own packages/software he uses. Then he should handle it 2) If no modifications/directly from upstream, submit to the upstream project - it's a bug in that software then. 3) Upstream may handle the issue and fix may trickle down to the consumer through the vendor's path of upgrades If you can replicate an error in MeeGo.com images/components directly, you're of course welcome to submit to those bugtrackers. Example could be a Qt or Qt Mobility issue that happens on MeeGo.com images too. /Carsten 2011/6/22 Andrey Ponomarenko: Hi, Could anybody explain me where to post bug reports for MeeGo 1.2 Harmattan [1]? To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? Thanks! [1] MeeGo 1.2 Harmattan [2] maemo.org Bugzilla [3] MeeGo Bugzilla -- Andrey Ponomarenko Department for Operating Systems at ISPRAS web:http://www.LinuxTesting.org mail: aponomare...@ispras.ru ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
