New maintainer for XDG specs

[Daniel Stone]

Hi all,
After a bit of a period of inactivity, Matthias Klumpp has agreed to help 
update and maintain the XDG specs, including the menu and icon-theme specs in 
particular.

If you have any suggestions or anything you want addressed, please discuss it 
on the list, or file an issue or merge request.

Thanks to Matthias for stepping up, as well as to Bastien Nocera and David 
Faure in particular for all their work over the years to get us to this point.

Cheers,
Daniel

Re: Code of Conduct questions

[Daniel Stone]

Hi,
I've cross-posted this to freedesktop@, as the xdg@ list is only used
for actual specification development.

On Mon, 22 Oct 2018 at 00:36, Jacob Lifshay  wrote:
> Hi, we were thinking of asking if freedesktop would host Kazan 
> (https://github.com/kazan-3d/kazan) for us, however some of our community 
> members have objections with how freedesktop's Code of Conduct is currently 
> written. Would it be acceptable for a project on freedesktop to have a 
> different code of conduct as long as it has similar intent? The code of 
> conduct that we would like to use is similar to 
> https://libre-riscv.org/charter/

Unfortunately, this is not something we're willing to do. If there are
particular properties of the libre-riscv charter you'd like to see
included in the fd.o Code of Conduct, or specific concerns you have
with it, we (myself, Keith and Tollef) would be happy to hear it.

The biggest divide is between 'enumerating badness' vs. 'Bill & Ted',
to be glib.

Enumerating badness (e.g. the fd.o CoC, based on the Contributor
Covenant) specifically elaborates _examples_ of unacceptable
behaviour, in order to make expectations clear. It sets very clear
bright lines on unacceptable behaviour, whilst allowing the scope to
be larger.

Bill & Ted (from Bill & Ted's Excellent Adventure) follows the film's
mantra of 'be excellent to each other', and is often quite vague in
what this specifically means. Usually this takes the form of
self-encouraging platitudes: we're all adults, we're all
professionals, we all want to be nice, we all want great software.
These are all good sentiments.

The reason we chose a CoC which specifically enumerates badness, is
that it makes expectations clear, especially for newcomers. If the
community's norms are 'good not bad', and everyone always observes
those norms, then by definition no behaviour can be bad: if you feel
you're being excluded in a way which violates the code, you aren't.
Specific enumerated counter-examples help make it clear what is and
isn't acceptable, and prevents bad behaviour from being accidentally
but irreversably entrenched. (Anyone who attempted to play rules
lawyer and use technicalities to work their way out of the spirit of
the CoC would not get a welcoming reception.)

Personally, I'm also extremely uncomfortable with the parts making
clear that 'roles and seniority' are paramount and must be
acknowledged for everyone. The combination of the two is an excellent
way to entrench abuse and hostility to newcomers: senior people are
good not bad, senior people define what is good and bad, and you as a
newcomer effectively have no recourse to complaint. Regardless of what
the intent of the authors was, the effect is sadly the same.

Some more background on the different styles is written up here:
https://modelviewculture.com/pieces/the-new-normal-codes-of-conduct-in-2015-and-beyond

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Consider adding license information to freedesktop.org wiki contents?

[Daniel Stone]

On 6 May 2018 at 14:56, Thomas Kluyver  wrote:
> On Sun, May 6, 2018, at 1:56 PM, Daniel Stone wrote:
>> The wiki doesn't run on MoinMoin anymore. All the wiki content is
>
> I'm trying to get the history - a lot of the wiki pages in the current system 
> were converted from moin, so that old data is needed to try to work out who 
> wrote them. Sorry for not explaining that clearly enough.

OK, done now.

I understand the frustration, but we're all volunteers with
(extremely) limited time.
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Consider adding license information to freedesktop.org wiki contents?

[Daniel Stone]

Hi,

On 5 May 2018 at 18:50, Thomas Kluyver  wrote:
> I have found where the Moinmoin data is located 
> (/srv/www.freedesktop.org/moin/data on annarchy.freedesktop.org). Could 
> someone add me (takluyver) to the www-data group so I can investigate it 
> further? Or you could make all that data world-readable.

The wiki doesn't run on MoinMoin anymore. All the wiki content is
publicly accessible here:
https://cgit.freedesktop.org/wiki/

> On Sat, May 5, 2018, at 6:00 PM, Thomas Kluyver wrote:
>> I also stole about 30 sheets of toilet paper from a hotel a few weeks
>> ago. Please, someone explain property law to me!
>>
>> More seriously, it's clear that my proposed solution is not going to
>> fly, because we're taking copyright Very Seriously. Since we are taking
>> copyright Very Seriously, there are two problems:

Yes, we are because we have to.

>> 1. No-one can copy code samples from the wiki, or redistribute
>> specifications or anything, because they don't have a license. This is
>> what the thread was originally about, and it seems like a pretty major
>> flaw for a body making interoperability specifications for open source
>> software.

Most specifications are _not_ hosted on the wiki, but are hosted here:
https://specifications.freedesktop.org/

Some of those specifications have licenses, others do not. For those
without licenses, it would be good to fix that by getting the content
properly licensed by agreement of the contributors.

>> 2. Whoever runs freedesktop.org is violating all the contributors'
>> copyright by redistributing the content they created, because you're not
>> asked to grant a license when you edit the wiki.
>>
>> Is anybody interested in fixing this? Do we even have a record of who
>> edited what before the wiki was migrated to its current form?
>>
>> If you think we can live with the ambiguous copyright situation as it
>> is, then you weren't really taking copyright law Very Seriously, you
>> were just picking an argument with me for trying to suggest a solution.

Personally, yes, I am very interested in seeing the situation fixed
and regularised. Roughly in order, the steps to fix that would be:
  * agree with people who currently and regularly contribute, or who
have made substantial contributions in the past, what the new license
should be
  * declare this new license as required for new pages
  * contact the authors of old wiki pages and specifications, seeking
their approval to relicense content
  * tracking content which has not been relicensed and deciding at
some later stage whether to rewrite it, jettison it, or maintain it
with the old 'implicit' disclaimer

I don't have any time to do this, but will happily support anyone who
is interested in doing it, so long as it doesn't involve having to put
up with pointlessly sarcastic sniping.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Consider adding license information to freedesktop.org wiki contents?

[Daniel Stone]

Hi Boyuan,

On 13 April 2018 at 03:03, Boyuan Yang <073p...@gmail.com> wrote:
> Several weeks have passed and seems that there's no progress here; the mail
> copy sent to original discussion participants got no replies and one of the
> email address also bounces.

Sorry for the lack of reply, I've been quite busy lately. I also don't
have a great answer for you. We cannot post-hoc enforce a licence on
content: anything that is there is copyright to the actual author. We
can enforce a licence on new content, but relicensing the existing
content is quite a time-consuming process: first finding who wrote it
in the first place, and then getting in contact with them. The former
is difficult because we have moved from twiki -> MoinMoin -> ikiwiki,
in most cases losing history. We can find the history, but it takes a
lot of time. Secondly, this content dates back in some cases to 2004,
and contacting people after 14 years is notoriously difficult.

This is not to say that it can't be done, it's just that we don't have
the time for it right now. Volunteers welcome. :)

> It would be great if anyone could help me get into contact with the original
> author of 
> https://www.freedesktop.org/wiki/Specifications/file-manager-interface
> . Besides, I believe setting up a default license for freedesktop.org contents
> should be of higher priority given freedesktop.org's fame and importance in
> FLOSS world.

I've CCed the two people who I believe wrote the content originally,
who can answer for the spec. They could assign a licence to it and
perhaps move it to the specifications repo as well.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Freedesktop sdk aka 'tiny base runtime' project

[Daniel Stone]

Hi Laurence,

On 27 October 2017 at 15:45, Laurence Urhegyi
 wrote:
> So i wanted to kick off this mailing list by trying to round up a few things
> which have been discussed recently, at GUADEC, in f2f conversations
> afterwards, or shot over emails between a few people. It's been discussed
> for a while that we want to create a tiny base runtime with bst. The upshot
> is this will homogenize the metadata used in the build process for Flatpak,
> GNOME Continuous and eventually many other projects too, we hope.

Thiago's questions would be good to have an elaborated answer on. In
particular, whether BuildStream - which seems like it's only a few
months old - is a core part of the 'API' for the SDK, or whether it's
just incidentally used as part of the build process. I hadn't heard of
it until now, and would be curious to see if it's really used at all
outside of GNOME and Codethink.

> ## Objectives
>
> * Create and maintain a minimal base runtime using BuildStream definitions.

Same question as above: is the goal of the SDK to use BuildStream
definitions, or is BuildStream just something which happens to be a
part of it?

> * Establish neutrally located infrastructure to host the base runtime.
> * Implement an effective strategy for security updates to the runtime.
> * Ensure that the base runtime works with the relevant tooling in Flatpak
> and GNOME Continuous.
> * Replace flatpak builder with BuildStream to generate flatpak SDKs.
> * Replace Freedesktop Base Runtimes (based on YOCTO) with the base runtime.
> * Lastly, replace the GNOME Continuous (based on YOCTO) with the base
> runtime.

I'd ideally suggest establishing the goals of the SDK in terms of what
it's meant to provide to external users. That's something which is
actually compelling and useful: fd.o doesn't usually get involved in
projects whose sole goal is to _use_ a new build system.

> Some points on the above:
> * We're on gitlab.com for now as an interim solution before we migrate to
> freedesktop infra, or freedesktop migrates to gitlab.

For the record, I would very much like fd.o to migrate to GitLab.

> * Hardware will required at some point for the infrastructure.

What kind of hardware? Is that something you'd expect from fd.o, or
would you reuse, e.g. flathub and GNOME Continuous? Do you need
hosting, or build machines, or test runners, or ... ?
> ## Licence
>
> X / MIT
>
> No CLA to sign: All contributors hold their own copyright.

Is this just for the SDK - which I understand at this point to be a
bunch of build recipes and a conversion script from JSON/Yocto to
YAML/BuildStream - or are you talking about BuildStream itself?

> ## Code of Conduct
>
> We've discussed a simple but effective code of conduct, along the lines of:
> use common sense: don't abuse others and don't misbehave. When anyone does,
> folk should tell the mergers, who will be generally annoyed at the
> miscreants, and may take actions.

fd.o already has a Code of Conduct here, which we expect all new
projects to abide by:
https://www.freedesktop.org/wiki/CodeOfConduct/

If you have any specific input or suggestions, these would be welcome.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi Albert,
Sorry for the delay in getting back to you.

On Fri, 14 Apr 2017 at 11:18 pm, Albert Astals Cid  wrote:

> El divendres, 14 d’abril de 2017, a les 11:27:37 CEST, Daniel Stone va
> escriure:
> > The wiki also says that the sole purpose of fd.o is for X Window
> > System desktops, and that source code is often maintained in CVS and
> > Subversion. :\ It could use some work.
> >
> > Once upon a time that was true, but these days xdg@ sticks to the
> > actual XDG standards. It's a very bad way to reach quite a lot of our
> > member projects.
>
> Ok, could i suggest that maybe you need a list so you don't need to chase
> projects one for one when you intend to introduce such drastic changes in
> the
> future again?
>
> Because the only thing you're doing is offering excuses, which i'm not
> interested in, i'm interested in solutions.


I'm every bit as uninterested as you are in you are in assigning blame. I
think a separate list for project-wide issues is a very good idea, and I'll
set one up as part of contacting all the projects and finding concrete
points of contact / community responsibility. Unfortunately this has been
somewhat delayed by travel, but we're getting there.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi Albert,

On 13 April 2017 at 19:39, Albert Astals Cid  wrote:
> El dimecres, 12 d’abril de 2017, a les 17:49:56 CEST, Daniel Stone va
> escriure:
>> On 12 April 2017 at 09:05, Albert Astals Cid  wrote:
>> We did discuss this with a number of people, but with over 100 quite
>> diffuse projects (some active, some stagnant, some abandoned, some
>> unclear), and running fd.o not being a paid activity (or even the
>> primary project we work on) for any of us, we weren't able to reach
>> everyone.
>
> Why did you not use this list?
>
> The frontpage of freedesktop.org says
>
> "Contacting freedesktop: If you have any comments or questions about this site
> or its infrastructures, please send a message to the xdg list "
>
> So it seems that this would have been the obvious place to discuss the
> application of a Code of Conduct and making it easy for eveyone involved in
> freedesktop to learn about it from the source instead of from the news.

The wiki also says that the sole purpose of fd.o is for X Window
System desktops, and that source code is often maintained in CVS and
Subversion. :\ It could use some work.

Once upon a time that was true, but these days xdg@ sticks to the
actual XDG standards. It's a very bad way to reach quite a lot of our
member projects.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi Alexandre,

On 11 April 2017 at 12:43, Alexandre Franke  wrote:
>> Daniel Stone  schrieb am Di., 11. Apr. 2017 um 13:26
>> Uhr:
>>> Constructive feedback on the specific form and wording of the CoC is
>>> more than welcome. What would be even better is if you're able to
>>> point to the experiences of other communities, the discussions they've
>>> had, and where they landed. The exact wording isn't irreversibly set
>>> in stone, and I'm sure we'll want to be tweaking it over time. What is
>>> set in stone is that we (the fd.o admins, who unanimously approved
>>> this change) are committed to this CoC, and will not be turning back
>>> from it.
>
> I encourage you to read https://grep.be/blog//en/retorts/Codes_of_Conduct/

I'm familiar with the Debian CoC, and the discussions around its
introduction. I hadn't read Wouter's specific blog; it's an
interesting point, but I'm not sure I agree. It's definitely something
to consider though, and I'd like to compare it to best practice
elsewhere. Thanks!

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi Philipp,

On 11 April 2017 at 12:40, Philipp A.  wrote:
> Daniel Stone  schrieb am Di., 11. Apr. 2017 um 13:26
> Uhr:
>> Constructive feedback on the specific form and wording of the CoC is
>> more than welcome. What would be even better is if you're able to
>> point to the experiences of other communities, the discussions they've
>> had, and where they landed. The exact wording isn't irreversibly set
>> in stone, and I'm sure we'll want to be tweaking it over time. What is
>> set in stone is that we (the fd.o admins, who unanimously approved
>> this change) are committed to this CoC, and will not be turning back
>> from it.
>
> This is great news, as this way, the identified problems with its wording
> can be actually used to improve upon it. I was probably too much in the
> “software license” mindset, where a layman can’t dare to change the wording
> without fucking up. But actual feedback to improve this, based on other
> communities’ experiences? Sign me up.
>
> For one, I’d like to point to the Rust community, which also uses a CoC that
> begins similarly to, but is less problematic than the CC:
> https://www.rust-lang.org/en-US/conduct.html
>
> Regarding constructive criticism: The CC’s “Enforcement” paragraph is highly
> problematic. Its intent is clearly to foster accountability and prevent
> harrassers going unscathed due to being buddies with a mod. But it only
> protects the reporter, while nothing protects the (maybe wrongly) accused. I
> want to see a more “innocent until proven guilty” mindset reflected in a
> CoC. Accusing people shouldn’t be a powerful tool for harrassers, and witch
> hunts should be discouraged.

Is the enforcement section your primary problem with the CC, and how
specifically (in terms of actual language used - or not used) do you
see Rust's CoC as improving on this? Is it the piece where it insists
on the CC being both followed and enforced? If so, I personally read
that to mean that reports cannot be ignored, and problematic behaviour
cannot be waved away. I _don't_ read it as an assumption that every
report must result in action being taken against the accused, no
matter what. If we provided a tool which allowed anyone to kick anyone
else out of a community just by presenting a few magic keywords, we
would have utterly failed; I don't think the CC as written has done
that.

Thanks a lot!

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi Albert,

On 12 April 2017 at 09:05, Albert Astals Cid  wrote:
> El dimarts, 11 d’abril de 2017, a les 12:26:09 CEST, Daniel Stone va escriure:
>> Constructive feedback on the specific form and wording of the CoC is
>> more than welcome. What would be even better is if you're able to
>> point to the experiences of other communities, the discussions they've
>> had, and where they landed. The exact wording isn't irreversibly set
>> in stone, and I'm sure we'll want to be tweaking it over time. What is
>> set in stone is that we (the fd.o admins, who unanimously approved
>> this change) are committed to this CoC, and will not be turning back
>> from it.
>
> Can you clarify why do you think the sysadmins have the right to impose such a
> big change on the rest of the community without prior consultation?

freedesktop provides services to communities, including mailing lists,
bug trackers, Git hosting, web hosting, etc etc. We as the admins
already have to intervene to remove legally-impermissible content
(e.g. when someone uploaded third-party proprietary code they weren't
allowed to distribute, or when links to child pornography make it into
mailing list archives) from these services, because the responsibility
falls on fd.o as the provider rather than the more diffuse individual
communities.

Our original plan was to offer the CoC (pre-made template text and a
point of contact) as an opt-in, where projects could contact us and
add it themselves. But, as with the above, behaviour of the individual
communities reflects on fd.o as a whole. We aren't a diffuse/random
hosting site like GitHub, but instead work with individually-selected
projects. With this comes responsibility on both sides: we cannot just
wash our hands of the behaviour of the member communities.

We did discuss this with a number of people, but with over 100 quite
diffuse projects (some active, some stagnant, some abandoned, some
unclear), and running fd.o not being a paid activity (or even the
primary project we work on) for any of us, we weren't able to reach
everyone. My apologies if you/Poppler feel excluded, or imposed upon,
but you have my full attention now. :)

