You know that scene in movies where the doctor comes out of the surgery with a mask dangling around their neck and a solemn look in their eyes to greet the family who has been waiting what seems like forever in the waiting room? This is that scene. I'm that doctor. freedesktop.org is the patient. You are the family.
freedesktop.org is in really bad shape. There, I said it. Most of us knew it, but now it's been said. The good news is that it's rescuable. The even better news is that people want to rescue it, and some are actually doing things to make it happen.
Let me back up a bit, though. What is freedesktop.org supposed to be? Well, it's supposed to be a place for people working on F/OSS desktop projects to come together and collaborate on shared designs and shared software. It's been successful in bringing together drag and drop, window manager hints, application menus, icon themes, bookmarks, D-Bus and much more. This is valuable work and freedesktop.org is, or at least should, be vital to the F/OSS desktop platform.
It has seen better days, however. Currently it suffers from two major illnesses: administritus and anarchiosis. ;)
First, the administritus. freedsktop.org has infrastructure related to it: a website, cvs and git hosting, a bugzilla instance. This infrastructure is overseen by a group of administrators. These people are expected to be around whenever needed to set up accounts, approve projects and specifications for entry and do general sys admin type stuff as well. This means that they not only have to have lots of time and energy, but have to have a good idea of what's going on in the F/OSS world for each and every topic brought to freedesktop.org. They need that knowledge because it is them who gives the final "yes" or "no" to something being hosted on freedesktop.org. This is a completely irrational set of expectations, and the admin team is therefore performing as one would expect: below the par of what we need.
Now, I don't blame them as individuals .. I just think the expectations are insane and we, the projects, haven't given them enough support. We ought to have more KDE, GNOME, XFCE, etc. project people with admin privileges to help out. We don't, and that probably needs fixing.
However, that's just infrastructure. freedesktop.org isn't, however, infrastructure. freedesktop.org has infrastructure. It is the people who come together to work collaboratively who are freedesktop.org. Think of it this way: if KDE's svn server disappeared tomorrow, a new system would get set up in short order as best the community could manage and we'd get on with it. New infrastructure would emerge. If the KDE contributor community disappeared tomorrow, the existing infrastructure would not magically create new community. Therefore KDE is the community, not the infrastructure. freesktop.org, indeed any F/OSS project, is the same.
So while we work on solutions to the administritus, we are already working on the anarchiosis. What is that?
Right now it's very hard to get things on freedesktop.org, and not everyone trusts the freedesktop.org hosting due to past outages. The result is that we have work being done all over the Internet with little transparency to others.
There's also no way to know who has implemented which specification or uses which pieces of software associated with freedesktop.org. That's bad enough for those of us in the related projects that participate in freedesktop.org, but it's a deal killer for third parties on the outside looking in who'd like to implement support for the platform.
The admin team has the final say in what goes in and what doesn't, which means that people are not allowed to just work on what they want and let things bubble up. It's a top down approach that discourages people and prevents the best decisions possible from being made.
Finally, there is little to no leadership or process applied to freedesktop.org. When two people have a problem with each other, it's up to them to duke it out. When someone wants to use org.freedesktop for a D-Bus service name, there's no way to figure out if that's Ok to do and, if it isn't, no way for the rest of the participants to veto that.
The result is an inefficient system that is completely opaque to most would be participants that revolves around politics, bad decisions and arguments. Anarchy, and the bad sort at that. Several specifications are in danger of becoming defunct, forked or simply never see the light of day because of this case of anarchiosis.
So .. what do we do? We damn well fix it.
To bring some stability to the ills of freedesktop.org I gave it a swift kick in the nuts this past week in order to wake up the slumbering souls that populate the xdg list. This came via Plasma's implementation of the galago notification spec in 4.3. At issue were some very poor moves that accompanied the creation and maintenance of that specification, starting five years ago and continue to today. (I won't go into the details, it's been hashed through enough on the list and there's nothing to be gained by airing it even more publicly.)
Simply put: we had had enough of the shenanigans that are a direct result of the structure, or lack thereof, within freedesktop.org and we put our collective foot down. I wanted to make people own up to how broken things are. I think that was accomplished. Awareness alone isn't enough, though.
To bring some transparency to the process of specification writing, I've gone ahead and created an xdg-specs gitorious project that enables anyone who wants to get involved to do so. I started this a while ago, but it seems more critical than ever now and people are actually using it. If and when the freedesktop.org administration issue gets sorted and it's as easy as gitorious makes it to get involved with the specs process, this repository will move there. In the meantime, there's a README file explaining the proposed process in the repository, people are free to clone and work and I'm happy to add any specification author to the xdg-specs team to manage their spec in the main repository.
We can finally put all our work in one shared place, work together and document it in a way that third parties will know what we are up to. Which drafts are specs and which specs are standards can be deduced in future by simply measuring things in that documentation, such as how many, and which, projects implement which versions of that spec. You don't have to ask for permission to get involved, you just do. That's how F/OSS should work.
There are also the social ills, of course. Since nobody seems to have wanted to do much more than deepen the politics or bitch at each other or sit quietly and try to get something done amidst the chaos, I've done the silly brash sort of thing I do ... I've stepped up and have begun playing the role of facilitator on the xdg list. Nobody asked me to and I didn't ask for permission, but that's why it hasn't been done up until now: nobody is going to ask and there is nobody to grant permission. Catch 22? Nope. Sometimes you just have to step up and do it.
I'm not sure I'm the best person for the job, but at least I'm a person who will do the job. I'll stand in between people when needed, get out of the way when I can and generally make sure things work. However, I have no interest in control, title or even administration rights within freedesktop.org. (I make a crappy sys admin anyways. ;) I just want some oil applied to the moving parts so there's less friction and more movement that we can all live with.
I strongly urge the people who are attending GCDS next week to discuss these issues in person. Come up with some commitments between the projects. Get some people putting effort into these things. Stop screwing around and get your hands moving.
Save freedesktop.org, together. Or continue watching it die, day by day. It's our choice.
Subscribe to:
Post Comments (Atom)
24 comments:
Nice post. I agree with your assessment. Its an important project for FOSS in general. It really does need to work.
Awesome writeup and I love the "can-do" attitude this post radiates. We need that. Thanks!
Funnily enough, I literally just read through the monstrous thread on the XDG list that prompted this. The Plasma screencast inspired me to peek over and see how the systray work is being received (fairly well, from what I saw) and I got sucked into the other one. I was actually about to thank you in a comment on that post, but this looks like a better place now.
Thank you.
You took a lot of (undeserved) heat in that thread, and you took it well. I am glad that despite previous setbacks, you are putting this effort into fixing things. You are an asset to the community. :)
Really good job, well done, I really hope other people step up too. I hope your action acts as a catalyst and you find that you don't actually need to *do* anything.
This will be some fuel to those people who think Seigo's hubris is killing KDE but what we can hope is that their voices are drowned out by people actually wanting to do something for the free desktop.
Leadership and structure is difficult thing for community free software.
My own feeling is that for properly effective, free and democratic system a single structure will not suffice.
It is like political systems. Countries that are free, democratic and stable don't have a single system but rather a set of systems balancing each other (judiciary/prime minister/president/one or two houses of parliament).
For example to have a system fuelled by open debate and cooperation in which people can easily get involved in practical aspects. Then some sort of facilitating "leadership". Directing that the lumbering but useful beast of a committee with appropriate structure for appointing members.
Maybe I am being far from practical when there are issues to be fixed now... but how to build a structure that can solve disputes, act efficiently, include everybody and still be accountable and stagnation-proof is worth thinking on deeply.
Anyway. Thank you again for your work.
Great post. I really hope it will revive fd.o. And you picked the right time. With the desktop summit coming it is a good time to discuss these issues. (Edit: You mentioned GCDS, but I didn't get that at first :)
One slightly OT question: Which the new specs would it be possible to combine taskbar icons and tray icons into dock-like "alive" icons?
And I was wondering why there was no activity on your github repo;)
Thanks for summing this up again. I think a shared, distributed repository is a must-have to improve the situation. As you say, having metadata information listing adopters and stuff is really important and useful for others.
I'm not sure it solves the lack of a well-defined process to get specs accepted though. People will use the fd.o namespace in their in-development specifications and someone still needs to decide which of those specs are merged into the official xdg-specs branch.
Clearly, adopter listings help in making these decisions. But it's not clarified what a spec needs to be accepted yet. We can solve this by actually defining this in the README.
Another thing I think is very important: Publish the information available in the repository on the web. Repositories are nice for the people working on them but for the information to be really useful we need to make them more easily accessible. (I guess you're aware of this and I know that at this early stage, nobody can expect this to be ready. Just thought I'd mention it here for the sake of completeness.)
Unfortunately, I won't be able to attend GCDS. Someone from KDE asked me and pointed me to the KDE sponsorship page but I guess it's a little late for that (and as a poor, poor student I can't really put much money on my own anyway).
@Tom: "Which the new specs would it be possible to combine taskbar icons and tray icons into dock-like "alive" icons?"
the new dbus system tray / notification item service that we've introduced in KDE 4.3. marco has a draft proposal coming together in his clone of the xdg-specs repo.
@jannispohlmann: "We can solve this by actually defining this in the README."
yes, that needs fleshing out more indeed. this needs some consensus building on fd.o first though, and i didn't want to start pushing that kind of structure on my own.
"Publish the information available in the repository on the web"
absolutely; and that's been the intention from the start. :) but first we needed a way to gather the information ... one step at a time....
I hope you don't mind but I just posted it on digg.com in the hope to reach more people. Furthermore I've posted it on my facebook account... let's hope more people will see, understand and help :-)
Some last words for:
Thank you sooo much for what you're doing!
Here's the link:
http://digg.com/d1vDe8
@friesoft: That's the link that redirects back to this page. Here's the one to the Digg page where people can vote it up: http://digg.com/linux_unix/Saving_freedesktop_together
yeah... just realized that.. thx :-)
well.. better safe than sorry -- so here's the link again:
http://digg.com/linux_unix/Saving_freedesktop_together
Yeah, I don't really disagree with most anything you've said. One of the things we did a couple of years ago was to firmly separate XDG from the rest of fd.o; since then, while the rest of fd.o hasn't been particularly horrifically neglected, XDG probably has. Someone needs to step up and exercise some decent leadership; if that's you, cool.
As for the admin side, yeah, it's not great, but I guess it could be worse. AFAICT it's more or less on par with other major FLOSS projects here. Adding new admins definitely isn't a panacea though: it's all great for about two months, but then after the honeymoon period, the interest drops off and we effectively have yet another ex-admin. I think the current count of people who've had root since fd.o got created is close on 25.
I'm not even pretending to be an admin anymore, but one thing that worked particularly well was when vuntz did triage and made sure everyone knew what the status was and what should be done next. I think the drop-off in admin activity since he stopped doing that (not that I can blame him in the least: indeed, I can only thank him for his work while he was doing it) is hardly a coincidence.
As for the rest, well, yeah, we have had to be a bit more selective lately. For better or worse, 'it's on fd.o' seems to be somewhat of a trump card in arguments. I assume you're talking about Akonadi vs. People here: in the end, while we could've given space to either, I wasn't at all convinced that it would've helped either gain any kind of cross-desktop acceptance. No-one I talked to from GNOME expressed any form of enthusiasm about Akonadi at all, nor about People, whereas the best KDE would offer about People was a grudging agreement that Akonadi might possibly be implemented on top of People, maybe, probably not.
Given that we're a git-only shop these days, it's quite trivial to do your initial development somewhere like gitorious or github (I forget which one is Free), or even just on a user directory on fd.o, and then ask for blessing later, when there's some amount of traction or at least basic agreement.
We just said 'yes, yes, yes' in the past to almost everyone that came along, and in the end it came close to diluting fd.o's usefulness, as we were just a git hosting shop, rather than somewhere that actually defined the cross-desktop infrastructure underlying the, well, Free desktop. And at that point, well, we might as well be gitorious + Mailman.
-daniels
@daniels: "One of the things we did a couple of years ago was to firmly separate XDG from the rest of fd.o; since then, while the rest of fd.o hasn't been particularly horrifically neglected, XDG probably has."
given that fd.o was originally set up specifically for XDG, creating such a division and then subsequently letting it drift is a really odd thing to happen.
what exactly is fd.o, then? x.org and a bunch of friends with accounts on a git and bugzilla system?
in any case, you're right that xdg, which really was always the heart of fd.o, has been neglected and it's time that stopped.
it may help if you or someone like you wrote to the xdg list expressly noting its neglect and ultimately its liberation from any perceived fd.o oversight so that those of us on the list may have a free hand in getting it moving properly again.
"AFAICT it's more or less on par with other major FLOSS projects here."
yes, you can find similarly disfunctional projects out there. but there are major FLOSS projects that operate very smoothly on the admin side. the hallmarks tend to be that they automate processes, build an actual working team of people and allow people on the ground do as much of the deciding work as needed.
look at KDE: add yourself to the planet? anyone with svn access can do that. get an svn account? fill out a form on the web, the person you note as your supporting member gets an email along with the admins, the admins push a button or three upon confirmation with the supporting member, and it's done.
yes, there's a lot of work in system administration: maintaining security, server hardware and software, disk, etc. but when it comes to opening the doors to people, it can and should be a low-overhead endeavor.
there will be discussions about this at GCDS from what i've been told, and i hope they can help right that ship.
"Adding new admins definitely isn't a panacea though:"
absolutely; it takes team building and good processes in place to extend the average longevity and a way to pull in new faces on a regular basis to continually fill in gaps that will show up. right now, i couldn't tell you how one might get involved as an admin and it seems from your statements that the average life expectancy is a couple of months for an fd.o admin which is just crazy short.
"For better or worse, 'it's on fd.o' seems to be somewhat of a trump card in arguments."
yes it did become that, because there was no other bar to clear other than "it's on fd.o". so the barrier to entry became where resistance was placed. unfortunately that utterly fails for two reasons:
it discourages new efforts (too high a barrier to entry)
once on fd.o, it still doesn't mean anyone else cares, but there is no way to document that.
the barrier to entry should be low and the path to proving yourself as accepted by multiple projects should be where the bar is placed and that means documenting that process.
it's crazy that we have not documented who uses what, outside of the EWMH spec.
"and then ask for blessing later"
the idea that people need to ask for blessing is indicative of the problem with the way the entire conversation at fd.o gets framed.
i forget: who exactly decided the fd.o sys admins would become the official platform architects such that blessings are asked for and delivered?
"We just said 'yes, yes, yes' in the past to almost everyone that came along, and in the end it came close to diluting fd.o's usefulness, as we were just a git hosting shop, rather than somewhere that actually defined the cross-desktop infrastructure underlying the, well, Free desktop."
i agree; however the answer should not have been to shut down the entrance. because that solved nothing. it just made more friction at the entry gate and caused even more problems.
the solution is to provide a way to allow documentation of acceptance by the various projects such that simply being @ fd.o is not "enough": being @ fd.o and having documented support from various projects would be the goal.
a bit about the Akonadi and People thing:
it's only one example among many, including galago or how people wait for months and months (one guy's been waiting for sth like 5 months?) to get the needed tools to work on specs.
but Akonadi/People is a good example: when i looked at People it was a contacts agregator, mostly for online sources like facebook and gmail.
Akonadi is a full PIM information caching system/solution designed for scalability.
comparing the two borders on absurdity, but only if you are familiar with what each does.
within the GNOME team, there were people in favour of it, such as Andew Cowie who presented on it at L.C.A. during the lightening talks and even blogged about it at one point iirc.
the Akonadi team was in contact with people in the GNOME team as well.
so both the possibility for wide spread acceptance and the proper positioning of these pieces of software were mishandled.
that is only to be expected to happen with a gatekeeper model, as the gatekeepers will never be able to have enough accurate information at hand to get it right enough of the time given the wide spread of topics on fd.o.
however, this is not, as i noted at the outside of this comment, the only example.
the people actually doing the work should be the ones who take on the responsibility for proving their cross desktop nature to the rest of us, and we need to have ways to document that process so we can measure it objectively. this does not require gatekeepers, in fact, gatekeeping fights against this more healthy approach.
a project should be able to tender themselves to fd.o as long as they are infrastructure, cross-desktop in aim and F/OSS.
for software projects (as opposed to specification-only documentation projects) they could put their hat in the ring with a specification and when that gets enough support then the software could be imported into fd.o git.
no permission or blessing or gatekeeping. just participation, documentation and objective measurement.
xdg and fd.o in general: a quick look at cgit.fd.o shows fd.o to be home to cairo, about 17 kits (console, policy, device, christ only knows what else), fontconfig, geoclue, gypsy, hal, dbus, mesa, x.org, poppler, ldtp, apoc, swfdec, networkmanager, gstreamer, ooo-build, and misc. others. so yes, i would argue that xdg is now a small -- though obviously still important -- piece of fd.o.
no-one's going to step in and forcefully try to run xdg as it were. most of us don't have the requisite knowledge, let alone time or interest. there are/will be people who are/will be better suited to that job, so why should they be blocked in favour of someone who's quite obviously going to do a shit job?
i don't see anyone blocking xdg leadership or whatever. i'm not even subscribed. what's the saying again -- rough consensus and working code? is there a lack of either on xdg right now? is there some immense power vacuum such that a leader must be anointed from on high (whatever 'on high' is)?
if xdg is neglected, then no amount of sysadmins, x developers, or dbus hackers emailing the list and saying 'we're cutting you off' is going to really help much. if there's a failure in the xdg community, then it needs to be fixed by someone who will ultimately guide it to a successful end.
admin: it's already pretty simple, and indeed well documented. i don't know what else to tell you.
barrier to entry: there are a hell of a lot of fd.o users (over 500, iirc?). every single one of these users can create a git repository. all we provide to projects is a git repository, web space, and a mailing list. git repositories are truly trivial to obtain (gitorious, github, whatever), and only mailing lists are even remotely difficult. if there's no 'blessing' or whatever, then what are we providing, other than hosting which is trivially obtainable elsewhere, at least temporarily? if the answer lies in the name, then that means we're implicitly blessing any project on fd.o, which means we need to be at least moderately selective in order for that name to still mean anything at all.
platform architects: are we? i wasn't aware anyone was compelled to ship every project hosted on fd.o, nor was i aware that being hosted on fd.o automatically forced all projects higher in the stack to use it.
and we're back to the point that you say we should just say yes to every single project that comes along, yet also keep on implying that hosting on fd.o actually means something ('being @ fd.o and having documented support from various projects would be the goal': are projects any less worthwhile if they're not hosted by us?).
if we turn into sourceforge, then the fd.o name will mean absolutely nothing.
(...)
(...)
akonadi/people: yes, it took an inordinately long time. mea culpa. the general impression i got was that yes, akonadi could be implemented on top of people in order to interoperate with it, but no-one was interested, because the akonadi people wanted everyone to just use akonadi. very few people in gnome were interested in akonadi -- a blog post and a lightning talk mean absolutely nothing, sorry. is anyone outside kde using it today? is anyone outside kde even talking about using it? i suspect the reason for akonadi's lack of cross-desktop adoption doesn't have much to do with its current hosting provider.
i'm going to quote this because i still can't quite get my head around it:
a project should be able to tender themselves to fd.o as long as they are infrastructure, cross-desktop in aim and F/OSS.
for software projects (as opposed to specification-only documentation projects) they could put their hat in the ring with a specification and when that gets enough support then the software could be imported into fd.o git.
no permission or blessing or gatekeeping. just participation, documentation and objective measurement.
none of what you've said here actually means anything. i'll try to summarise my rough understanding, so maybe you can understand my confusion:
a) there should be no gatekeepers, anyone should be allowed to apply (apply? who decides? is it some form of gatekeeper? i didn't realise we were preventing people from 'tendering' at the moment -- last i saw, bugzilla was open).
b) software projects should be allowed to express interest in being on fd.o and once it gets wide support, then it can be imported. how is this different to today? who decides? is the decider not just another gatekeeper?
c) 'permission', 'gatekeeping' -- surely a) and b) are in direct conflict, no?
d) 'participation' -- who are we currently blocking from participation, and how do you believe we can fix it?
e) 'documentation' -- ??
e) 'objective measurement' -- what are your benchmarks, what are the scales, and what are the exact tipping points?
maybe it's the lack of sleep and brutal itinerary, but i really can't make much sense of your point.
no-one's trying to argue that fd.o today is absolutely optimal. i just don't see that your suggestions are anything other than more of the same, aside from a bit of thesaural footwork and handwaving over the difficult parts.
also, i've now read the archives now, and i have to say that havoc nails it. the man himself can tell you that us agreeing isn't a particularly frequent event, so i'm not just saying this out of deference. :)
also, it seems that the epic problems stem from:
* xdg being a tad rudderless at times
* the xdg-specs repo not having been created on fd.o, which it now has been
* nepomuk?? (completely unrelated.)
are you coming to gcds?
@daniels: "no-one's going to step in and forcefully try to run xdg as it were."
no, just block it through inaction.
"so why should they be blocked in favour of someone who's quite obviously going to do a shit job?"
i've asked myself that same question many times. sadly the reality is that is exactly what's been happening.
"i don't see anyone blocking xdg leadership or whatever."
sure, there's been no overt public action, but the disregard and mismanagement of fd.o resources has amounted to the same thing.
"is there some immense power vacuum such that a leader must be anointed from on high (whatever 'on high' is)?"
no, and no one is suggesting that that is what's needed. it's not about power, vacuums, anointings, any of that. it's about allowing free participation. which is sort of the opposite of that.
try keeping with the topic.
"there are a hell of a lot of fd.o users (over 500, iirc?)"
and yet several projects are blocked because of account and project approval. fd.o, in spite of those 500 accounts, is still ranking an F on the grade scale in enabling people. so instead of defending the current state of things, we need to find out why despite all those accounts it's still failing.
"if there's no 'blessing' or whatever, then what are we providing, other than hosting which is trivially obtainable elsewhere, at least temporarily?"
consensus creation and documentation of the same. it's so very telling that you don't understand that that is fd.o's primary asset.
"then that means we're implicitly blessing any project on fd.o,"
no ... if a project meets the basic criterion (cross desktop aspirations, F/OSS) then they should have a home on fd.o, but they don't get any access to the name in practice (e.g. putting their services under org.freedesktop on the d-bus, claiming to be a standard technology, etc) until there is documented usage.
but here's the "funny" bit, Daniel: despite your assertions that fd.o needs to be protected through gatekeeping, galago still usurped org.freedesktop and Cairo still claimed to be a standard part of the toolkit. both are and were invalid claims. despite this careful gatekeeping. perhaps we should recognize failure and start making progress instead of trying to prop up the mechanisms that are failing?
"platform architects: are we?"
yes, fd.o is and yes, the current admins, as gatekeepers, very much control much of the final decisions, e.g. blocking akonadi.
"i wasn't aware anyone was compelled to ship every project hosted on fd.o, nor was i aware that being hosted on fd.o automatically forced all projects higher in the stack to use it."
so then there's no reason to block anyone from posting there stuff to freedesktop.org because it doesn't matter.
oops. except you said just the opposite a few paragraphs before that.
you really need to straighten out your story and cop to what is really going on: fd.o is important, it does have impact, gatekeeping skews that.
"and we're back to the point that you say we should just say yes to every single project that comes along, yet also keep on implying that hosting on fd.o actually means something"
and again, you fail to understand: the barrier to entry should be low, the requirements to succeeding on fd.o should be higher (through documented consensus)
@daniels: "the general impression i got was that yes, akonadi could be implemented on top of people in order to interoperate with it, but no-one was interested,"
which is completely irrelevant. Akonadi and GNOME People are not relevant to each other. it is a red herring. a dead parrot.
"maybe it's the lack of sleep and brutal itinerary, but i really can't make much sense of your point."
i hope it is the lack of sleep and itinerary, because i've been over every single point in your list here or elsewhere on xdg and/or other fd.o related communications. there is no reason you shouldn't grok it by now.
other people have understood it, and yet you, who sits as a gatekeeper on fd.o can't/won't? w. t. f.
"i've now read the archives now, and i have to say that havoc nails it."
gee, isn't that what i'm saying too? yes, it is: stop the politicking and document who implements what, where and when and we can easily measure acceptance based on that.
"* xdg being a tad rudderless at times"
agreed. and it's because we don't allow the people doing the actual work to do that work on xdg. the people on the ground should be the rudder.
"* the xdg-specs repo not having been created on fd.o, which it now has been"
can i push to it? can others easily clone and push, too? and why wasn't this done previous to me striking out and just doing it because it needed to be done?
xdg-specs is not part of the "epic problem", it was the first step towards curing it.
we want something that works, that is healthy and has proper (and lightweight) processes without bottlenecks.
"* nepomuk?? (completely unrelated.)"
what about nepomuk, other than it's a techonlogy in which we are actually making progress by a system of participation and consensus? and probably because it isn't waiting on fd.o to do so.
@Daniels: "* the xdg-specs repo not having been created on fd.o, which it now has been"
wait, where is this repo? i don't see it on http://cgit.freedesktop.org/
it sounds like you're still hung up on something that happened in 2006, and i'm sorry to hear that, but it's not my problem and if you're going to be an arse because of it, then you can be an arse to someone else.
the repo doesn't appear on cgit.fd.o because it's empty. if you'd bothered to look at the bug, you'd note that the url is ssh://git.freedesktop.org/git/xdg/xdg-specs.
basically afaict what you're saying is that we should host everything under the planet, but there should be some particular requirement for defined 'success'. presumably that's not defined by any 'gatekeeper', and is not subject to any arbitrary decisions or anything. certainly i'd hope so.
if you come back with an actual real proposal, rather than just buzzword-laden hot air ('we'll have an innovative consensus-driven documented community with no barriers to entry and no gatekeepers! except we have barriers defined by gatekeepers, but ssshhh.') combined with being a complete cock, send me an email or find me on irc.
at the moment, what you're saying is that fd.o should host anyone and everyone (which i don't buy -- gitorious and github exist and indeed are probably better for this sort of thing than we are). then there's going to be some kind of procedure to achieve 'success'.
what is that procedure? who defines it? are these people then 'gatekeepers'?
also, what's currently preventing you from doing stuff on xdg@? you certainly don't seem to have a problem with making hundreds of multi-page posts, so presumably something's working out for you.
@daniels: no, i'm hung up on something that's happened in 2004, 2005, 2006, 2007, 2008 and 2009 with no real end in sight. it's a pattern of brokenness.
"basically afaict what you're saying is that we should host everything under the planet,"
for specs, yes. they are just tiny bits of text. if you have a spec that describes something F/OSS, has a cross-desktop aspiration, then i see no harm in your spec being hosted in a common repository.
it may never get consensus (as recorded in the metadata in the repository itself), but that's another matter.
so what about software? that's easy: start with a spec describing that software. it would be a special kind of spec, different from the d-bus interfaces, file format or naming convention ones we have now, but really not that different.
once there's the same consensus gathered for that spec as done with any other one, then it would qualify for fd.o hosting.
it's really very simple.
"if you come back with an actual real proposal,"
which i have done a few times this year alone on xdg@ as well as on this blog as well as in the git repo for specs i set up.
and where have your proposals been?
"rather than just buzzword-laden hot air"
i've been offering a lot more than just that, Daniel. when people who hold keys, such as yourself, are so amazingly disconnected from what's going on that you've been blithely unaware of what's really going on something really needs to change.
"at the moment, what you're saying is that fd.o should host anyone and everyone"
that's not at all what i've been saying. i'd invite you to take the time to read and understand what i've written.
"what is that procedure? who defines it? are these people then 'gatekeepers'?"
the procedure has been enunciated a few times now on xdg@ (ironically given your next statement below), we define the process as a community and there's no need for gatekeepers unless you consider bottom-up-consensus gatekeeping (which it isn't, btw)
"also, what's currently preventing you from doing stuff on xdg@?"
well, that's where i started, isn't it? but that's not a hosting system, and the barrier to entry to getting involved with the hosting infrastructure on fd.o is unworkable. but for discussion? yes, and that's where it's been happening.
"you certainly don't seem to have a problem with making hundreds of multi-page posts, so presumably something's working out for you."
yes, i put a fair amount of energy into it. and i've put solutions on the table, real and practical ones with lots of nice detail to them. and now things are actually moving because of that effort.
so one of us is actually accomplishing something. and if you feel that's "being an arse" so be it; it's only aimed in your general direction because you stood right where it was pointing.
i want to see fd.o moving and progressing and healthy; most everyone else has been happy to either actively undermine it or, as is the more common case, to sit and watch it rot as the status quo remained unchecked.
now, if people such as yourself had actually taken up the cause back when i was being nice about it to everyone (the proposal i made around a git repo, complete with described process, are over a year old and all of it was on xdg@), it would've been a lot more fun and enjoyable for everyone involved including me.
Hey, you have a great blog here! I'm definitely going to bookmark you! Increasing your web traffic and page views Add, add your website in www.directory.itsolusenz.com/ site, it's pretty awesome too!
Hey, you have a great blog here! I'm definitely going to bookmark you! Increasing your web traffic and page views Add, add your website in www.directory.itsolusenz.com/ site, it's pretty awesome too!
Post a Comment