freedesktop.org specification process

[Cornelius Schumacher]

Following up on the discussion about freedesktop.org at GCDS and the
additional input on the mailing list, I wrote down a specification for the
process how to manage freedesktop.org specifications. It's based on the
consensus we built at GCDS plus the input which came from Aaron and others
before and after the meetings.

To bootstrap the process I wrote it down as a freedesktop.org specification
following the proposed process. You can find the text at
http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/specifications/SpecificationProcess/specification.txt

Please have a look and comment.

The next step would be to work in your comments, and when this is done to
merge it back to the main repository and get approval by the release teams.

--
Cornelius Schumacher <schumacher@...>
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Thursday 09 July 2009, Cornelius Schumacher wrote:
> Please have a look and comment.

it's looking really great. it could use some proof reading, but the content
itself seems quite sound.

just as a heads up: i'm going to be out for the next few weeks during which
time i will be available only occasionally. i will be back in full before
august. until then, i won't be able to provide much in the way of
input/involvement, but i haven't fallen off the face of the earth (just busy
moving across it ;)

i am very happy to see how far we have already come as evidenced by this draft
document, and can't wait to see where it will be when i return and can
participate more fully again.

there are a couple of others with admin status in the xdg-spec team on
gitorious, including Cornelius. so any changes or additions that need to
happen there can be taken care of by others in my absence. i'd recommend
adding at least one person with admin status from each involved project (KDE,
GNOME, XFCE, LXDE, etc.) so we have true shared ownership of this artifact.

cheers, and i'll see you all on the flip side ... :)

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Rodney Dawes-2]

I generally disagree with the idea that in order to use the
org.freedesktop namespace for DBus interfaces, you must first gain
acceptance through having multiple desktops use your interface.

This means that it will be much harder to gain acceptance (as I'm sure
that lots of KDE developers are reluctant to use org.gnome services, and
vice-versa, without there being acceptance). It also means that once
that acceptance is gained, you either don't use the new namespace, or
you are immediately required to break API compatibility. And I think
encouraging the breaking of compatibility for this is probably one of
the last things we want to do. This would be very painful for
distributions and developers to deal with.

Shouldn't we rather be encouraging people to use that namespace, and
get their interfaces accepted as standards on FreeDesktop, rather than
telling them to break API when/if they do get accepted here?


On Thu, 2009-07-09 at 22:19 +0200, Cornelius Schumacher wrote:

> Following up on the discussion about freedesktop.org at GCDS and the
> additional input on the mailing list, I wrote down a specification for the
> process how to manage freedesktop.org specifications. It's based on the
> consensus we built at GCDS plus the input which came from Aaron and others
> before and after the meetings.
>
> To bootstrap the process I wrote it down as a freedesktop.org specification
> following the proposed process. You can find the text at
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/specifications/SpecificationProcess/specification.txt
>
> Please have a look and comment.
>
> The next step would be to work in your comments, and when this is done to
> merge it back to the main repository and get approval by the release teams.
>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Mikhail Gusarov-3]

Twas brillig at 17:07:39 09.07.2009 UTC-04 when dobey.pwns@... did gyre and gimble:

 RD> I generally disagree with the idea that in order to use the
 RD> org.freedesktop namespace for DBus interfaces, you must first gain
 RD> acceptance through having multiple desktops use your interface.

The problem is badly designed protocols, which won't get accepted, and
only pollute shared NS.

 RD> It also means that once that acceptance is gained, you either don't
 RD> use the new namespace, or you are immediately required to break API
 RD> compatibility.

It should be trivial to add brand new org.freedesktop interface and keep
older name as an alias, marked as deprecated, for some time.

--
  http://fossarchy.blogspot.com/


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Cornelius Schumacher]

On Thursday 09 July 2009 23:07:39 Rodney Dawes wrote:
> I generally disagree with the idea that in order to use the
> org.freedesktop namespace for DBus interfaces, you must first gain
> acceptance through having multiple desktops use your interface.

That's why we have proposed the namespace specification. This is a
specification which just gets you a D-Bus namespace, where you then can
implement your interface. So at least the intention to use a org.freedesktop
namespace has to be accepted by the involved desktops. That doesn't mean they
already have to use it. But it's good to have an agreement about the
intention how a namespace is used before implementations start using it.

