18. dec. 2011 22.44 skrev Cristian Măgherușan-Stanciu <[email protected]>: > Hello, > > I just started working on this project this week-end (BTW, I'm alien_ > on IRC), and I already have a few 'fundamental' noob questions or > concerns regarding the way this infrastructure is built and on how we > use our tools such as osc, OBS, gerrit and git :-) Excellent - it's always good to get some basic questions answered, if you can help document this on wiki from my post that'd be lovely :)
So, just to explain why things are the way they are, I need to explain some basic requirements/philosophies for the Mer Core. 1) It should be possible for anyone off the street to contribute to Mer One of the issues we had in MeeGo was that it was bloody difficult for anyone to contribute to it, as there was no sane way for people to contribute to packaging -- the proposed methods were to send a patch to mailing list (very off putting way/difficult), or through a non-obvious process of earning merit and then a meego.com OBS account In Mer, you clone a git repository and submit changes, get them reviewed at http://review.merproject.org (http://wiki.merproject.org/wiki/Contribution for details) - with everything in git+gerrit, including our processes, we ensure that transparency is built into the fabric of the project. 2) Mer Core is supposed to be minimal, serving it's purpose to be a portable Linux-Qt core that people build products using - ie, it's not for end-users, it's for vendors. Though we define vendors as people delivering hardware adaptations, tools, UIs, added-value frameworks or even the lone hacker at home doing a kitchen UX etc. Due to our experiences in MeeGo, we intentionally keep out hardware adaptations and UIs out of the core, as to avoid significant politics - like, discussion of what side of the screen the taskbar should be on. Or intensive backdoor politics due to hardware adaptations politics of chip companies. In Mer, we work together on the things we all have to do anyway, so we lift the shared burden. If you don't believe this is a problem, take a look at the discussions ongoing on https://lists.tizen.org/listinfo/general :) 3) OBS is treated as just-a-builder in Mer Core (but doesn't mean projects on top have to) We have tried OBS as a review and request system and it had/has some serious issues that make it difficult to maintain a sane development rhythm and feedback. Mer Core is built using OBS but in theory, we're not tied to it if something better comes along. 4) Mer should be instantly forkable and it should be easy to set up your own Mer build with ease, without having to rely on online links to the project for daily use In MeeGo we had significant problems with following the Core from a product point of view -- many work days were lost because of the main OBS's obs-to-obs linking API was down or otherwise broken. In Mer, we have 'fakeobs' (or Mer Delivery System), which basically takes a rsync'able snapshot of Mer Core + binaries and it's packages in git and allows you to run a local server to link your OBS to We also wanted to make it easy for vendors to do local modifications to packages, easily rebase if needed and that's where git comes in. The other angle is that the entire core is in git too, so you can fork that for your local product programme. Instantly forkable - we're tired of one or two companies deciding the fate of all our shared work so we want to make it really difficult to shut down the project, so vendors can feel safe building their products using it without risking their entire business going bankrupt because of someone's fetish with, let's say, Motif as a mobile interface. > -I noticed we store the full tarballs inside our repos and in OBS. git > is not good at it and there's a lot of wasted space because of this. > Could we just have the sources fetched during compile time and tracked > by the build scripts similar to the way Gentoo's portage works? I know > that this might mean we should rewrite OBS or ask the OBS developers > to do it for us. Are they accepting feature requests from us? OBS actually supports fetching during compile/commit time. But there's some challenges: 1) Upstream download URLs aren't always up 2) Vendors typically want one source dump when retrieving a release 3) fakeobs/Mer DS does not right now support tarballs outside git But you're right, it's not that efficient. An alternative to this is a 'distfiles' approach like FreeBSD has it, with references to URLs in a 'sources' file, like Fedora does it, would be plausible and useful. The problem is just that for some pieces of software, in this world of github and git trees, some releases only exist as git tags :) So how does the story work for contributing sources that doesn't exist on a URL somewhere? It would violate the example of making it possible for people to contribute off the street. The main reason for it being like this is simple, we had to get something working and quickly. If you'd like to help with contributing to this part, let's start a discussion thread on this mailing list about implementing this in fakeobs. It's just python scripts and git repos anyway. > > -I find it a bit awkward to use two versioning tools for development, > can't osc just reuse the local git repo instead of implementing its > own versioning. I'm thinking about our git repo having a remote inside > OBS and one in our gerrit, and using just git for all the versioning > instead of osc. I agree with this, -- 'osc' has a plugin infrastructure, it should be possible to integrate better with our packaging-in-git approach. It's just that we haven't had enough time to do so. > > -is the mer infrastructure opened for stuff belonging more to the UX > projects, such as ex-meego packages and so on? could we have our > gerrit and git repos shared with anyone willing to be a part of this > 'ecosystem' and having the same review process, source repo for > package data, documentation and so on for all of them? I find it hard > to find various UX packages spread out all over the OBS, many in > abandonware state, when it would be much easier to find their latest > version in our gerrit. Right now we limit Mer project to efforts that is the core, the activities supporting the core, and activities allowing to utilize the core better. In order to keep our work focused, we keep our maintaining burden low. It also means it's much easier to run things like legal reviews. It is, by the way, really really simple to set up your own gerrit infrastructure. However, it does seem likely we'll have a 'Mer Tools' kind of project, for obvious things like vim, emacs, dot, graphviz and so on. And review/distribution of those. Which would be second-tier of maintaining in Mer, but through same repositories/methods of delivery. To keep the technical level high and politics low in Mer, we encourage people to start own efforts/projects, even small ones, basing on Mer. We can't currently afford to offer infrastructure hosting (we're not exactly backed by a billion dollar company) but we try to let people incubate in the Mer wiki and IRC channels and then eventually, when grown up, to move out of Mom's basement and become your own project :) > > -is there a way to get OBS to integrate better with a workflow that is > a bit more into work with upstream projects? I am thinking about > having it support transparently source directories checked out from > all over the internet, such as from gitorious, instead of pre-built > source archives for everything. I know that many projects are only > available as source tarballs, but there are quite a lot of them who > use git now and we should do better for them if possible. OBS has "source services", http://en.opensuse.org/openSUSE:Build_Service_Concept_SourceService which you can probably use. > > -I would appreciate some documentation on the way we're supposed > quickly iterate on development of applications running inside the > mer/nemo image, perform debugging and deploy quick fixes and not only > for interpreted languages which can be written on the device, but for > example by using the image and the osc/OBS toolchain from whithin the > QtSDK. Is there any and I am just too blind to see it? Right now people iterate with making tarballs and committing to OBS. Theoretically, for many things, you would be able to use MADDE and that SDK to cross compile, but I must also admit our SDK efforts are pretty much non-existing at the moment. But a lot of components are out there, open source. On platform SDK level, we're likely to have a mix of local OBS builds and SB2. On app SDK, it's likely to be Qt Creator + only cross compile on top of a Mer sysroot. > > I'm looking forward for your feedback, and thanks for the patience to > read this, it got longer than I expected :-) > Cheers, > Cristian > >
