On Fri, 24 Dec 2010 00:50:38 +0000 David Greaves <[email protected]> wrote:
> Let's take this to meego-community if there are replies. Good call... > 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[1] 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 part. 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? > Seriously? > > 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 > "community"! 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[1]. 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[2] and even via the rejection message XFade provided ($ osc request show 1) on my original package SR[3], 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 implementing it. >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[4]? What do you think? > 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[1][5][6], 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. Thanks! 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 > releases. Yep, I think I "get" this one better as a result of our previous discussions. > 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 > it. > > 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 > versions. > > 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, Shane... [1]http://wiki.meego.com/Proposal_for_a_Repository_working_group [2]http://trac.tspre.org/merbot/freenode/%23meego/log.11-24-2010 Starting at: 17:59 <X-Fade> lbt, sabotage: I wonder if scratch ... [3]https://build.pub.meego.com/request/show/1 [4]http://bugs.meego.com/enter_bug.cgi?product=Community%20processes [5]http://wiki.meego.com/MeeGo_Community#Proposals [6]http://wiki.meego.com/Proposals _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