> This means that it will be much harder to gain acceptance (as I'm sure
> that lots of KDE developers are reluctant to use org.gnome services, and
> vice-versa, without there being acceptance). It also means that once
> that acceptance is gained, you either don't use the new namespace, or
> you are immediately required to break API compatibility. And I think
> encouraging the breaking of compatibility for this is probably one of
> the last things we want to do. This would be very painful for
> distributions and developers to deal with.

An implementation could start with using a non-freedesktop.org namespace or a
non-generic freedesktop.org namespace (after the namespace spec being
accepted). When the interface is done and accepted as freedesktop.org
specification, it could just add a second name, so that it's accessible under
the name it was developed under and the name it's accepted as common
specification. This way you wouldn't have to break compatibility and you
would still have the benefit of commonly agreed names.

> Shouldn't we rather be encouraging people to use that namespace, and
> get their interfaces accepted as standards on FreeDesktop, rather than
> telling them to break API when/if they do get accepted here?

We want to avoid that people just start using org.freedesktop names without
having any consensus. This has caused some of the problems we have now. That
said, if people follow the process of getting acceptance for their intention
to use a namespace, there is no reason why this can't be done.

--
Cornelius Schumacher <schumacher@...>
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Thu, 9 Jul 2009 22:19:59 +0200
Cornelius Schumacher <schumacher@...> wrote:

> Following up on the discussion about freedesktop.org at GCDS and the
> additional input on the mailing list, I wrote down a specification
> for the process how to manage freedesktop.org specifications. It's
> based on the consensus we built at GCDS plus the input which came
> from Aaron and others before and after the meetings.
>
> To bootstrap the process I wrote it down as a freedesktop.org
> specification following the proposed process. You can find the text
> at
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/specifications/SpecificationProcess/specification.txt
>
> Please have a look and comment.
>
> The next step would be to work in your comments, and when this is
> done to merge it back to the main repository and get approval by the
> release teams.

Release teams ... I still don't agree with that ;)

Anyway, I'll head out to a festival tomorrow morning, so I won't be
able to comment on the specification before Sunday. I've pulled it into
a local branch and started to improve a few bits already, so rest
assured that I'll send a few comments about it after the (loud ... and
most likely muddy) weekend.

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Thursday 09 July 2009 23:07:39 Rodney Dawes wrote:
> It also means that once
> that acceptance is gained, you either don't use the new namespace, or
> you are immediately required to break API compatibility.

Yes.  The standardisation process implies that changes (not just the service
name) will be changed during standardisation.  This only ends when version 1.0
is standardised.  Using standards-track systems requires that developers and
distributions accept that they will be subject to change.

> And I think
> encouraging the breaking of compatibility for this is probably one of
> the last things we want to do. This would be very painful for
> distributions and developers to deal with.

Ad absurdum, this suggests that API compatibility should never be broken
before standardisation either.  When does the fixing and changing process take
place?  

Will
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Thursday 09 July 2009 22:19:59 Cornelius Schumacher wrote:

> Following up on the discussion about freedesktop.org at GCDS and the
> additional input on the mailing list, I wrote down a specification for the
> process how to manage freedesktop.org specifications. It's based on the
> consensus we built at GCDS plus the input which came from Aaron and others
> before and after the meetings.
>
> To bootstrap the process I wrote it down as a freedesktop.org specification
> following the proposed process. You can find the text at
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/spec
>ifications/SpecificationProcess/specification.txt
>
> Please have a look and comment.

* Could do with a spell check and s/it's/its/ as appropriate.

* "The GNOME and KDE communities have to take into account the needs and  
feedback of other communities as well"
  This needs more work.

* ### Specification Sources
  How and where will the intentions of the desktop projects be recorded?

* The sources for freedesktop.org specifications are hosted in a git
repository at <http://gitorious.org/xdg-specs>.  

Perhaps mention that this is pending whether XDG.org will provide adequate git
hosting.

* ### Namespaces for Development of new Interfaces
If an implementor intends to use a namespace under org.freedesktop to develop  
a new D-Bus interface specification, there has to be submitted a namespace
specification stating the namespace and the intended use.