What I'm trying to do over the course of this week is get in touch
with all of the member projects and walk through this with them. Both
seeking their feedback, and establishing points of contact, so the CoC
and enforcement are actually driven by the communities themselves,
rather than being imposed from on high. I know that might seem at odds
with how this has been announced, so again please take my apologies
for that, but we are trying to do the right thing.

The text itself of the CoC is not set in stone, and if you have any
particular issues with the text that is there, it'd be great to get
any feedback so we can work on it. Just as our communities are living
and evolving creatures, so too is the CoC.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: xdg Digest, Vol 157, Issue 3

[Daniel Stone]

Hi to whoever lives under this pseudonym,

On 10 April 2017 at 13:35, Lazarus Long  wrote:
> ‎Would those CoC prohibit the creation of malware based on DBUS, UnionFS, 
> ConsoleKit, PolicyKit and a few others, using freedesktop.org to load these 
> malware modules? Then I'm all for it.
>
> You folks are really something.

Regardless of your opinion of software design, characterising
everyone's efforts as 'malware' is not OK. The term is very well
defined, and trolling isn't welcome here.

Replying to two other mails on the thread, which I don't have to hand:

We should've done a better job at announcing this. I am now in the
process of contacting all our member projects, of which there are
surprisingly many, to go through this change with them. In the
meantime some more details are at
https://www.fooishbar.org/blog/fdo-contributor-covenant/

