[meego-packaging] Extras/Surrounds Re: [meego-commits] 11098: New package Trunk:Testing/kernel-adaptation-oaktrail
shane.bryan at linux.intel.com
Mon Dec 27 17:50:12 PST 2010
On Fri, 24 Dec 2010 00:50:38 +0000
David Greaves <david at dgreaves.com> wrote:
> Let's take this to meego-community if there are replies.
> On 21/12/10 17:38, Shane Bryan wrote:
> > Which, as Arjan suggested, is EXACTLY what a community based
> > project is supposed to have, "inflowing packages people are
> > submitting without asking anyone". If/when we get there, I'd call
> > that a measure of success.
> > <tangent>
> > This might not be such a problem if the community OBS would get it's
> > act together and start accepting SR's to Extras (or Surrounds, or
> > *any* non-home project). I've got a package I submitted to Extras
> > 3 weeks ago now yet it's still sitting there with no action and
> > no visibility as to what the hold up is, or how much longer it
> > will sit there :/
> > It's beginning to feel alot like the Apple AppStore submission
> > process, a black hole.
> > </tangent>
> > Shane...
> "Get our act together..."?
> May I just say a heartfelt "sod off!"
You may, and my apologies for a poor (vague) choice of words on my
It was never my intention to be pointing at you, Niels or any person in
particular. Rather, I was pointing at *us*, the community, that I was
under the (possibly misguided) impression this "non-core" OBS instance
was meant to be used (and I thought, operated) by.
I can certainly see though now, in hind sight, how my choice of language
came across completely wrong.
> You do know that the community OBS is not actually a sentient OBS?
> A team of *2* of us have been working our arses off on this for
> months (mainly in our own "spare" time) with very little support from
> anyone else in the community (including the -dev area, the maemo
> community or the meego engineering people - who have a fair bit of
> experience with OBS setup and who have contributed precisely
> *nothing* to the community side - presumably because they're not
> being paid to do so). Don't give me any shit about the MeeGo
Yes, I do know this, and recognize that the work you have done is
gratis and on your own time. I have said as much in private emails
when you were helping to get my build.pub.meego.com account activated.
Again, I never meant to give any impression otherwise!
I can't help with the problems of contributions from "meego engineering
people" as I'm not one of them (I don't think... I know squat about
*how* OBS is setup, configured and run).
As for support from the community, I did ask some questions in our
personal "Community OBS account" email exchange back in November, to
which you pointed me at the Repository Working Group proposal.
What, I guess, is missing then is the call to action, or a detailed
list of the "TODOs" that we, the community, can sign up for and start
doing. If it exists, my regrets for not knowing where, and I welcome
another public trashing if it will help ;)
We've also had some exchanges by email, IRC and even via the
rejection message XFade provided ($ osc request show 1) on my original
package SR, all of which I am very grateful for and helped to set
expectations better than they had been.
> Oh - and to even vaguely make this work in a professional manner
> we've ended up taking on sysadmin roles for the entire meego.com
> infrastructure. Which is why you'll find the meego.com public OBS
> actually works with your meego.com account. (yes, now you ask, Niels
> and I spent *our* evenings earlier this week configuring some new
> workers so there's some useable grunt in time for the holiday).
And you absolutely have my thanks (and my regrets, that is has had
to resort to this, one or two people doing what we (Intel/Nokia/Linux
Foundation) should have been doing all along).
> So, by way of apology I'm sure you'll be volunteering to join us over
> the christmas break and do some work on the less exciting side of the
> community OBS?
Absolutely! What break ;)
No, seriously, I am not joking... I was out of touch over the 3 day
weekend but that is pretty much the extent of my time off, sad to say...
If you ask anyone I work with, I have, and will, bend over backwards to
get the job done (assuming it's the right job and worth doing, which
getting the Community OBS working is IMHO), above and beyond my "day
job". I've created git trees, project releases and packages for people
who should have done it themselves. I've done image creation and
customization for demos when needed. I've debugged, root caused and
supplied patches for projects I don't own and for HW integration
problems that were not mine to fix, but just needed fixing. I've done
theming, localization, translations, and general policy change and
enforcement, etc... I am by no means afraid to step up or to rock the
boat (be it the one that pays me, or the community) and I do so not
simply as an outsider complaining about what I don't like, but as an
active and dedicated contributor. So I too am no stranger to the pains
you have been suffering and have spent plenty of my own time doing what
others should have been doing, or for which no one else was willing to
take up the cause and get a solution started.
My problem in this case (until now) has been lack of clarity on what
exactly was missing or needed to get the community OBS fully functional.
So far, the links I've followed on the wiki, and emails I've managed to
read/skim have been shy on details as to exactly how exactly *I* can
actually do something to help with the Community OBS (other than start
trying to use it, which as you know, I've done and will continue to
push the envelope on).
> rant over... moving on:
> I've told more than a couple of people (you included iirc) that we
> won't be accepting anything into Surrounds/Extras without some policy
> & guidelines.
Could be... I'm failing to recall or find it anymore though, so I'm
afraid you have me at a disadvantage, and I defer to your memory. It
certainly explains observed behavior more clearly now ;)
> OSI only licenses? GPL3? What's the process for absent devs? If
> someone says "hey, lbt, let me upload a new version of that library
> Shane uploaded" ... do I just let her? What if there's a security
> issue in it? What if you've not been seen in 3 months? Do we accept
> mp3 players? libdecss? What about porn? What about apps with a
> rather rude splash screen? Any patent issues? (Don't forget the
> system physically lives in the "land of the free" so is subject to
> state seizure by the RIAA). Do we insist on a valid bugtracker being
> identified for all Surrounds packages? Must it proxy via a bmc#? Is
> *everything* in Surrounds intended to go into core at some point? How
> do we handle deprecation of applications/libs in core to surrounds?
> Where's the ITP? What about security bugs - do maintainers need to
> demonstrate reliability to handle timely updates? Maybe it's a good
> idea to allow a fast track for simple 'ports' from another distro
> where the security bugs *are* tracked? openSuse?
Awesome list, really!
I mean for real... this is the first time I've seen how detailed and
complex this is from the perspective of those charged (stuck :P) with
From my perspective, I thought this was supposed to be a much more
casual, "loosey goosey", collection of packages that the "community"
decided were useful/interesting and just sort of organically grew as a
collection at a common repo URL. Given my misguided understanding, you
can see (maybe) where my frustration was coming from for the delay in
packages getting into Extras.
> Just write that lot up - thanks.
Sure thing, I'd be happy to. But given past experience, saying
something is so, doesn't make it so. And in my case, it seems my
opinions and perspectives are usually overruled anyway, so my
motivation for setting these policies myself is pretty low. Not to
mention, doing it this way isn't very much of a community effort.
Which makes me wonder, when/where/how are these issue being discussed
or debated now? The TSG meetings? Is there even a venue for these to
be vetted out today? I'd gladly participate, but I'm afraid I don't
know how or where.
For lack of anything else tractable, I will add the list above to some
appropriate looking wiki page on meego.com to ensure that list is
captured. We can start using that to tract status and ownership.
Or, maybe we ought to start using the new "Community processes" Product
under the "MeeGo Policies" classification in BMC? What do you
> I'm not just trying to be anal : so far my general policy for *home*
> projects is "OSI, nothing illegal and don't take the piss". We may
> (or may not) need a more formal one.
So this is "your" general policy, but is it documented? If not,
mind if I at least add it to a wiki? Should it be approved by the TSG
or the proposed Repository Working Group (RWG)?
Speaking of RWG... what's the status of that proposal? I see it still
listed on the wiki, but nothing about it's status...
> The objective for 'Extras' is to have a repo that is of sufficient
> quality that a vendor *could* enable it on a production device (as
> Nokia did with the N900).
Oh, ok, this is the first I've heard that there are quality metrics
desired for it, and the goal being that vendors *could* enable it.
But do we know of any vendors that *would* enable it? Do we have
metrics and specs from them on what criteria must be met before they
would consider doing so? IOW, are we trying to create a solution for a
"problem" we don't actually have (yet)? Don't get me wrong, I'm not
disagreeing with the intent, just asking some possibly awkward
questions because *I* want to know... I'm curious that way... feel
free to ask me to "sod off!!" again ;)
> 'Surrounds' is more complex - it probably has to support multiple
> versions of MeeGo to some degree. Apps live longer than distro
Yep, I think I "get" this one better as a result of our previous
> Imagine I have a MeeGo device and there's appX that uses Surrounds
> 1.0a. Eventually it has 70k users.
> Surrounds 1.0b comes out 6 months later and there are new apps using
> Who does the QA on appX to make sure it runs when Surrounds is
> 'upgraded'? (The dev has gone awol).
> So the user now wants appY - which is built on Surrounds 1.0b.
> Actually the apps need the same python lib but need 2 different
> How does that work then?
All great questions... who's trying to solve them and if I can help,
how can I get involved?
> Yes we have some engineering ideas but....
> So I think :
> * Surrounds needs to evolve or it's useles .... so no mapping a
> single surrounds release to a meego release.
> * we must aim to support older applications/surrounds pairs (and so
> support multiple concurrent installs of surrounds onto a device)
I'm happy to help as I can with these, but by no means claim to have
experience running or maintaining a long term SW repository solution.
Just willing to help if/where I can.
> * we need to understand our goals and our resources
This summarizes all I really wanted to get at... that right now, from
where I stand and what I've seen/found hunting the wikis and emails, we
are still missing this "understanding" of the goals, an actionable list
of problems/definitions/jobs that need to be solved, and an
assignment/tracking solution that would allow us the ability to visibly
raise the issue that resources are desperately missing.
I can only speak for myself here, but if I can't tell what and where
you need help, I can't really do much *to* help. And quite frankly, I
do have some reservations on being too involved for fear that simply
working for Intel as my "day job" will make the "community"
resistant to any proposed policies as subversive to the needs of
Intel rather than the project.
It's an awkward (and quite possible unfounded) feeling, yet a very real
concern to me given many comments and reactions from those outside
Intel that I've witnessed over the years as MeeGo has emerged.
With kind regards, and my respect,
Starting at: 17:59 <X-Fade> lbt, sabotage: I wonder if scratch ...
More information about the MeeGo-packaging