An _implementor_ choosing a namespace seems wrong - isn't this the job of the
spec drafter?

* Generic namespace names should be only accepted, if there is a high chance
of the interface under it being accepted as well.

Vague and everyone will think that their org.freedesktop.SlicedBread namespace
will probably be expected.  Perhaps have a stricter condition for generic (but
then how do you define 'generic') namespace names such as more than simple
GNOME/KDE acceptance?

* Example specification metadata

mismatched <revision> tags :P

specversion and revnumber appear to be different words for the same thing..

HTH

Will
> The next step would be to work in your comments, and when this is done to
> merge it back to the main repository and get approval by the release teams.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Cornelius Schumacher]

On Friday 10 July 2009 01:38:45 Jannis Pohlmann wrote:
>
> Release teams ... I still don't agree with that ;)

The rationale for having the release teams as the point of contact is that
they already decide about dependencies of their software, they have an
overview of what's being included and what's not, and they are used to these
kind of balancing decision processes. Additionally each community is
guaranteed to have a release team.

This is mostly about a point of contact. It's not about doing all the work.
But the release teams are likely to be in the best position to broker
requests.

Another advantage of doing it via the release teams is that there is an actual
team behind that, and it's not a single person, who could become a
bottleneck.

We could also do something else like letting the formal organizations name
representatives. But I like the simplicity of the release team approach.

--
Cornelius Schumacher <schumacher@...>
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Cornelius Schumacher]

On Friday 10 July 2009 03:26:39 Will Stephenson wrote:
>
> * Could do with a spell check and s/it's/its/ as appropriate.

Yes. If you have specific spelling or grammar fixes, please send them to me.

> * The sources for freedesktop.org specifications are hosted in a git
> repository at <http://gitorious.org/xdg-specs>.
>
> Perhaps mention that this is pending whether XDG.org will provide adequate
> git hosting.

If that happens, we can change the spec.

> * ### Namespaces for Development of new Interfaces
> If an implementor intends to use a namespace under org.freedesktop to
> develop a new D-Bus interface specification, there has to be submitted a
> namespace specification stating the namespace and the intended use.
>
> An _implementor_ choosing a namespace seems wrong - isn't this the job of
> the spec drafter?

Agreed.

Thanks for the comments.

--
Cornelius Schumacher <schumacher@...>
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Fri, 10 Jul 2009 09:42:43 +0200
Cornelius Schumacher <schumacher@...> wrote:

> On Friday 10 July 2009 01:38:45 Jannis Pohlmann wrote:
> >
> > Release teams ... I still don't agree with that ;)
>
> The rationale for having the release teams as the point of contact is
> that they already decide about dependencies of their software, they
> have an overview of what's being included and what's not, and they
> are used to these kind of balancing decision processes. Additionally
> each community is guaranteed to have a release team.
>
> This is mostly about a point of contact. It's not about doing all the
> work. But the release teams are likely to be in the best position to
> broker requests.
>
> Another advantage of doing it via the release teams is that there is
> an actual team behind that, and it's not a single person, who could
> become a bottleneck.
>
> We could also do something else like letting the formal organizations
> name representatives. But I like the simplicity of the release team
> approach.

Short comment before I leave for the festival: the reason why I'm not
particularly happy with using the release team as a contact point is
that release teams may change with each release. Specifications
are supposed to last longer than just a few release cycles of the
projects involved. Also, release teams are busy enough already. Why put
another burden on their shoulder which has nothing to do with their
actual job?

Does it really matter who the contact points are? As Aaron said, if two
persons from the same project disagree, then there's something wrong.
So I think it's better to get people involved who are actually working
with the specs, even if that may be different persons from time to
time. In the end you can always ask someone "is that the final
and official word from your project?" to be sure he gives the fact that
he's acting as a representative some thought ;)

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Le Friday 10 July 2009, Jannis Pohlmann a écrit :

> Does it really matter who the contact points are? As Aaron said, if two
> persons from the same project disagree, then there's something wrong.
> So I think it's better to get people involved who are actually working
> with the specs, even if that may be different persons from time to
> time. In the end you can always ask someone "is that the final
> and official word from your project?" to be sure he gives the fact that
> he's acting as a representative some thought ;)