The accusations levelled against the Ada Initiative by ESR, a noted
non-contributor of code to this and many other communities, would be
laughable if they weren't so insanely libellous. If the desire is to
be able to have unimpeded technical discussions, then accusing
external people (with absolutely no evidence) of trying to set up fake
sexual assults for ... well, I have no idea what anyone stands to gain
out of that, or why they would do that (neither does ESR), is really
not a great way to go about it. I can only offer my assurance that I
haven't introduced the CoC as a vehicle to either a) level fake sexual
assault allegations for unclear motives, or b) try to destroy the
livelihoods of others by doing the same.

Constructive feedback on the specific form and wording of the CoC is
more than welcome. What would be even better is if you're able to
point to the experiences of other communities, the discussions they've
had, and where they landed. The exact wording isn't irreversibly set
in stone, and I'm sure we'll want to be tweaking it over time. What is
set in stone is that we (the fd.o admins, who unanimously approved
this change) are committed to this CoC, and will not be turning back
from it.

Cheers,
Daniel
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Unsubscribing

[Daniel Stone]

All,
I'm unsubscribing from this list as it's too much to read, and tbh
desktop-entry-spec and similar aren't really my cup of tea. :)

fd.o sysadmin is now under control thanks to Tollef Fog Heen, who reads
sitewrangl...@lists.freedesktop.org as well as BZ.  It looks from the
complete lack of any activity whatsoever that the 'blessed specs'
movement is dead before it even started, sadly, so I guess there's no
need for me to hang around on here.

