icon naming spec project on launchpad?

[Rodney Dawes]

On Fri, 2009-06-26 at 19:21 -0600, Aaron J. Seigo wrote:
> a couple of people have offered this POV now. this concerns me deeply, as KDE 
> just recently adopted this spec. the only reason we went through all that 
> work[1] was to gain the benefits of a shared spec. if the spec dies now, then 
> our time and energy will have been wasted.

It's a very malinformed point of view. I on the other hand, a few people
demanding what they want, and being totally uncooperative, rather than
being helpful and acting upon suggestions to further the discussion and
come up with the best possible solution from the start, so that they may
get their way. Red Hat developers seem to have this habit of developing
features, and then demanding upstream pieces they depend on add support
for their features, where upstream is already frozen, and has not been
at all discussed with upstream. This has happened before with
gnome-icon-theme, and is now occurring with the Icon Naming Spec. This
is not the way to do development in the FOSS world.

> to me, this is not an acceptable outcome. and i can't imagine _anyone_ here 
> thinking it is. so we probably all want the same thing, but there's something 
> here blocking that from happening. classic group dynamic problem, right? :)
> 
> having watched the past interactions around the icon naming specification, i 
> have some inklings as to what that "something" might be made up of. (and it's 
> more than one thing or one person.) there's evidently some unhappiness and 
> disagreement around this, and as such i'd suggest that a mailing list is a 
> poor way to deal with this.

Mailing lists are generally a very poor way to deal with anything.
Unfortunately, it's one of the best tools we have though. However, no
technical solution is going to solve the social problems.

> here's my proposal to move this forward and not lose the baby with the 
> bathwater:
> 
> 1) let's get the spec itself into the git repository; i'm happy to do this 
> myself even. then we have some place we can work on the end result in a 
> collaborative fashion, and build workflow around this particular spec from 
> there. if the workflow moves to launchpad or stays on fd.o's bugtracker and 
> mailing lists, at least we'll have a place we can work together on the 
> deliverable.

We have a place where we can work together on the deliverable. Moving
one xml file to a different source control system isn't going to solve
the problems, which are social, not technical. Having commit wars in
the VCS, instead of flame wars on the mailing list, isn't a solution.
The proposal isn't to move that XML file to Launchpad, it is to move
the discussion and status handling to the bug tracker there, as it
provides a better work-flow for dealing with the needs of a
specification, than anything we have on freedesktop.org at the moment.

I don't know what you mean exactly by 'move the spec to git' either. I
haven't had time to fully read your threads, and every time the Icon
Naming spec is mentioned in a thread on XDG, it seems like one or more
of the people from RH who like to complain about it, has to jump in and
try to start a flame war, so now I'm having to deal with that, instead
of having intellectual progressive discussion on more useful things.

I don't have a problem moving the spec into a git repository if that
will somehow actually solve some problems (which it won't really), so
long as it's not a simply open git repository where anyone who maintains
a spec can commit to other specs (because I'm pretty sure someone will),
and I don't want to have to deal with the childish behavior of others
who are unhappy and don't wish to attempt to get consensus in a properly
useful way.

> 2) let's arrange for an irc meeting to discuss this. i'd suggest #freedesktop 
> on irc.freenode.net, and one of the days between now and GCDS starting. i'm in 
> a UTC-6 timezone, but am very flexible right now timewise and will commit to 
> attending. if the others can RSVP to this email with days and times that work 
> for them, we can nail it down. i'm happy to also serve as moderator for the 
> meeting[2] if that would be deemed helpful, though i'd just as happily attend 
> as a participant if someone else steps up to facilitate.

I don't mind having an IRC meeting if something useful is going to come
out of it. If it's just going to be some people venting and complaining,
without any useful suggestions or acceptable behavior, I don't want to
be a part of it. If some people don't want to respect the significant
amount of time I've put into the specification, to get it into a state
where it's used by KDE, GNOME, and XFCE, then I'm not going to give them
the respect of listening to them moan for five minutes on IRC either.

> alternatively, if enough of the stakeholders will be at GCDS next week, a 
> meeting could be schedule with those people for a F2F. (i unfortunately won't 
> be there, as i'm moving house ... bad timing, i know.)

I unfortunately won't be there, either. So that's probably out of the
question.

> as a third alternative, i could even set up a conference call for us, though i 
> find those to be even trickier when dealing with F/OSS hackers. :)

Voice call would probably not be very helpful at this stage, I don't
think.

> one way or another, though, this obviously needs to be worked out, and if we 
> communicate openly with each other we can certainly arrive at a workable 
> solution that will benefit as many people as possible[3].
> 
> what do you say?

If people are actually going to be helpful, I'm all for a helpful
discussion. If people are going to just moan and we're not going to get
anything done, I have more important things to do. Nicolo (who started
this thread) is being helpful. The two Red Hat developers who replied
with tactless comments, are not. If they want to be helpful, I'm waiting
to see some change in commentary, but I'm not holding my breath.

> 
> [1] some of which was my work, so i feel this one even more personally than i 
> might usually ;)

I made a lot of changes in the early days of the spec, so that it would
be more feasible for KDE. And I've put countless hours into the spec,
and updating pieces of GNOME, and helping others with questions and all
of that as well.

If there are real problems we can solve with a discussion on IRC, I'm
all for solving those problems.