In my opinion it does not matter who it is.  but it has to be someone the
project trust. And the decision of the desktop has to be taken after having
consulted all the relevent person for the specification within the desktop.
And we need someone that know who works on what, and will take care of
broadcasting the announce of the spec to the right people.

Also, I don't see what's 'wrong' when two poeple from the same project
disagree.  That happens very often. KDE and Gnome are big project with lots of
people with different opinions.  It is true that it is probably much easier to
get consensus within a single desktop than between desktop, but still,
conflicts happens.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Le Thursday 09 July 2009, Cornelius Schumacher a écrit :

> Following up on the discussion about freedesktop.org at GCDS and the
> additional input on the mailing list, I wrote down a specification for the
> process how to manage freedesktop.org specifications. It's based on the
> consensus we built at GCDS plus the input which came from Aaron and others
> before and after the meetings.
>
> To bootstrap the process I wrote it down as a freedesktop.org specification
> following the proposed process. You can find the text at
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/spec
>ifications/SpecificationProcess/specification.txt
>
> Please have a look and comment.
>
> The next step would be to work in your comments, and when this is done to
> merge it back to the main repository and get approval by the release teams.

Something is missing to me.
Before creating a specification, we should have a process to ask for feedback
and requirements from different desktop, so everyone is on the same page
before.

This is almost taken care if we want to take a freedesktop namespace, but not
for general specification.

In my opinion this should be a recommanded good practice.  sending an email to
xdg mailing list with the intentent, and then the point of contact of each
desktop make sure the right person and give feedback.


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Daniel Stone]

On Thu, Jul 09, 2009 at 05:07:39PM -0400, Rodney Dawes wrote:
> I generally disagree with the idea that in order to use the
> org.freedesktop namespace for DBus interfaces, you must first gain
> acceptance through having multiple desktops use your interface.

I've snipped the rest of your email since you make it quite plain you
haven't bothered to read what you're complaining about.

Since I'm such a ridiculously nice person, I'll reiterate for you:
  * step one: project presents rough proposal along with request to
              use org.freedesktop namespace, no formal interface spec
              nor code need be present
  * step two: project presents interface spec and asks for that to be
              approved

Between steps one and two, no-one else can use that namespace but you.
Seem fair?

Cheers,
Daniel
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Daniel Stone]

On Fri, Jul 10, 2009 at 03:26:39AM +0200, Will Stephenson wrote:
> * The sources for freedesktop.org specifications are hosted in a git
> repository at <http://gitorious.org/xdg-specs>.  
>
> Perhaps mention that this is pending whether XDG.org will provide adequate git
> hosting.

I assume you mean fd.o, but in any case, the xdg-specs repository has
been sitting on fd.o for a little while now.

Cheers,
Daniel
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan-2]

On Fri, Jul 10, 2009 at 9:26 AM, Will Stephenson<wstephenson@...> wrote:
>> Please have a look and comment.
>
> * Could do with a spell check and s/it's/its/ as appropriate.
>
> * "The GNOME and KDE communities have to take into account the needs and
> feedback of other communities as well"
>  This needs more work.

Thank you very much for mentioning this.

As a much smaller project/community (LXDE), we always feel that it's
not very easy to get involved in freedesktop.org. Although the mailing
list is theoratically open to everyone, things used by Gnome or KDE or
pushed by mainstream distro makers tends to get much more attention
due to there high publicity and large user base.

Most of the time, things developed by KDE and Gnome teams are quite
good both in quality and the design. But the problem is, the specs
designed by them might not be suitable for desktop environments other
than Gnome and KDE since we all have different goals and design
principles. That's why there are so many different desktop
environments.

Given the much more limited resources and development man power we
have, it's very difficult for us, other smaller desktop projects, to
spend as much effort as Gnome or KDE in this area. So it might seem
that we are not actively join the discussion, but that doesn't mean
that we don't have our opinions on the specs. Besides, once something
is widely used in either Gnome or KDE, for maximal compatibility, we
must follow them no matter it's a good design or not otherwise we'll
have compatibility issues with applications from Gnome or KDE
projects.