So, if you want me to see or respond to something, please mail me
privately or CC me.

Cheers,
Daniel


pgpWN9JxSywUB.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: evening the entry bar: git account management

[Daniel Stone]

On Wed, Feb 17, 2010 at 09:59:30AM -0800, Aaron J. Seigo wrote:
> On February 17, 2010, Daniel Stone wrote:
> > On Tue, Feb 16, 2010 at 12:24:50PM -0800, Aaron J. Seigo wrote:
> > > but it is linked to from the next sentence in the paragraph on the main
> > > page. the linked sentence itself is: "See AccountRequests for
> > > information on how to obtain CVS access to a project." CVS?
> > 
> > At the risk of being overly blunt -- it's a fucking wiki.  There's an
> > edit button; I'm willing to bet that it's fixable in far, far less time
> > than it took to write this email.
> 
> The first thing I tried was clicking on the edit button. I got a "this page 
> is 
> locked for editting". Yes, I was logged in.

I didn't realise -- my apologies.

> I see today that that has been changed and it is now editable when I click on 
> that button. That's great!
> 
> Even then, I don't think I'd just dive on in and edit without first getting 
> some basic directional consensus here. We currently lack the togetherness 
> around freedesktop.org to make changes that are coordinated without 
> communicating first. Over time that will change.

I hope so.

> I am tired, however, of what has become your trademark sarcasm and 
> grumpiness, 
> Daniel. Your "it's a fucking wiki" comment is exceptionally lame since this 
> was not the case yesterday as it was locked down then. Now, I don't know (nor 
> care) what crawled up your ass, but I really hope that the rest of us can 
> build a community around freedesktop.org that's more welcoming and friendly. 
> I'd prefer it if you could join us in making that happen since we need every 
> intelligent an well-meaning person we can get (and I do think you have both 
> of 
> those qualities).

At the risk of proving your point, I'll say that I'm polite and friendly
by default, until people give me a reason to be otherwise.  Suffice to
say that I'd count the last two or so years as reason to be otherwise.

> > > the text on AccountRequests is the opposite of friendly: "To obtain an
> > > account for a project hosted by freedesktop.org, you must follow these
> > > rules. Failure to do so will probably result in your request getting
> > > dropped on the floor. Don't take it personally if it does, the rules are
> > > there to make sure it doesn't happen, so if they aren't followed ..."
> > > 
> > > that doesn't particularly make me want to get involved.
> > 
> > Fair.  Do you have any particular suggestions?
> 
> Absolutely; basically it's just getting rid of the sarcasm and grumpiness, 
> like:

FWIW, the sarcasm and grumpiness was present from revision #1, which had
nothing to do with me whatsoever:
http://www.freedesktop.org/wiki/AccountRequests?action=recall&rev=1

> "To obtain an account for a project hosted by freedesktop.org, follow the 
> guidelines below. To ensure speedy processing of your request, please double 
> check that all of the necessary information is provided in complete form. 
> Account requests that do not supply all of the necessary information listed 
> below will not be able to be fulfilled and will instead be sent back to the 
> submitter with a request for more information. "

Sounds good -- feel free to throw that in there.

> > > the page doesn't describe who would qualify for an account or who i
> > > should consult to see i i might qualify (i've got to figure that part
> > > out for myself; ime, contributors rarely manage that on their own)
> > 
> > Which project are you contributing to? Are you writing a 3D driver for
> > Mesa, are you submitting a patch for a spec, ... ?
> 
> Absolutely; each hosted project should have a note describing who to contact 
> for such information. Or at least, there should be space provided for 
> projects 
> that wish to publish such information. (I don't expect all projects will want 
> to be open and inviting in this manner.) So for the xgd specs repo, it would 
> be great to have some text there describing who qualifies (anyone maintaining 
> a specification in the repository) and where they can be discussed 
> (xdg@lists.freedesktop.org). This probably belongs on a new page otherwise 
> there will be too big a listing and it will drown out the rest of the content 
> on the page.

Right.  It would be great if our projects had more coherence, but I
think the best we can do is for every project to have a page describing
what qualifies -- which will often not be objective; requests for X are
dealt with on a case-by-case basis, and there's no p

Re: evening the entry bar: git account management

[Daniel Stone]

On Wed, Feb 17, 2010 at 11:05:08AM -0500, Jeff Mitchell wrote:
> On 2/17/2010 10:36 AM, Daniel Stone wrote:
> > At the risk of being overly blunt -- it's a fucking wiki.  There's an
> > edit button; I'm willing to bet that it's fixable in far, far less time
> > than it took to write this email.
> 
> Can I just point out that editing fucking information on a fucking wiki
> that has to do with core fucking FDO policies may not be something that
> normal fucking people feel fucking comfortable with fucking doing, at
> the risk of incurring the same fucking kind of mighty fucking wrath as
> was just fucking displayed above?

Actually, it's a missing link on one page, rather than a change of a
core fdo policy per se.  Anyway, I'd like to think that over the past
few years or so I've tried to patiently help and do my best, but I'm
glad that's been reduced to one out-of-context quote which paints me out
to be some kind of unbelievable arse.

If you find me too objectionable to work with,
sitewrangl...@lists.freedesktop.org contains all the current admins
except myself.  Maybe they won't even use profanity if it shocks you
such that one occurrence in a 1101-word email causes you to fill an
entire paragraph with that same word to make a point, since apparently
being a grown-up is far too difficult.

Kindest regards,
Daniel, basking in the warming glow of appreciation from this list


pgppnuNMQyNQt.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: evening the entry bar: git account management

[Daniel Stone]

On Tue, Feb 16, 2010 at 12:24:50PM -0800, Aaron J. Seigo wrote:
> i'm starting a new thread for this because it really is a parallel issue and 
> i 
> don't want to hijack Vincent's thread to discuss it
> 
> On February 16, 2010, Daniel Stone wrote:
> > On Tue, Feb 16, 2010 at 10:21:02AM -0800, Aaron J. Seigo wrote:
> > > On February 16, 2010, Vincent Untz wrote:
> > > > I learnt a few days ago that we finally have a xdg-specs git repo. So
> > > > let's move forward :-)
> > > 
> > > great!
> > > 
> > > now, how do people get push access to it? trolling around on
> > > http://www.freedesktop.org i couldn't find instructions on how to apply
> > > for an account or who would qualify for it.
> > 
> > http://www.freedesktop.org/wiki/AccountRequests -- incidentally, this is
> 
> it's not linked to from:
> 
>   http://www.freedesktop.org/wiki/GettingInvolved
> 
> but it is linked to from the next sentence in the paragraph on the main page. 
> the linked sentence itself is: "See AccountRequests for information on how to 
> obtain CVS access to a project." CVS?

At the risk of being overly blunt -- it's a fucking wiki.  There's an
edit button; I'm willing to bet that it's fixable in far, far less time
than it took to write this email.

> the text on AccountRequests is the opposite of friendly: "To obtain an 
> account 
> for a project hosted by freedesktop.org, you must follow these rules. Failure 
> to do so will probably result in your request getting dropped on the floor. 
> Don't take it personally if it does, the rules are there to make sure it 
> doesn't happen, so if they aren't followed ..."
> 
> that doesn't particularly make me want to get involved.

Fair.  Do you have any particular suggestions?

> the page doesn't describe who would qualify for an account or who i should 
> consult to see i i might qualify (i've got to figure that part out for 
> myself; 
> ime, contributors rarely manage that on their own)

Which project are you contributing to? Are you writing a 3D driver for
Mesa, are you submitting a patch for a spec, ... ?

> the instructions are poor:
> 
> "Create a bug asking for an account. Select the Product that corresponds to 
> the Project for which you are requesting access. If there's no product in 
> bugzilla for the project in question, file it against the freedesktop.org 
> product, in the New Accounts component."
> 
> there is no hint as to what to use as the title or the component; i assume 
> that noticing requests for accounts happens by diligent people reading 
> through 
> all new bug reports? sounds like a system that lends itself to accidental 
> failure?

How do you suggest we do it, given that the projects themselves may have
wildly different methods for deciding who should and should not have
edit access to their project? What if the Mesa guys want something
different to the X.Org guys who provably want something different to you
who may or may not want something different to others on this list?

> i'd like to do more than observe/complain, but i can't edit any of these 
> pages 
> because the wiki is locked down even when logged in. so, sorry about not 
> doing 
> something about the above.
> 
> compare and contrast the AccountsRequest page with what we use in KDE:

This is irrelevant: KDE is a single monolithic project.  X.Org people
are not qualified to decide who should get a HAL account, or whatever.
So yes, it would be nice if policies were unified, but the reality is
that they're not because we are one host for myriad projects.

> > > how long does it take to get an account set up?
> > 
> > Not long.
> 
> how long is long?

97 minutes.

> what is the policy on what is too long?

Common sense.

> > > who is responsible for making this happen? (and hopefully it's more than
> > > one person)
> > 
> > A few people.  Not me.
> 
> where are these "few people" defined?

ssh annarchy.freedesktop.org 'getent passwd | cut -f1 -d: | egrep "R$"'

> what is the community accountability?

In what sense?

> how do they know if a request should get approved for a given product?

Well, as you can see from the AccountRequests page, people in a position
of authority for the particular project approve or deny the request, and
then forward it on to the admins who implement their wishes.

> in general, there is a lack of transparency that makes it more difficult than 
> necessary to get a grasp on how to get involved (or even if one would want 
> to).

What would you like to get involved with?

> i would li

Re: Migrating the specifications to git (xdg-specs repo)

[Daniel Stone]

On Tue, Feb 16, 2010 at 10:21:02AM -0800, Aaron J. Seigo wrote:
> On February 16, 2010, Vincent Untz wrote:
> > I learnt a few days ago that we finally have a xdg-specs git repo. So
> > let's move forward :-)
> 
> great! 
> 
> now, how do people get push access to it? trolling around on 
> http://www.freedesktop.org i couldn't find instructions on how to apply for 
> an 
> account or who would qualify for it.

http://www.freedesktop.org/wiki/AccountRequests -- incidentally, this is
also aliased by:
http://www.google.com/search?q=new+account+freedesktop.org&btnI=I'm+Feeling+Lucky

> how long does it take to get an account set up?

Not long.

> who is responsible for making this happen? (and hopefully it's more than one 
> person)

A few people.  Not me.


pgpP6ULI5j8pW.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

fd.o services outage, annarchy $HOME lost

[Daniel Stone]

Hi all,
Cutting and pasting from my blog entry[0] because I'm lazy:

> As ajax quite elegantly summed up[1], due to a series of catastrophic
> power failures at PSU, where fd.o is hosted, we were down for a good
> chunk of yesterday. Despite the machines having redundant power
> supplies, being connected to separate power rails in the rack, which
> were hooked up to independent, UPS-backed, power supplies, we still
> (like a good chunk of Portland, and certainly everyone in the PSU
> machine room) lost our power.
> 
> As far as we can tell, when annarchy.fd.o (websites, people.fd.o, cgit,
> anongit, et al) came back up, power was again interrupted while the
> ext3 journal was being replayed. When it came up the n'th time, fsck
> dumped almost the entire filesystem in lost+found, then started saying
> increasingly unhappy things about the state of the filesystem on its
> second pass. In the end, we just went with mkfs, and now we have a
> brand new and shiny filesystem.
> 
> It's worth pointing out that even if this was another filesystem, such
> as /srv, which hosts all project data, we would've been fine, as
> they're all backed up. But, unfortunately for some, we made a decision
> a while ago to not back /home up, and didn't advertise that as widely as
> we should have. So, if you had stuff in annarchy:/home, it's now gone,
> and I hope you have backups.
> 
> Sorry about that. On the upside, I got to see PSU's new and really very
> nice machine room this morning, thanks to XDC being about 250m away
> from the PSU machine room, and fd.o is otherwise running fine. We've
> been talking this week about replacing our ageing hardware, which would
> also allow for more redundancy as well as better performance from those
> machines. But we still have no plans to back up /home, so if you put
> stuff there, please, please keep your own backups (or make sure the
> Wayback Machine knows about it). 

Again, please accept our apologies.  The decision was made a long time
ago to not back up $HOME, and it was mentioned a few times, but
certainly not documented nearly as widely as it should've been (i.e.
shouted from the rooftops), given that a few people have lost data and
been upset about it.

The plan for when we get new hardware is to run the old hardware as
redundant backups, with regular rsyncs, so we can fail over and have
less downtime, as well as have a backup (of sorts) of $HOME.

Hopefully this doesn't put you guys out too much, and thanks for your
understanding.

Cheers,
Daniel

[1]: http://ajaxxx.livejournal.com/62015.html


pgpMXYncTBjvG.pgp
Description: PGP signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: freedesktop.org specification process

[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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Summary of the fdo disussion at GCDS

[Daniel Stone]

On Fri, Jul 10, 2009 at 09:53:58AM +0900, Daniel Bo wrote:
> > I know, it isn't easy to decide on this matter and we clearly can't
> > satisfy everyone right from the start (maybe never). But I hope you
> > understand that for me as an Xfce developer having to rely *entirely*
> > on other people's good will is not acceptable.
> >
> > Hopefully, the degree of participation in fd.o discussions will
> > I said I wasn't sure it's good enough. Maybe have a project list called
> > "Freedesktop.org Members" or something, and have representatives (and
> > please not the release teams again ;)) of these members decide on new
> > membership requests?
> 
> Maybe we can model approval on the RFC process.

We are not a formal, heavyweight, standards organisation, and never will
be.  The LSB exists for that purpose.

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

Re: Summary of the fdo disussion at GCDS

[Daniel Stone]

On Fri, Jul 10, 2009 at 01:13:59AM +0200, Jannis Pohlmann wrote:
> Hopefully, the degree of participation in fd.o discussions will
> increase (I think it already has improved a lot over the past weeks),
> but I fear that with only two projects having the final word on
> everything, we might eventually end up in lethargy with a lot of
> specifications pending approval because nobody cares about making a
> decision.

So you can offer a complete, ironclad, 100% guarantee that Xfce's
delegate will always remain completely responsive at all times? What
about Enlightenment? Everyone else? Surely that would only make the
problem _worse_, not better.

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

Re: freedesktop.org specification process

[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 .  
> 
> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Composit manager question

[Daniel Stone]

On Fri, Aug 11, 2006 at 01:49:44PM +0400, Oleg Sukhodolsky wrote:
> EWMH defines a _NET_WM_WINDOW_OPACITY hint to tell a composite manager to 
> make
> the window translucent. It allows to set just one value for the whole
> window. Modern
> application require an alpha-mask to be set to make some areas of the
> window fully
> transparent, others to be semi-transparent and the rest to be fully opaque.
> So the questions:
> 1. Is or will be there a standard way to set the opacity-mask by means
> of a hint?
> 2. If there's no a composite manager running, or the composite manager
> doesn't support the
> feature (like old and sweet xcompmgr :) ), what is the right way to
> set such a mask?
> Should the application implement the whole composite manager behavior
> and as such
> manage all the windows on the user desktop, not only its own windows,
> or is it enough to use
> some XComposite and/or XRender Extension features for that? What is
> the way to detect if
> the Composite Manager supports setting an alpha-mask instead of just one 
> value?
> 
> Any real code examples may also assist.

Use an ARGB32 visual.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Xfree86 with touch screen for pda

[Daniel Stone]

On Wed, Jun 14, 2006 at 10:24:26AM +0200, Dylan Cristiani wrote:
> i post this message here because Marc Aurele La France suggested me to 
> talk to Keith Packard here

You want to use the xserver tree at freedesktop.org, instead of using
XFree86 4.3.0.  The latter is very outdated.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: .desktop files, serious security hole, virus-friendliness

[Daniel Stone]

On Mon, Apr 03, 2006 at 03:24:51PM +0100, Scott James Remnant wrote:
> Uh, PIF file attacks were very common for a long time in Windows.

Are.  Viruses still use them to great effect.


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Dimming a laptop's backlight when idle

[Daniel Stone]

On Wed, Feb 08, 2006 at 11:21:23AM -0800, Aaron Stone wrote:
> Do the X people hang out on this mailing list? If not, where all do they
> hang out? fd.o seemed to indicate that xdg was the center of action for
> everything...

The 'xorg' list is, curiously, the centre of the X.Org universe.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: update-desktop-database location

[Daniel Stone]

On Tue, Feb 07, 2006 at 04:40:56PM +0100, Stanislav Brabec wrote:
> Christian Westgaard p??e v ?t 07. 02. 2006 v 15:45 +0100:
> > > But you can use:
> > > update-desktop-database 2>/dev/null || true
> > >
> > > Or specifically in current version of SuSE:
> > > SuSEconfig --module desktop-file-utils
> > > It is started after installation of any package.
> > 
> > I thought the idea was, not to have one check for every distro/version of 
> > distro,
> > but to have one common way, defined by a standard.
> 
> I understand.
> 
> And what about adding pkg-config file desktop-file-utils.pc, as other
> packages do. It can provide correct value of prefix, bindir etc.

Surely this just shifts the problem to a more obscure one?  This way,
you'll need to keep $(prefix)/lib/pkgconfig in $PKG_CONFIG_PATH, rather
than only having to remember to update $PATH.

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

Re: update-desktop-database location

[Daniel Stone]

On Tue, Feb 07, 2006 at 04:52:39PM +0100, Stanislav Brabec wrote:
> Daniel Stone wrote:
> > On Tue, Feb 07, 2006 at 04:40:56PM +0100, Stanislav Brabec wrote:
> > > And what about adding pkg-config file desktop-file-utils.pc, as other
> > > packages do. It can provide correct value of prefix, bindir etc.
> > 
> > Surely this just shifts the problem to a more obscure one?  This way,
> > you'll need to keep $(prefix)/lib/pkgconfig in $PKG_CONFIG_PATH, rather
> > than only having to remember to update $PATH.
> 
> Yes, but it is already done in products using obscure paths.
> 
> In difference to PATH (and "which" binary), pkg-config is intended to
> answer questions like:
> - Is package desktop-file-utils installed?

if which desktop-file-utils >/dev/null 2>&1; then
fi

> - Where are desktop-file-utils binaries installed?

which desktop-file-utils

> - Which version of desktop-file-utils we are using?

desktop-file-utils --version

I think it's overkill for your requirements, personally.

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

Re: Last Tango in fdo (was Re: Tango, Or How I Learned to Stop Worrying and Love the Desktop)

[Daniel Stone]

On Thu, Nov 10, 2005 at 11:49:33PM +, Richard Moore wrote:
> On Thu, Nov 10, 2005 at 06:42:33PM -0500, Adam Jackson wrote:
> > Which is a bit of an empty directive without actual names of people to go 
> > after and brutalize.  So, I must ask the crowd: who out there is actually 
> > saying freedesktop.org is a formal standardization body capable of 
> > enforcing 
> > the adoption of technologies or components?
> > 
> > If you can't answer that question with the name of a particular individual, 
> > then you may now stop squawking about "misrepresentation", because you've 
> > disproved your own assertion.
> 
> Here's an example from earlier in the thread:
> 
> http://www.desktoplinux.com/news/NS3533242304.html
> 
> There are 3 names there.

Searching for 'freedesktop.org', 'fd.o', 'f.d.o', and 'fdo' yields no
results.  Searching for 'standard' only reveals that they:
  * have created a specification to standardise icon names across
desktops (which, I will note, is not the same as calling something
'a standard', but seems to have a lot of interest from various
desktops anyway), and
  * 'hope to eventually provide a subsystem to help standardize
toolkits on a common look and feel'.

...,
Daniel


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Last Tango in fdo (was Re: Tango, Or How I Learned to Stop Worrying and Love the Desktop)

[Daniel Stone]

On Thu, Nov 10, 2005 at 11:20:53PM +, Richard Moore wrote:
> On Fri, Nov 11, 2005 at 10:03:06AM +1100, Daniel Stone wrote:
> > Why?
> 
> Because, as Travis intimated, what is being said about Tango does not
> reflect its true relationship with freedesktop.org.

So go out there and correct these misrepresentations.

> > Must I also yell from the rooftops that anything in Open Clipart isn't
> > necessarily 'the fd.o position' because it doesn't agree with several
> > peoples' ideas on styling?
> 
> The only mention of freedesktop in the openclipart homepage is a note
> saying where it is hosted - hardly the same.
> 
> [various off the wall examples deleted]

I don't see how they're 'off the wall' ...

> > (Pet peeve: it's freedesktop.org, not free.desktop.org.)
> 
> Well, if I'm abreviating Free Desktop Organisation, it's f.d.o.
> do we need a spec for this? :-)

FDO, surely.

> > > As I said earlier in this thread, currently people's perception of
> > > what f.d.o does is currently contradicted by the fdo web site. If this
> > > isn't fixed then fdo is acting against its own aims.
> > 
> > Interesting assertion.
> 
> Surely you agree that having the purpose of freedesktop.org misunderstood
> cannot help its aims.

I think that would be the best thing anyone could do for fd.o right
now, and I wish it were so.

> From the website:
> 
> 'Unlike a standards organization, freedesktop.org is a "collaboration
> zone" where ideas and code are tossed around, and de facto
> specifications are encouraged.'
> 
> Except, that's not how it is often represented. This in turn harms its
> use as a forum for collaborating.

So why don't you go out there and take on any misrepresentations you
see?  I don't see what's stopping you, honestly.  The wiki has said the
same thing for years, which seems to be as solid an authority as anyone
can appeal to here, so surely that's force enough to back you up.

