On 11 Jun 2011, at 15:22, David Greaves wrote: > On 10/06/11 23:20, Anas Nashif wrote: > > What exactly are you referring to here that has not been upstreamed? Most of > > the work being done in the above mentioned project are new participants. The > > only big changes are to IMGer, but there are loads of reasons for doing so. > > Just that - the big changes in IMGer and the participant and a few small > changes too. We would have been happy to discuss them and look for a joint > solution. > Today we have two image generation tools and participants and two lots of > work being carried out on an 'osc library'. I also saw independent clones of > other tools like BOSS and some of the supporting libraries - I wrote this > email hoping to halt this divergence and find a way to collaborate before we > diverge too much. Li Yi is already now talking about the boss-plugin with me > so that's a great start; thanks.
The amount of work and customisations ti IMGer and the need to get things done in a timely fashion to address many issues are the main reason. IMGer started as an ambitious project, however for our purposes, only 1 part is actually required and that had to be constantly changed to address issues in the environment we are working in and to address constant flow of MIC changes and fixes. since the participant was designed for Nokia internal infrastructure and not for MeeGo, relying on MeeGo specific changes to be accepted and integrated in timely fashion was a major concern. Anyways, it would be great to reset and do things in a collaborative way. gitorious.org/meego-boss is just a staging area for the team before we push to 'infrastructure tools'. As you can see, all of our production participants are already under 'infrastructure tools'. Also, since BOSS and those MeeGo specific participants are in the same git project, I wonder how you did not notice the work before :-) > > On 11/06/11 05:40, Carsten Munk wrote: >>> On 10 Jun 2011, at 22:00, David Greaves wrote: >>>> So... what do you think? Can I expect some more communication and some >>>> proposed patches? >>> >>> Yes, sure. Communication goes both ways as we know. When did you last ask >>> MeeGo release engineering about their requirements and input to the above? > > Every 2-4 weeks at our planning meetings in Nokia I'd ask our MeeGo reps if > they had any requests from MeeGo RE. I say this so you know I tried. So maybe > it's my fault and I should have sent an email out directly? Anyway ... now > here we are. I do not want to hear about Intel or Nokia' internal requirements, that is really out of scope and probably the reason for this confusion. If the project is hosted by MeeGo, documented on MeeGo wiki pages, then it has to serve MeeGo, which it does not at the moment in the current state, since from what I see all focus of BOSS development right now is the N900 DE. I want to see one singe release engineering process for everything under the MeeGo umbrella and the forces joined. Working in silos is really bad for everybody. > >>> Where are all of those requirements and plans mentioned above are coming >>> from btw? > > Ongoing support and requirements from Nokia for 'other internal use'; lessons > learnt in supporting the now defunct Nokia/MeeGo product deployment; the N900 > CE deployment. > >> Anas raises a good point - there seems to be no defined feature process or >> even referred to a place where discussion can go on in :) >> >> I'd propose the following: >> >> * Tie the project somewhere in the MeeGo project - it already seems to be a >> MeeGo infrastructure tools project, so mark clearly it's a cross vendor >> project - it's confusing that the page starts with "Nokia OBS" picture > > OK. > >> * Mark clearly on http://wiki.meego.com/Release_Infrastructure/BOSS that >> (proposed) location of discussion around BOSS is at meego-distribution-tools@ >> mailing list > > Yep - I actually asked for the scope of this list to be extended to include > our products; then when we finally got to the point where we were > using/releasing code I'd forgotten about it. > >> * Establish a featurezilla of sorts for BOSS features (like we have for MCTS >> and MWTS) and use the same model as MeeGo does, that is: >> - Submit a feature description. People/companies can state if they'd like to >> commit resources to do a feature by providing an assignee and a timeframe. If >> there's a assignee, it can go on a roadmap. > > Yep - this was done inside Nokia. I did the wiki roadmap to extract some of > the concepts we'd planned. > >> - Have -all- stakeholder feedback go into the same process, that means Nokia, >> MeeGo RE, MeeGo Apps, whoever. > > Seems reasonable. > >> * Monthly (IRC?) meeting of roadmap review, indicating which features can go >> into the codebase in next release/which won't make it >> >> Thoughts? > > Thanks - useful to have that pointed out ... it's not obvious that it is > missing when you're inside the project. > > I don't have any objections to any of those points. Me neither. Anas > > David > > -- > "Don't worry, you'll be fine; I saw it work in a cartoon once..." _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