So this could make a false sense of wide acceptance. We support those
specs because we need to provide the users maximized compatibility,
not because we think the spec is good. Unfortunately, once something
is already widely used in KDE or Gnome, it's hard to fix since it's
already widely used and any change could break backward compatibility.

So, if the process of spec development is going to be changed, I hope
there could be more chance for smaller projects other than Gnome and
KDE to get involved. Otherwise xdg could easily develops some specs
which only work well for Gnome and KDE, and not for others. Then
things couldn't be really 'cross-desktop' because 'cross-desktop'
never equals 'supported by Gnome + KDE'.

Thank you all for reading this.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

Cornelius Schumacher wrote:

> Following up on the discussion about freedesktop.org at GCDS and the
> additional input on the mailing list, I wrote down a specification for the
> process how to manage freedesktop.org specifications. It's based on the
> consensus we built at GCDS plus the input which came from Aaron and others
> before and after the meetings.
>
> To bootstrap the process I wrote it down as a freedesktop.org specification
> following the proposed process. You can find the text at
> http://gitorious.org/~cornelius/xdg-specs/xdg-specs-spec0/blobs/master/specifications/SpecificationProcess/specification.txt
>
> Please have a look and comment.

# About "### Overall Acceptance States"

I am wondering if there should not be a way to represent specifications
which may have been declined by one "major" desktop but implemented by
the other one and by "minor" desktops.

(sorry for the major, minor words, I can't find better terms)

# About "## Project Hosting"

There is no lack of hosting solutions these days, so I think
newly-approved projects should only be hosted there if they are
implementing an fd.o spec. This should help reducing confusion.

# About "## Appendix A: Specification Meta Data Format"

Sometimes implementations are at application level rather than
desktop/organization level (for example the thumbnail spec). So I
suggest replacing the <organization> element with the more generic
<adopter>.

I think we should encourage implementations to list themselves as
adopters. This helps to have a birds-eye view of the ubiquity of an
implementation.

The <adopter> element should include contact information for the
implementer so that it's easier to gather interested people when there
is a need to make the specification evolve.

The "specversion" attribute of the <version> element should be mandatory.

Aurélien
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone-3]

On 2009/07/10 00:42, Cornelius Schumacher wrote:
> On Friday 10 July 2009 01:38:45 Jannis Pohlmann wrote:
>> Release teams ... I still don't agree with that ;)
>
> The rationale for having the release teams as the point of contact is that
> they already decide about dependencies of their software,

Maybe they do with KDE (and maybe with GNOME), but that's not true
everywhere.  We (Xfce) decide about dependencies collaboratively at the
start of the development cycle.

> they have an
> overview of what's being included and what's not, and they are used to these
> kind of balancing decision processes. Additionally each community is
> guaranteed to have a release team.

No, they really aren't.  In the past, we haven't decided on a "release
team" (usually just one or two people) until we start the alpha/beta
cycle for the next release.  (We have a plan to be a bit more formal
about this stuff, but this is how it's worked in the past.)  Please
understand that most projects don't have the resources to dedicate
people to it.  Also understand that GNOME and KDE are unique in that
they have a lot of paid developers.  Xfce is done entirely by volunteers
in their free time.  I'm not sure, but I believe LXDE is similar in that
regard.


> Another advantage of doing it via the release teams is that there is an actual
> team behind that, and it's not a single person, who could become a
> bottleneck.

Heh.  Not quite.

> We could also do something else like letting the formal organizations name
> representatives. But I like the simplicity of the release team approach.

Naming formal representatives basically sounds pretty much equal in
terms of usefulness to the release team approach.  The only reason the
release team idea is simpler is because it doesn't require selecting
anyone.  Communication difficulties remain the same.

There's just no reason to need points of contact at all in the general
case with a more decentralised system like the one Aaron suggests.  A
point of contact might be useful in the case that there's an
intra-project dispute, but one would hope they'd be few and far between
(as someone mentioned, even with KDE's open-commit policy, there'd only
been two issues over the past 10 years...  our communities are pretty
trusting and that trust is rarely violated).

        -brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Fri, 10 Jul 2009 11:31:27 +0200
Olivier Goffart <ogoffart@...> wrote:

> Le Friday 10 July 2009, Jannis Pohlmann a écrit :
>
> > Does it really matter who the contact points are? As Aaron said, if
> > two persons from the same project disagree, then there's something
> > wrong. So I think it's better to get people involved who are
> > actually working with the specs, even if that may be different
> > persons from time to time. In the end you can always ask someone
> > "is that the final and official word from your project?" to be sure
> > he gives the fact that he's acting as a representative some
> > thought ;)
>
>
> In my opinion it does not matter who it is.  but it has to be someone
> the project trust. And the decision of the desktop has to be taken
> after having consulted all the relevent person for the specification
> within the desktop. And we need someone that know who works on what,
> and will take care of broadcasting the announce of the spec to the
> right people.
>
> Also, I don't see what's 'wrong' when two poeple from the same
> project disagree.  That happens very often. KDE and Gnome are big
> project with lots of people with different opinions.  It is true that
> it is probably much easier to get consensus within a single desktop
> than between desktop, but still, conflicts happens.

