2011/5/4 Mikael Hermansson <[email protected]>: > I must admin that I am getting a bit afraid about how some people starting > to "dictate" what should be included in Meego. <snip>
For good measure, as it may not be clear for everyone, let me take a minute of everyone's time to explain MeeGo basics of daily work. And take it from me - it's a good thing we have a documented process as it has been chaos in the past :) 1) We have a release timeline that is clearly documented at http://wiki.meego.com/Release_Engineering/Release_Timeline and has been there since forever, along with a process at http://wiki.meego.com/Release_Engineering/Process. We have a release plan for 1.2 at http://wiki.meego.com/Release_Engineering/Plans/1.2 This process, timeline and plan affects to anything included into MeeGo 1.2 as well, we're about to ship. :) As well as timelines for delivering invasive changes in 1.3, etc. This reflects in answers from people deepily involved in the project answering on questions like "can we can XXXX included for 1.2" -> "no", as it's very difficult to get anything in unless it's a direct release blocker. 2) MeeGo has meritocratic governance (some may argue this isn't the case, but that's for another thread) and people who are assigned in roles will occasionally have to have the final say in order to move things along. Arjan is the chief architect and then has the final say in a lot of issues due to his role. And that may seem like dictation at times, while occasionally it is hard choices that had to be made - I personally hope to see more transparent process in MeeGo. 3) MeeGo has a requirements process, https://meego.com/developers/requirements where requirements are delivered from working groups, individual contributors, companies, practically anyone, which determines what goes into the MeeGo OS. This makes sure things can be properly QA'ed and features implemented as well as knowing what we will ship eventually. All of this links together so we can put out a good stack for building products on. And there will occasionally be unpopular decisions that will have to be made in order to put out a good release. We can't discuss from now on until forever. BR Carsten Munk MeeGo Nokia N900 Hardware Adaptation Maintainer > 2011/5/4 <[email protected]> >> >> On May 3, 2011, at 4:15 PM, ext Arjan van de Ven wrote: >> >> > On >> >> + Will be developed open soon >> > >> > and is thus completely irrelevant. >> > sorry. >> > too little too late. >> > we're shipping in 2 weeks.... >> > whatever we do afterwards better be compatible with what we shipped, or >> > we will likely pass on inclusion. >> > >> >> I think that it should be completely irrelevant about argue that issue. >> Intel and Nokia both developed their components >> this year as closed, both ended different solution, Intel just happened >> release their result same weeks before Nokia. >> >> >> >> we'd have two incompatible sets of tablet apps. Those that use MeeGo >> >> UX Components, and those that use Qt Components, with either tablet >> >> not able to run the other framework. >> > >> > today, compliance does not yet cover the components, but you're making a >> > very good case that it should.... >> >> And I really hope that we should look this issue in larger context, not >> only as MeeGo tablet, not even >> MeeGo only. Still, largest Qt and Linux communities lives outside of >> MeeGo scene and there >> is no good reason branch own way. >> >> Even Qt components are developed as mobile origin they hopefully will >> replace old QWidget >> API in all Qt applications including all mobile environments and desktops. >> As far as I know, >> we least have now Desktop components for Linux desktops/Mac/Windows, Nokia >> MeeGo Components, >> Intel MeeGo component and Nokia Symbian components. Lets see what Android >> Qt community does... >> >> It is advantage to all developers to get API's harmonized and application >> portability between >> environments as easy as possible. >> >> Just having Qml made already porting easier when C++ part does not need to >> be modified, components >> made it even more easier when there were ready made UI components and >> having common API >> for components makes it even easier. We should still remember that no >> solution removes all porting work. >> There is no automatic way to make exactly same Qml code offering optimum >> user experience in >> desktop, tablet and different handset platforms because just the native UX >> differs between platforms. >> Just as example desktops does not have stacked windows concept at all and >> using concept of fill in forms in >> handset is in most of cases insane, you should use rather scrollable list >> .. >> >> Thing is little bit easier in mobile touch screen devices but no automatic >> magic can provide solution even >> between different device classes with same platform. Compare iPhone and >> Ipad or Android phones and tablets. >> different physical screen size and different resolution affects to mobile >> UI code a lot. >> >> >> Kate >> _______________________________________________ >> MeeGo-dev mailing list >> [email protected] >> http://lists.meego.com/listinfo/meego-dev >> http://wiki.meego.com/Mailing_list_guidelines > > > > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
