Dave blogged once again and this time he took aim at the character of people. Even if we assume that I'm a raging asshole laying waste to the interactions going on around me, the track records remain for all the projects involved in freedesktop.org in terms of what each has adopted and what each has proposed. I really hope that people pay attention to the issues we face rather than pick on personalities involved.
I'm not going to write a rebuttal to Dave's essay point by point, but I would like to correct a statement Dave made that was not just unfair and incorrect but potentially quite damaging to the overall process because it is unnecessarily divisive: I do not have "no confidence in GNOME developers as a whole." This is not about the individual developers who work on GNOME as a faceless whole. I've known several of them for years and count a number of them as friends and associates. There as several who I have praised openly and publicly in the past for the technical and social work. To put it simply: I am not a bigot, and I'd ask that we not use such an idea as an excuse to dismiss the realities we face.
This really isn't about individual developers, and I do not paint every person in GNOME with the same brush in my mind. I don't do that for KDE, either: there is variety, some productive and some counter-productive, in any large group of people and our communities are not exceptions to that. However, casting me as some sort of "I hate all of you!" villain is not useful. Even if it were true, then people should simply ignore me as an individual actor in it and look at the large, long-term patterns that really do exist and really do need fixing. I am not personally responsible for everything, I was not even involved most of episodes that exhibited the unfortunate patterns we've been experiencing. So even if the messenger really, truly sucks and you really don't like them as a person, try to address the issues anyways. Avoid indulging in shooting the messenger as a way of dismissing issues and thereby relieving the perceived pain. It's only a distraction, and nothing gets improved that way.
Aside from all that, I do find hope in the discussions being had: Dave says freedesktop.org is not functioning the way it should, and I've heard the same from others. People have been trying to put forward possible ways to improve it for some time now. Those involved in freedesktop.org as a whole haven't actually been trying out those ideas in practice, and that is a bit discouraging and certainly not helping. Having a functional, healthy collaboration zone (or zones) would be to all our benefit and I do hope that we find the time, energy and courage to try to better our processes.
Starting with clear problem statements, as Dave suggests, might be one thing to do. We now have a defined git repository to house specs in a shared fashion, perhaps we can now add usage metadata to that repository so we can easily track who is using, who is developing and who is participating in each effort clearly. This would help address Dave's concern of ensuring that projects have the appropriate individuals around them, as we'd be able to easily identify when they don't. This is a source of insight we currently lack. There are certainly other improvements to be made as well, and I hope that we can shift the discussion to those things.
Before I sign off for the day (it's a beautiful sunny Saturday outside, and we're going to go for a walk and some shopping in a bit!), I also wanted to clear some technical errors in Dave's blog:
- StatusNotifiers are not about notifications. This an understandable error I've seen repeated a few times as the word "notifier" is in the name, but it is actually about system tray icons or "message area" entries. The use of the word "Notifier" was to emphasize that it is about communicating application status rather than presenting a full interactive interface. It really, though, has nothing to do with notifications themselves, which is a whole other technical topic.
- StatusNotifiers did start with a clear problem statement, namely that the XEmbed system tray icons were failing us in a number of technical manners. This problem statement was shared on the xdg@ list more than once and over the course of several years, and a number of projects other than KDE agreed (Enlightenment is one that jumps to mind, for instance). Where we could have done better is to repeat that statement when introducing the StatusNotifiers spec to the xdg@ list, something Dave observes. We simply can not assume people will have read and remembered past discussions and need to keep context. StatusNotifiers did start, however, with a clear and communicated problem statement.
- Changes and improvements suggested were made to the spec, though not all were, particularly those that deviated from the design in such a way as to make the entire concept of host-side rendering control moot. We didn't show up with something hard-baked and without flex in it.
Cheers ...
34 comments:
Who do you want from 'freedesktop.org as a whole' to do any of this? The session at GCDS seemed to conclude very well, and the take-away was that people from the respective desktop environments would go back, document usage of specs in their projects, marshal the relevant people to comment on specs which were raised, etc, etc. Given that it was mainly just wiki pages which were asked for, I'm not really sure what else needs doing.
Also, glad I'm hearing about this for the first time through a blog. Again. A shining example of cross-project communication.
That's a pretty willfull misreading of Dave's post.
Reading a Daves post made me thinking if he understood a single sentence from yours. He just blames Canonical and fd.o, but not gnome. Canonical really should stop working with them, because those people are really strange and don't know what cooperation means.
@daniels: and what actions came from the GCDS event? for a long while: none. after several gentle reminders and check-ins (not by me, btw), we finally got a git repository for specs which didn't have any useful metadata, still doesn't have all the specs (though i can now start helping with that ... i have a git account now and am finally settled into the new place), and still doesn't have the main thing that motivated it all from the start: a mechanism to document usage and status of the specs so we can track that info.
i tried to start discussion on the metadata again, a few people from KDE replied, and otherwise silence.
so yes, the GCDS session concluded with people in a good mood and with some agreements on things like "we should make freedesktop.org better" but once again a lack of timely actions that reflect that.
what really galls me is that i had started a git repository, started an approach for metadata within it (and was completely open to any changes requested, still am), had several others who were also working in/on it and that effort was totally ignored despite being repeatedly offered... all so that Vincent Untz could start a new repository that is no more or less complete and which was months late.
let's also tackle this honestly: you have an ax to grind with me Daniel, and i really don't care for it. when fd.o comes up, you pop your head up and say something completely trite, sarcastic and borderline nasty. it's tired, unnecessary and reflects precisely the poison around fd.o that drags it down.
@jmj: how is it a misreading of Dave's post? he went for personal indictments as a way to explain why there's dissent.
he offered additional analysis and input, which i either didn't respond to here because it wasn't aimed at me or which i noted in this blog entry that i agreed with.
but perhaps i did misread something. please point me to what it was. was it when he said i generally mistrust all GNOME developers? because that was a direct quote, kept with the same meaning it had in the context of the blog entry he wrote.
as with my earlier blog entry, the responses are generally apologist in nature rather than actually addressing content or solution.
@aseigo: When you slag fd.o off and say that it needs to be improved, I want to hear how it can be improved. If metadata and some of the specs are missing, I'm sad to hear that, but it's not really anything I can do anything about.
The xdg-specs git repository appears to have been created on the 9th of December, 2009. Which is admittedly a fair bit later than hoped, but still over fifteen months ago. If there's still not much movement around it, then I'm sorry to hear it, but I'm honestly not sure what you'd like fd.o as an organisation to do about it.
The only open bug I can see about specs is this one:
https://bugs.freedesktop.org/show_bug.cgi?id=33006
which concludes in 'I'm sorry, I don't know Marco. I can only say that, according to the xdg archives, he's been working on the notification spec.'
So if there's anything other than that bug you need done (hell, if you could even shed light on that bug), then please let us know, preferably in specific terms.
My beef here is that you have a pattern of blogging screaming about how fd.o is broken when you never bother to approach anyone and ask if things can be changed/fixed first. I'm sure you know our email addresses and IRC nicknames, or you could use the fd.o lists, or any number of other communication methods. But instead you go straight for the headlines, and it's getting pretty old. I don't have a beef with you personally as such -- in fact, the last time I saw you in person, I ended up stopping someone from punching you in the face.
Anyway, now that you've got everyone's attention: what can we do? Be specific.
What I read most clearly in this story is:
"But I started it then, there were some people there that agreed so we went on, but afterwards, the correct people were not there."
Isn't there a way to set up a Point Of Contact (POC) for each community that is contacted when collaboration is needed? This POC can then contact the right people in their community.
And what to do if there isn't someone available in that a community. How will the process evolve? Without that other community?
@daniels: it is not "slagging off" something to note that real challenges that are ongoing with it. i'm not dissing fd.o, i'm noting real weaknesses we face.
as for real solutions, i've been offering my thoughts on that for years now.
"The xdg-specs git repository appears to have been created on the 9th of December, 2009. Which is admittedly a fair bit later than hoped, but still over fifteen months ago."
yes, i'm glad it is there. and i said so on the mailing list. even though it completely ignored all the previous work that had been done, i figured, "Hey, progress is progress, don't knock it, let's move this forward." it didn't.
i do now have an account myself and am moved into my new place and so am, for the first time in probably 6 months, able to do something directly about it myself.
"If there's still not much movement around it, then I'm sorry to hear it, but I'm honestly not sure what you'd like fd.o as an organisation to do about it."
here's what i'd like fd.o to do: take input offered from all parties and when that input is in the stakeholder's combined best interests actually find ways to act on it regardless of where the input came from.
in the case of the specs repo, that would have perhaps come in the form of supporting work i had started but which Vincent duplicated much, much later; it perhaps could have come in the form of actually putting metadata in there or even just discussing the idea of metadata, which so far has been a completely one sided discussion.
now, i completely acknowledge that perhaps these things are of zero interest to others. in which case, the stakeholders in fd.o really don't have enough interest in combined, cooperative development as a primary goal. which is, as i wrote in an earlier blog post, completely fine as well ... as long as we acknowledge that state of things.
it seems that there is, however, a desire to work technologies of mutual interest out together. now what we need is to turn those desires into demonstrated actions. there's a disconnect there right now.
it's fixable. we should fix it. it requires all parties to help fix it.
personally, i want to see that happen very, very badly. which is why i'm willing put myself in the firing line in the name of making it happen.
@daniels: "My beef here is that you have a pattern of blogging screaming about how fd.o is broken when you never bother to approach anyone and ask if things can be changed/fixed first."
this, Daniel, is pure and unadulterated bullshit and as such i would like to reply to it separately.
i have been discussing solutions for all the issues i've brought in blog entries for years with people involved in fd.o. i have been involved on the xdg@ list, i've put time and effort into implementing those suggestions (so it isn't just words i've been offering hoping others will do something).
in each case where i raised issues, either in person or here on my blog, it followed months and usually years of concerted effort before it coming to this.
the StatusNotifier issue, the jobs d-bus issue (which i spent a fair amount of time with the fellow implementing it for GNOME), the specs issue, etc. etc. etc. etc.
so to say i scream first and don't actually approach people or put in effort is utter delusion. i'd appreciate it if you'd stop spreading such lies. thanks.
@tbscope: "Isn't there a way to set up a Point Of Contact (POC) for each community that is contacted when collaboration is needed? This POC can then contact the right people in their community."
agreed; this was part of the suggestion for metadata on the specs. such metadata would document which projects are acknowledging the spec (even if to say, "no thanks :)"), what the adoption status is in each project and who the contact people are that sign off on those statements for each project.
then it's a trivial matter to know which areas are not getting representation and those from each project involved with fd.o on a regular basis can be prodded (or take the self-initiative) to get people involved.
the "POC"s could also be explicitly noted in the main repository metadata and change over time.
"And what to do if there isn't someone available in that a community. How will the process evolve? Without that other community?"
as there is no way to force people, i think this is inevitable.
there are times when people will just be busy or whatever. our schedules won't mesh 100% of the time and we can't let that impede progress on such occasions.
it also allows one group that has a brilliant idea that others don't appreciate yet to at least continue on with the chance of proving their idea through action.
these should be the edge cases, though, and don't need to be the status quo at all.
@aseigo: I'm still trying to boil down your response to concrete actions people can take. I'm sorry that Vincent duplicated your work and you felt put out, but surely you could've taken that up with Vincent?
At the end of the day, most of the people doing fd.o aren't really qualified to lead the spec work. The people qualified to do the spec work are the people from the respective environments who can marshal the people and to some degree work on implementation: that would mainly be you and Vincent.
I'm personally not subscribed to xdg, as I have enough stuff on my plate as it is, and I don't really have anything to contribute to client-oriented specs. Should I be?
I'd thought that xdg being quite unambiguously in the hands of the environments, rather than the 'gatekeeper' model you'd previously complained about, would be an improvement, but apparently not.
We aim to be a forum in which people can work together. No more, no less. That doesn't mean we're not interested in collaborative development, it doesn't mean we hate one desktop environment or the other, it just means that we don't micromanage and stand over people making sure things are going OK. Would you guys like a designated person who can speak to both of you when you're having disagreements to sort it out? Or would you like someone who could step in and make final decisions? (And if the latter, who would it be - would you have legitimacy concerns if it was someone uninvolved in actual spec work?)
I actually want to make fd.o better, believe it or not. So you can understand my dismay when I open Reader to see that a process I believe to be going well -- there's an active git repo, account requests are coming in and being processed with a ~fortnight RTT (not ideal but not shocking) -- is apparently in dire straits, collaboration is dead, etc. Even from having looked at several months of xdg@ archives this morning, I couldn't see much real evidence of any problems.
Again, in future, if you have problems, please raise them with the list, myself, Tollef, Keith -- anyone, really -- rather than stew on them for months and then blog about how fd.o is broken because no-one listens to concerns you don't seem to have previously expressed.
@ daniels: "Again, in future, if you have problems, please raise them with the list, myself, Tollef, Keith -- anyone, really -- rather than stew on them for months and then blog about how fd.o is broken because no-one listens to concerns you don't seem to have previously expressed."
I am confused here. Did you simply not read Aaron's response? He explained in some details that he had been raising the problems for years.
Your description of Aaron's behavior is almost, if not completely, the exact opposite of what he says he did.
If that's the case, then I'm simply not sure where/who. I haven't seen Aaron in person for a few years (I believe 2005 was the last time), the last mail I got from him was a brief one in 2009, and we've not spoken on IRC since we discussed aKonadi/Nepomuk in 2008.
If the issue is about the (non-)adoption of specs, then fd.o people aren't the people to raise it with. That would be GNOME. I checked the xdg archives going back several months this morning, and didn't see anything from Aaron either.
The only time I ever hear Aaron saying that fd.o is hugely broken is over blogs. And that's hugely broken.
@Daniels
You're saying you didn't saw anything from Aaron. Did you saw a thing from gnome camp? Something that will show they want to cooperate?
The last I saw from both camps was that they had an arrangement they were happy with.
@ daniels
"When you slag fd.o off and say that it needs to be improved, I want to hear how it can be improved"
I just visited the freedesktop.org website and in the News section the latest headline is from September 2009 - "PSU suffered a power problem on 2009-9-29 which was not covered by the UPS"
The website was last updated in July 2010. This is over 8 months ago now.
I think this can be improved to better relect that there is not a lack of timely actions
@ Daniel: "If that's the case, then I'm simply not sure where/who."
In that case maybe it would be better to ask him, rather than accusing him of not doing what he claimed he did.
@aseigo: you're doing the passive-aggressive parts really well; I have to say that I'm impressed.
@ Matthew
The website was updated a lot more recently that that (although that was the last time the front page was edited). There's a link to the recent changes right at the top of that page; several happened today.
http://www.freedesktop.org/wiki/RecentChanges
I think the response was always going to be predictable because it couldn't have been done any other way. Frankly, those of us who've been just been trying to use open source desktops for the past ten years have seen this. I've also seen this in some seriously schizophrenic, and thankfully rare, client relationships over the years:
1. Claim that Freedesktop is broken and that it isn't really a standards body so anything that may or may not have been done is OK.
Don't make the mistake of reading that as some way of trying to improve the situation because Dave offers no constructive areas to improve.
2. Don't agree anything in writing or in a mailing list. Nothing that can be recorded. If you agree verbally at a meeting you can later claim that there was a misunderstanding or that the discussion never took place. He said, she said.
3. Call StatusNotifier broken with not a shred of evidence to back it up. All I know is that I've seen it work in KDE and eventually also in Unity.
4. He brings up dconf as a comparison, which is a puzzle. In the case of dconf it was a proposal that simply appeared. With StatusNotifier there was some documented discussion on it.
5. Point 4 is then offered as a justification that what has gone on is all OK.
6. This is not a compelling problem statement. No user ever had a problem because notifications didn’t use D-Bus.
I really don't know what you can say to a statement like that.
7. The rest of the blog posting at this point appears to follow the usual track - try and claim that everyone is a stakeholder who can change things, but never acknowledging the roadblocks that get put in place to stop such change.
For example, improvements were demanded of StatusNotifer as I understand it and when those improvements were actually forthcoming and coded there was stonewalling, probably because they hoped nothing would happen. It's not the first time this has happened. People who write the code decide? Hardly.
8. He identifies that deep mistrust has developed, but can never bring himself to identify why that is.
9. He then launches a bizarre character assassination on Canonical. I know Canonical has got quite a few things wrong, but picking out an article by Greg Kroah Hartman on Canonical's kernel involvement as a comparison is just diverting things.
Sigh.............
Dave Neary has completely, totally and unequivocally closed the door on things ever improving in a million years. I think after the past decade we should have learned that much unfortunately and we should learn it for the next decade, lest a lot of people waste more time and effort.
@ Daniel
"I'm personally not subscribed to xdg, as I have enough stuff on my plate as it is, and I don't really have anything to contribute to client-oriented specs. Should I be?"
Might explain why you never heard from Aaron on this subject???
As I said, I dug through the archives too, and came up empty-handed.
Paweł: Such a message is not needed. Suggest to drop your mistrust.
@daniels, @aaron
Guys, you're yelling past each other. Aaron seems to be complaining about broken standardization processes taking place around fd.o, not so much the systems on fd.o.
Now hug and kiss! And I'd like to thank you both publicly for all the work you've done, seriously.
Hi Aaron,
I'm happy to devise my conclusion re your mistrust of GNOME - but you're going to have to address the comments I quoted of yours.
It sounds like your position is "I don't mistrust GNOME, I have GNOME friends - but they're not representative of the project". Otherwise why would you say the things you said?
Dave.
s/devise/revise/
Dave
@ Dave: You really can't see the difference between the general culture in a group and the behaviors of individual members of that group. For instance someone could be upset with Microsoft as a company while still thinking particular members of that company are doing good things. To take a property that applies to a particular group and claim it necessarily applies to every member of the group is a fallacy.
The first sentence was intended as a question.
@toddrme2178: Yes, there is a difference between individual behaviour and group norms. Aaron chooses to believe that the group norms for GNOME are represented by a number of people with whom he has had, apparently, less than ideal experiences. I choose to believe that the group norms for GNOME are represented by the many good experiences I have had working with people in the GNOME project.
For the record, Aaron and myself do work together (although we certainly don't always agree) as part of the Desktop Summit organising team.
I believe that all GNOME developers want to make the best possible user experience for GNOME users. And part of that is working on infrastructure like NetworkManager, PackageKit, DBus, DeviceKit, pulseaudio, ... so that users of GNOME can use the full potential of their computer. These things don't just benefit GNOME users, they benefit everyone.
One (small) part of the user experience is ensuring that application developers can integrate well with whichever desktop environment their users are using. Interfaces like mime type handling, desktop files and handling of copy & paste & drag & drop enable this.
Hopefully this list shows clearly that GNOME *is* concerned with solving problems the right way, as far down the stack as is necessary, rather than doing so in a way which will only benefit GNOME application developers or GNOME users.
We also need an interface which allows application developers to show information to the user through some kind of desktop-wide system (things like online/offline, volume, what music is playing, etc).
This last type of interface is what we're talking about here. There was some disagreement over the approach proposed by Aaron & Marco, and rather than work to reach a compromise, they decided to go ahead (as did Ted & Aurélien) without getting buy-in from the individuals who could have made it happen in GNOME. Aaron chooses to see fault on the part of the GNOME developers. I choose to look at things differently.
Cheers,
Dave.
@Dave Neary: "Aaron chooses to believe that the group norms for GNOME are represented by a number of people with whom he has had"
no, i believe the norms are represented by the common behaviors and attitudes that come into play. whether that is the result of certain individuals or not is interesting in terms of identifying ways to improve things, but the observation that there is a general pattern of behavior involving GNOME participation in cooperative development is not contingent on that.
i'd also add that it's a general pattern. i can point to exceptions, just as i can also point to times when other stakeholders (inc KDE) didn't perform as well as they could/should.
"Aaron and myself do work together (although we certainly don't always agree) as part of the Desktop Summit organising team."
yes, where the issue of using identity.kde.org for a backend service came up. it was offered in good faith by KDE, but GNOME representatives, including and perhaps even particularly you, were hesitant because it was a KDE thing. i was amazed by that. if GNOME had a similar system and it was put forward for use in a registration back-end, i wouldn't care one bit and i don't think the rest of KDE would either (though i'm sure we could find exceptions).
so yes, we do work together, and there are examples of this NIH problem to be found there too.
"I believe that all GNOME developers want to make the best possible user experience for GNOME users."
nobody is saying otherwise, Dave.
(con.)
"Hopefully this list shows clearly that GNOME *is* concerned with solving problems the right way,"
what is shows is that as long as it comes from within GNOME, it's all good. if it comes from outside GNOME, it becomes a very different story.
this was never about GNOME exporting technology. it was about making that a two way street, which is key to making co-operative ventures work. it's something we also used to manage to accomplish.
"This last type of interface is what we're talking about here"
no, actually, it isn't. it was an example, one of many. i prefer to speak from personal experience and to actual examples as this tends to avoid talking about others and in generalities.
but it isn't about this one incident alone in a vacuum.
"There was some disagreement over the approach proposed by Aaron & Marco, and rather than work to reach a compromise, they decided to go ahead (as did Ted & Aurélien) without getting buy-in from the individuals who could have made it happen in GNOME."
first off, we did work to make the spec amenable to others. this is a process that still continues, even, as it expands in capability. the compromise asked for was really "forget the basic design concept" which makes no sense whatsoever. the needs for that design were discussed, over several years and with general agreement, on xdg@.
if this was a one-time thing, i'd be "oh, well, so be it", but it's the pattern. there's always some reason things from outside of GNOME are not good enough, while things from GNOME are deemed just fine (even though that is often quite debatable; the galago spec being a good example there, and that's something we did implement support for in KDE Plasma!).
the fd.o specs repo issue is a great example, as it isn't even technological but ended up in an even more absurd situation.
now, the "ours is good, yours is questionable" viewpoint is a valid position for GNOME to take. but it means that cooperative development can not realistically happen.
"Aaron chooses to see fault on the part of the GNOME developers."
i "choose" to see it as a typical example in a larger pattern where, yes, it is very difficult to bring technologies into co-op ventures like fd.o or even the desktop summit support infrastructure that originate "outside" of GNOME.
"I choose to look at things differently."
indeed you do :)
@Dave Neary: "I'm happy to devise my conclusion re your mistrust of GNOME - but you're going to have to address the comments I quoted of yours."
happy to do so :)
"It sounds like your position is "I don't mistrust GNOME, I have GNOME friends - but they're not representative of the project". Otherwise why would you say the things you said?"
GNOME is made up of individuals, and many of those individuals who i know seem like really good people. i've had some really good times with them over the years. there are also people i've butted heads with, and people who have done some amazingly questionable things over the years. for any large community we can observe much the same: people are people :)
however, when a group gets together and works on a common goal for an extended period of time a culture is created and patterns in behavior within those efforts and their results start to emerge.
this is largely independent of individuals: if you took 100 random developers at Apple and 100 random developers from Nokia and swapped them, each company would still produce the same products and generally behave the same and those 100 "swappers" would be part of it.
what i've observed over the last several years is a pattern of behavior when the GNOME project enters ostensibly cooperative ventures. it is only a pattern, however: there are exceptions to be found. but it's also a fairly dominant pattern.
if we took 10 random KDE hackers and swapped them with 10 random GNOME hackers, the results would probably be the same. the group dynamic, culture, leadership needs a shift. this is also what Mark Shuttleworth has been saying.
so without indicting individuals, which i don't think is useful as it misses the point, it is evident that there is something to be fixed in the current culture of GNOME if we wish to experience healthier cross-project cooperative development.
this is very, very different from saying i don't trust GNOME in general or that i don't trust GNOME developers specifically.
noting that there is an endemic problem that we run into regularly is an observation of reality, and one that needs to be made because it is having negative consequences. hopefully we can do such things without having the "loyalty" or "trustyness" of the messenger irrelevantly called into question. because that smells a lot like denial, Dave.
my willingness to expose myself to attacks such yours in the process, something i knew i was doing as can be seen from the closing paragraph on my original blog entry, is a demonstration of how much i do care about this f/oss desktop community as a whole, which includes GNOME.
and even more to the point: if i had no trust / faith / etc in this whole thing, i wouldn't have taken StatusNotifiers to fd.o in the first place. i wouldn't have repeatedly pushed forward discussion on the shared specs repository and metadata. i wouldn't have been a champion within KDE for this or the last shared desktop summit, helping to answer questions of concern and doubt around such a thing within our community. (which, btw, is an example of culture formation in action.)
all three of those things (amongst other actions i've taken) happened long after i was aware of the challenges with cooperative efforts we face. i kept and keep going because i actually do trust that GNOME can and will identify and improve this issue.
and now that we've gone through the exercise of dragging my personal viewpoint of GNOME and the individuals who contribute to it over the coals, can we now get on to addressing the real issue?
@Dave Neary
There was some disagreement over the approach proposed by Aaron & Marco, and rather than work to reach a compromise, they decided to go ahead (as did Ted & Aurélien) without getting buy-in from the individuals who could have made it happen in GNOME.
Come on Dave, really? Please stop doing this. You're not helping anyone by this kind of deliberate papering-over of how we got here. Please stop pretending we got to this point because of the actions of everyone else.
Several actionable objections and several non-actionable, vague, sweeping objections about the spec were raised by the GNOME folks participating in the discussion. In response to one of those vague sweeping objections, it was pointed out that debating the merits of separation of data from visualization(MV, MVC, MVP) is basically a resolved topic in software engineering and that there was little to be gained in such a discussion.
Then there was effectively silence from the GNOME folks participating.
It is now clear that the status notifier spec didn't fit with what the GNOME shell designers vision of how applications communicate status information. They went on to use the notification spec and made several changes to that spec without discussing it with others.
Several things could have happened differently:
- GNOME folks could have offered specific, pratical use-case objections that might have accommodated the discussion better.
- KDE folks could have requested for an explicit "we do not agree with this and will not support it" from the GNOME folks participating.
- GNOME folks could have explicitly said that. They could also have added that they believe the/a notification spec is more appropriate, will use that to support application status information and make sure to communicate proposed changes to that spec.
- KDE folks could have abandoned the spec to accommodate GNOME's vision of how application status should be handled - though they would feel somewhat put out to do so.
- GNOME folks could have made an accommodation in their design for the status notifier spec - though they would feel somewhat put out to do so.
There are probably a variety of ways this specific issue could have gone differently, or better, and many could reasonably be considered too-much-to-ask by any of the involved parties. It doesn't matter if the responsibility is evenly shared. What matters is that we each accept our responsibility and work to improve it.
To the GNOME folks best wishes for the GNOME 3.0 release. Despite all the bickering this week, everyone knows a lot of hard work went into it and it shows. Many people, including this KDE user and app developer, definitely appreciate it and are excited to see it when it comes!
@aseigo:
this, Daniel, is pure and unadulterated bullshit and as such i would like to reply to it separately.
Given that you haven't replied to either of the emails I sent to you over the past couple of days about this (pointing out that you hadn't emailed xdg@ since May, and those emails just looked like the normal back-and-forth of spec work) asking you to please clarify who you'd repeatedly pointed all this out to, I can only conclude that what you've said is pure and unadulterated bullshit.
I'm eagerly awaiting your apology for calling me a liar, then. Thanks.
It saddens me greatly to see so much conflict, and for want of a better word, dirty laundry being aired. While open-source is a diverse community, the word community is somewhat at odds to the manner in which people seem to treat one another. This "apartheid" really needs to stop. As long as we have that "them and us" mentality, opensource will go no-where, and fast. While we spend time bickering over these issues, Microsoft continue on their own path, creating some excellent services and applications. If their plan was to divide and conquer, - they've already won.
Post a Comment