How about this:

We establish one or two persons per project as general freedesktop.org
contacts. Whether they are part of the release team or not is
irrelevant. These are the persons to contact when a new spec or
whatever is brought up. They are also the persons to contact when
per-specification contacts (see below) are unresponsive.

Together with the meta data which holds information on the adoption of
a spec in various projects, we list one or two persons per project.
These are the per-specification contacts which are ideally involved in
discussions and can be contacted e.g. for adoption status updates
before a new version of a spec is released or when someone feels that a
spec needs to be changed/improved. Ideally, most of the communication
happens on public mailinglists and via the xdg-specs repository, so
whenever a new projects wants to be listed in the meta data of a spec,
one of its developers can extend the meta data with their own project
information and request one of the admins to merge this change.

What do people think?

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Jul 12, 2009, at 8:56 AM, Jannis Pohlmann <jannis@...> wrote:

> On Fri, 10 Jul 2009 11:31:27 +0200
> Olivier Goffart <ogoffart@...> wrote:
>
>> Le Friday 10 July 2009, Jannis Pohlmann a écrit :
>>
>>> Does it really matter who the contact points are? As Aaron said, if
>>> two persons from the same project disagree, then there's something
>>> wrong. So I think it's better to get people involved who are
>>> actually working with the specs, even if that may be different
>>> persons from time to time. In the end you can always ask someone
>>> "is that the final and official word from your project?" to be sure
>>> he gives the fact that he's acting as a representative some
>>> thought ;)
>>
>>
>> In my opinion it does not matter who it is.  but it has to be someone
>> the project trust. And the decision of the desktop has to be taken
>> after having consulted all the relevent person for the specification
>> within the desktop. And we need someone that know who works on what,
>> and will take care of broadcasting the announce of the spec to the
>> right people.
>>
>> Also, I don't see what's 'wrong' when two poeple from the same
>> project disagree.  That happens very often. KDE and Gnome are big
>> project with lots of people with different opinions.  It is true that
>> it is probably much easier to get consensus within a single desktop
>> than between desktop, but still, conflicts happens.
>
> How about this:
>
> We establish one or two persons per project as general freedesktop.org
> contacts. Whether they are part of the release team or not is
> irrelevant. These are the persons to contact when a new spec or
> whatever is brought up. They are also the persons to contact when
> per-specification contacts (see below) are unresponsive.
>
> Together with the meta data which holds information on the adoption of
> a spec in various projects, we list one or two persons per project.
> These are the per-specification contacts which are ideally involved in
> discussions and can be contacted e.g. for adoption status updates
> before a new version of a spec is released or when someone feels  
> that a
> spec needs to be changed/improved. Ideally, most of the communication
> happens on public mailinglists and via the xdg-specs repository, so
> whenever a new projects wants to be listed in the meta data of a spec,
> one of its developers can extend the meta data with their own project
> information and request one of the admins to merge this change.
>
> What do people think?

That's what I immagined when the repo idea first came up. This seems  
to get rid of bottlenecks.

Jeremy

>
>  - Jannis
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg