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[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 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"!
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).
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?
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.
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?
Just write that lot up - thanks.
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.
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).
'Surrounds' is more complex - it probably has to support multiple versions of
MeeGo to some degree. Apps live longer than distro releases.
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?
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)
* we need to understand our goals and our resources
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