Bored now,
Daniel


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Last Tango in fdo (was Re: Tango, Or How I Learned to Stop Worrying and Love the Desktop)

[Daniel Stone]

On Thu, Nov 10, 2005 at 10:20:16PM +, Richard Moore wrote:
> Ok then, perhaps f.d.o should simply put out a statement saying
> that what the people creating Tango are saying isn't the f.d.o.
> position, then continue to host it.

Why?

Must I also yell from the rooftops that anything in Open Clipart isn't
necessarily 'the fd.o position' because it doesn't agree with several
peoples' ideas on styling?

D-BUS isn't necessarily 'the fd.o position'?

The GTK-Qt engine?

'Get Hot New Stuff' doesn't necessarily align with our goals, however
hazily defined 'our goals' may be?

That we host planet.kernel.org doesn't mean we're about Linux
exclusively and we'd like to trample the rights of the BSDs?

Hosting Qt input methods means we all hate GTK?

(Pet peeve: it's freedesktop.org, not free.desktop.org.)

> As I said earlier in this thread, currently people's perception of
> what f.d.o does is currently contradicted by the fdo web site. If this
> isn't fixed then fdo is acting against its own aims.

Interesting assertion.


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Keep Tango-artists mailinglist

[Daniel Stone]

On Tue, Nov 08, 2005 at 06:55:05AM +0100, Torsten Rahn wrote:
> * which parts of Tango's "standards" are accepted standards by 
> freedesktop.org 
> (i.e. "just the i.c.n.") 
> * which parts of Tango's "standards" are accepted standards by the different 
> plattforms.  (i.e. "just the i.c.n.") 
> 
> Currently this is not the case and serves rather misleading and confusing to 
> the public perception of the project and its acceptance.
> 
> As long as this situation is not improved I don't see a reason to end this 
> thread.

fd.o does not 'accept' standards.  It does not have any process for
conferring standardisation or otherwise.  All it does is host various
documents (as well as random other stuff) in the hope that some of it is
useful.


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Remove Tango-artists mailinglist from FreeDesktop.org

[Daniel Stone]

On Mon, Nov 07, 2005 at 11:38:50PM +, seventh guardian wrote:
> I ask you all to read the WHOLE thread starting with this message:
> http://lists.freedesktop.org/archives/xdg/2005-November/007452.html

Yes, I have, and what I see is people wanting to host the
icon-naming-spec on fd.o (which has no formal power to convey
'standardisation', as it were), and some people who are unable to
disconnect the work the Tango project has done with i-n-s, and the
reference icon theme it has produced.


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Remove Tango-artists mailinglist from FreeDesktop.org

[Daniel Stone]

On Mon, Nov 07, 2005 at 11:06:27PM +, seventh guardian wrote:
> What I'm seeing here is people wanting to make Tango the freedesktop
> official theme, and I'm against that for many reasons.

There is currently no 'freedesktop official theme', and I can't imagine
a future in which there is.

> Freedesktop is
> taking a dangerous path: when everything is standard there's no
> individuality.

Apparently you have no idea how many different implementations of
everything (I can think of at least three projects to integrate
GTK and Qt at the mainloop level off the top of my head) fd.o tends
to host.  Sometimes, unfortunately, to the extent of being a little
too SF-ish.


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Remove Tango-artists mailinglist from FreeDesktop.org

[Daniel Stone]

On Mon, Nov 07, 2005 at 05:26:56PM +, seventh guardian wrote:
> > The tango project is a worthwile effort to bring  UI consistency
> > to UNIX desktops. The look and feel is an important  aspect of
> > desktop interoperability, and also includes icon themes. So
> > any efforts towards icon theme unification have a positive impact
> > on the desktop projects as a whole.
> 
> This I don't agree with. Any attempt to make the "look and feel"
> uniform across DM's is an attempt to create yet another Windows. I
> agree with standards like a Mime System or a common configuration
> directory, but the "look'n'feel" is something that shouldn't be
> standardized. That's what makes some DM diferent from another. If you
> take that away from us there's no point on existing multiple DM's. Kde
> could readilly merge with Gnome being that so.
> 
> And when someone talks about an uniform icon theme, that goes against
> the individual freedom. That's not linux. That is windows. If you want
> to create another windows, I'm off from freedesktop.org.

If you want to argue about Tango, please do it on a more appropriate
list.  Tango has its own lists.

If you want to rant about general fd.o project stuff, suggest using
[EMAIL PROTECTED]


signature.asc
Description: Digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: [OT] Mail duplicates, (Was: Re: Qt/GTK Skinning)

[Daniel Stone]

On Tue, Jul 26, 2005 at 12:02:39PM +0200, Kévin Ottens wrote:
> Le Mardi 26 Juillet 2005 11:52, Philip Van Hoof a écrit :
> > I wonder whether the Message-ID header differs. Can you check that? I
> > don't have the duplicates myself.
> 
> The Message-IDs are identical.
> I provide you the diff between dups for further investigation (if you want).
> 
> Hope that can help.

It's coming from the client -- broken MUA.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Account request procedure, random components

[Daniel Stone]

On Fri, Jul 01, 2005 at 09:44:05AM -0400, Owen Taylor wrote:
> If the procedure for requesting accounts is to stick them into
> bugzilla, there really needs to be a module for accounts unrelated
> to existing modules.

Yes, it is.  http://www.freedesktop.org/wiki/AccountRequests

> Is completely unrelated to the desktop entry specification, and
> it shouldn't be assigned to me.

Product fd.o, component New Accounts, means that the sitewranglers need
to take action and actually create an account.  Before that happens, as
we do not hand out accounts to random people, someone from the project
needs to approve (or reject) the account request.  This is why it is
assigned to the project.  The default owner for the product is a good
indication of who should deal with the request.

If this is insufficient, and your project hits this often enough that it
becomes a real drain on your productivity, you are welcome to request an
Account Requests component with a different default owner.  But the fact
remains that account approval must initially be done by a project
member, before sitewranglers can usefully deal with the request.

Bugzilla is used to represent this workflow by assigning it to the
project -- and person -- that needs to take action.  The project in
question at first, then later sitewranglers, after approval has been
granted.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg