Re: To GSOC mentors

[Jason D. Clinton]

I don't think this is true; you can get a Google Account without a GMail
account here: https://accounts.google.com/signupwithoutgmail?hl=en


On Tue, Mar 8, 2016 at 4:34 AM, Carlos Soriano Sanchez 
wrote:

> Hello again GSOC mentors,
>
> Forgot to mention an important information. The email address need to be a
> @gmail address.
> This is required by Google and we cannot do anything in that regard.
> However you can send us also a second non-gmail address to use for direct
> communication.
>
> Also, could you tell us a IRC nickname where we can contact you?
>
> Thanks and apologies for the inconvenience,
> GSOC admins
> ___
> soc-mentors-list mailing list
> soc-mentors-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/soc-mentors-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Rules for design in Gnome

[Jason D. Clinton]

Will probably regret writing this email, but here it goes, anyway.

On Wed, Apr 25, 2012 at 11:09 AM, Federico Mena Quintero feder...@gnome.org
 wrote:

 One of the main points of Nat's talk was that we were at a point where
 Gnome was ignoring innovation for fear of losing simplicity.  His
 presentation had a section called barriers to hacking, where he had
 items like lack of tools, but also items like lack of community,
 embarrassment (because your work is not seen as good enough),
 humiliation (because you get told that you are not up to Gnome's
 standards), and ridicule (you think *that* is a good UI?  It
 doesn't even follow the HIG!).

 There is a big slide in that talk that says, We need the cultural
 freedom to innovate.

 From what I've seen happen since the start of Gnome 3, we are at a
 similar period right now, where groups of Gnome developers are in
 discomfort because the dynamics of the project are working against
 them.


On the topic of history, I think that we can say with hindsight that the
later days of GNOME 2's lifespan (and the disjointed OS/tech stack
underneath it) cannot be held on a pedestal. We were handed a golden
market opportunity on a silver platter in the form of netbooks from ISV's
who actively sought *us* out, went about shipping, and offered support for
GNOME pre-installed on them--well in advance of the march of the Tablet
Empire. Just think about all of the thousands of people in the supply chain
from multiple vendors that were required to make that happen and then think
about trying to pull that off again. I hope that you feel that our failure
there was a tragedy. The market flat-out rejected what we had to offer.
Sure, any module proposal could get accepted in to GNOME at that time but
to what end?

Technology that a user or a platform developer cannot use because it isn't
usable isn't technology at all: it's techurbation.

But there is, as there always has been, a way forward: the people who have
a passion for a technology that they have brought in to this world
obviously envision a way for it to become accessible to users. I know that
you and Seif have that vision: I saw your presentation on Journal at the
2008 Hackfest and thought to myself, Fuck, yes! We *can* get there and
indeed I have watched multiple threads over the past four years on this and
related desktop activity logs topics propose ways forward. What I have seen
from the outside, though, is that the discussions always fizzled with
disagreement.

My question to you would be, why didn't agreement ever get reached? Why,
four years later, are we still arguing about desktop activity? I see a
failure of cooperation; not of the design team's but rather of the whole
project's.

(My views do not in any way represent those of Google.)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Jason D. Clinton]

On Thu, Dec 1, 2011 at 03:00, Frederic Peters fpet...@gnome.org wrote:

 Jason D. Clinton wrote:

   Because there's a big difference between an integrated, designed,
   polished, documented and translated GNOME app and something that
 happens
   to use GTK, right?
  
 
  That's the distinction between Featured Apps and everything else in the
  world. Core is for, well, core OS and desktop functionality that everyone
  can't do without. The only thing requiring approval today is Platform and
  Core.
 
  It certainly belongs in the apps moduleset where it is now so that it can
  facilitate easy jhbuilding. There's no approval required for the apps
  moduleset nor for Feature Apps (which is only a marketing distinction).

 Thanks for bringing this as that was certainly the plan but (by lack
 of resources in the marketing team?) it fell down and we got back to
 square one with the release team somehow handling applications, in
 this case Boxes.

 Somehow, because we didn't redefine criterias, in terms of
 documentation, schedule, all the things we had before. If people wants
 the release team to handle apps, we should get back to some processes.


When did this happen? I admit I've been a bit disconnected for a few months
but even if the Featured Apps didn't get updated, it was never intended to
be an exhaustive list. In fact, I explicitly stated in
the announcement (with blessing from the Release Team) that there was no
mechanism by which to apply for featured status and it was to be
construed as nothing more than what it was: purely a marketing designation.
There were only 8 Featured Apps the 3.0 and 3.2 release (these eight
http://www.gnome.org/applications/) *and* we still had an apps moduleset
for both releases.

So what has changed? I think that there's some confusion here and I'd like
to clear it up. As far as I know, everything is just fine: Featured Apps is
a marketing function and apps moduleset can include anything to facilitate
jhbuilding.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Jason D. Clinton]

On Thu, Dec 1, 2011 at 13:00, Frederic Peters fpet...@gnome.org wrote:

 But despite that announcement, most of the application module
 maintainers continued to follow the release schedule, and were part of
 releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/
 )


Yes, we want that and we get it without having to fight about Vinagre vs.
Boxes, for example. GNOME's process is a great set of best practices to
follow without having to involve the release team in picking GNOME
favorites (eg. The One True Music Player). And because it gives GNOME
translation and documentation teams an implicit schedule they can rely on.

Want to be part of GNOME? Join are community and you are. Want to be a
GNOME App? Follow our practices and you are.


Again, the question, what's the meaning of the apps moduleset? It's
 been the place for a serie of applications handled by the release
 team, remnants of the old modulesets, but doesn't it lack some more
 formal definition?


It shouldn't be handled by the release team because that gets us in to
these threads all over again which was entirely the point of implementing
this change. If that's been going on, it really shouldn't be.

The i18n coordinators add modules to Damned Lies; the Documentation
coordinators (eg. Shawn) track the Mallard work across modules; in the same
way, the release team or anyone with git access, really, can and should be
encouraged to add their build instructions to the apps moduleset.


If it's applications released by the GNOME project, shouldn't we get
 back some release criteria?


Module maintainers release their modules; GNOME provides infrastructure and
a community.


If it's just to facilitate jhbuilding, what's the difference between
 the -apps and the -world modulesets?


That should be fixed, I agree.


Well, there was the moduleset reorg announcement, but after that we
 also had 8 months of practice, and they don't quite fit, because in
 some sense, what has changed? nothing, applications still wanted to be

under the GNOME shelter, and the release team kept offering that.

 We put up a feature proposal period in place, and applications kept
 being proposed, and that discrepancy is part of this thread, Vincent
 wrote: I said that I didn't feel Boxes should be tracked as a feature.


If that's what happened then did we ever /really/ implement the change that
we all agreed on?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Jason D. Clinton]

On Wed, Nov 30, 2011 at 16:32, Andrew Cowie
and...@operationaldynamics.comwrote:

 On Wed, 2011-11-30 at 14:15 +0100, Luca Ferretti wrote:

  And, in suborder, why can't Boxes be simply a non-core, featured
  application, just like GIMP or Simple Scan?

 Because there's a big difference between an integrated, designed,
 polished, documented and translated GNOME app and something that happens
 to use GTK, right?


That's the distinction between Featured Apps and everything else in the
world. Core is for, well, core OS and desktop functionality that everyone
can't do without. The only thing requiring approval today is Platform and
Core.

It certainly belongs in the apps moduleset where it is now so that it can
facilitate easy jhbuilding. There's no approval required for the apps
moduleset nor for Feature Apps (which is only a marketing distinction).

Boxes looks wonderful.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v5)

[Jason D. Clinton]

On Tue, Sep 6, 2011 at 15:38, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Unfortunately, it seems this is
 not going to be blessed by GNOME, and questionpro.com only allows 10
 questions in the free version. I haven't found a better free online
 survey, and unless somebody offers hosting for this survey, it would
 have to be limited.

Google Docs Spreadsheets has a survey system built in to it called
Forms. It allows anonymous respondents.

 One problem raised was the issue of self-selection bias, of course,
 without any suggestions to get rid of it.

That's false. I gave you two strategies:

 You can mitigate this problem by
 offering a survey that appears to have nothing to do with the subject
 matter that you're really looking for an answer on so that you get a
 truly random sampling of Linux users. You also must be careful not to
 recruit people to take the survey from communities which will contain
 angry people. For example, going to forums to find people to take a
 survey automatically selectively biases from people who were likely
 there to solve some kind of problem and are so already in a particular
 state of mind.[1]

And you still haven't addressed the biased question phrasing in
questions 2 and 3.

[1] http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00051.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Jason D. Clinton]

On Wed, Aug 17, 2011 at 10:23, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Here's the fourth version of the survey, only tiny minor changes, it
 seems it's stabilized as there isn't many more comments.

 Shall we start planning the deployment? Who can get it into the site?
 Can I have access?

 How about an application that pops notifications similar to this one?
 Would such a thing be accepted?

You haven't yet addressed the problems that I pointed out.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v2)

[Jason D. Clinton]

Questions 2, 6, 7, and 8 are still leading. See my last email for a
discussion of how to fix them.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v2)

[Jason D. Clinton]

On Fri, Aug 5, 2011 at 12:09, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Aug 5, 2011 at 8:06 PM, Jason D. Clinton m...@jasonclinton.com 
 wrote:
 Questions 2, 6, 7, and 8 are still leading. See my last email for a
 discussion of how to fix them.

 Feel free to propose alternatives.

I'm not writing this survey for you especially after penning an email
explaining how to write non-leading survey questions and other
considerations that you need to take in to account before proceeding.
If you don't want to do this correctly then it would be better if you
didn't do it all.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v2)

[Jason D. Clinton]

On Mon, Aug 1, 2011 at 10:35, Felipe Contreras
felipe.contre...@gmail.com wrote:
 After going through all the feedback, here's the second version of the
 proposed survey.

Surveys require careful consideration of the phrasing of questions and
careful consideration of the selection bias of respondents. It doesn't
look like you have considered either, even after the bias in phrasing
of the questions was pointed out to you in the first round of emails.

For example, here's a classic:

  Do you approve of the President's job on foreign affairs?

versus:

  How would you rate the President's job on foreign affairs?

The first question is leading by punching the survey taker in the face
with a statement about their value judgement before you've even
finished saying the sentence. The second asks the survey taker to make
their own value judgement.

Second, you have to carefully consider who is motivated to take a
survey. People who are angry are much more likely to respond to a
survey versus people who are happy. You can mitigate this problem by
offering a survey that appears to have nothing to do with the subject
matter that you're really looking for an answer on so that you get a
truly random sampling of Linux users. You also must be careful not to
recruit people to take the survey from communities which will contain
angry people. For example, going to forums to find people to take a
survey automatically selectively biases from people who were likely
there to solve some kind of problem and are so already in a particular
state of mind. There are hundreds of strategies to work around the
selection bias problem.

It *is* a good idea to run a survey but unless it's done carefully,
you could actually do far more damage than good by reporting results
which are not accurate or--worse--call in to question the motivations
of the study.

The survey you're proposing will require months of work to do
correctly and is likely best achieved as a part of a large group
effort or as part of an academic or non-profit funded venture.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[Jason D. Clinton]

On Wed, Jun 1, 2011 at 11:38, Johannes Schmid j...@jsschmid.de wrote:
 Pretty good list of examples. All of these projects are mostly driven by
 Red Hat full-time employees (which isn't a bad thing in general). It
 happens to be the same company employing big parts of the core design
 team.

 While this doesn't mean it is a closed group of people, for an outside
 developer or volunteer it pretty much feels like that even if the
 individuals of that group are totally open to external
 contribution/envolvement.

To *who* does it feel that way? If you're going to insinuate that
people have tried to get involved and been rebuffed, then I think the
responsibility here falls to you to provide an example. Please don't
talk around the accusation by inferring that it's some kind of RH
conspiracy. It's not.

Allan Day is certainly a counter example.

Another counter example is that I have only been able to do the
marketing work that I have done by *listening* to the design process
so that I could articulate it to others. At no point have I felt like
the design team was inaccessible.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[Jason D. Clinton]

On Wed, Jun 1, 2011 at 14:31, Frederic Peters fpet...@gnome.org wrote:
 On Wed, Jun 1, 2011 at 11:38, Johannes Schmid j...@jsschmid.de wrote:
  Pretty good list of examples. All of these projects are mostly driven by
  Red Hat full-time employees (which isn't a bad thing in general). It
  happens to be the same company employing big parts of the core design
  team.
 
  While this doesn't mean it is a closed group of people, for an outside
  developer or volunteer it pretty much feels like that even if the
  individuals of that group are totally open to external
  contribution/envolvement.

 To *who* does it feel that way? If you're going to insinuate that
 people have tried to get involved and been rebuffed, then I think the
 responsibility here falls to you to provide an example. Please don't
 talk around the accusation by inferring that it's some kind of RH
 conspiracy. It's not.

 Johannes is definitely a active member of the GNOME community, and in
 my opinion the work he has been doing to make it possible for new
 developers to come and use our platform is underestimated (Anjuta,
 the dev doc tools hackfest, the continued work on platform demos,
 etc.).

 Therefore I don't think you should dismiss what he wrote, as if he had
 just a vague knowledge of our community, mimicking his message as
 there's a Red Hat conspiracy.

I know who Johannes is. Let me be more clear: Johannes, do you fear
that the design team is exclusionary or have you actually seen it
happen? If the later, let's see if there is something from that
experience that informs about a way we can improve things.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[Jason D. Clinton]

On Thu, May 19, 2011 at 10:02, Michael Terry m...@mterry.name wrote:
 True.  I guess I'm really just interested in an official answer to
 What are the criteria for deciding which platforms are within GNOME's
 scope?

Those for which people whom want them to work show up and do the
integration work needed, as it's always been. I don't see anything in
this thread that indicates that we're changing this position, at all.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[Jason D. Clinton]

On Fri, May 13, 2011 at 10:28, Gendre Sebastien ko...@romandie.com wrote:
 If I summarize the choice of Gnome Dev about panel by an exemple: The
 choice of operating system to boot at startup. They don't want to see a
 panel for manage Grub, a panel to manage Lilo, a panel to manage EFI,
 etc. But they want to see a generic panel make directly in Gnome Control
 Center and different back-end for each technologie. All that to have
 only one UI for all usage and don't break the logical of all Gnome UI.

Please see David's 5th reply to this thread about what our plans for
boot loader UI is.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Feature Proposal: Backup

[Jason D. Clinton]

On Thu, May 12, 2011 at 03:34, Allan Day allanp...@gmail.com wrote:
 That wouldn't be an issue if Deja
 Dup were applying to be an application

There is no process of applying to be a GNOME application except
perhaps requesting infrastructure hosting--but that's available to
anyone, really.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[Jason D. Clinton]

On Thu, May 12, 2011 at 14:45, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
 Technically, if the architecture only allows extension through
 patching (instead of extension points), it means the architecture is
 closed (that must be a highly offensive statement, if we're talking
 about free software).

So every piece of free software that hasn't yet implemented extension
points is offensive to free software, according to you? Doesn't that
seem like a somewhat extreme position?

 Also, that is a very effective way to alienate
 3rd parties (app developers, distromakers).

Not really, no. UI's that users don't want to use because they are
confusing alienates 3rd parties because, well, we don't have any
users. Why don't we get some users and then worry about alienating
developers by encouraging good design?

 I suspect, that attitude
 in gnome possibly affected Canonical decision to drop gnome 3.

This is completely fabricated speculation which is, in fact, not true.
Please refrain from spreading false information; that doesn't help
anyone.

 distros have to either patch g-c-c
 to introduce distro-specific capplets (maintaining patches is not the
 same thing as maintaining separate modules using relatively stable
 APIs)

We don't want 3rd parties putting things in g-c-c--that's all we're
saying. But it's free software; they can if they want to, of course.

 GNOME is not an OS.

But it could be.

 GNOME is not a distribution.

Right.

 GNOME is a core
 desktop (desktop building toolkit, if you like)/

We want it to be more.

 All those rants aside, let me ask one question: is this APIlessness
 considered as a temporary measure (I know, gnome 3 is currently highly
 undocumented - at least I did not see g-c-c 3 UI guidelines) for some
 transitional period or is it a policy that is planned to last in
 foreseeble future of gnome3?

Couldn't you have asked before ranting?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

[Jason D. Clinton]

On Thu, May 12, 2011 at 14:52, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
 For something like this, I have a feeling we may only get one chance. If
 you don't allow any differentiation on top of GNOME, there is at least
 one distribution that will just do preferences differently  ignore
 control-center. And I can imagine that future environments along the
 lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences
 from scratch, rather than building on the gnomecc work.

 They are doing that anyway, and there is nothing we can do to stop them.
 Why are they doing that? Isn't that a very important question? Is just
 just because of them - or is it about GNOME as well?

Because we don't have a mobile focus yet? Sure that would be about us.
But the lack of mobile focus has nothing to do with this thread.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[Jason D. Clinton]

On Thu, May 12, 2011 at 16:51, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
 I totally agree, IMHO GNOME is a base to allow distributors, vendors and
 third parts to build up and extend their own user experience and
 services and fight on free market. No competition means stagnation.
 Yes, very true. GNOME wants to dictate some policies. Fair play,
 because we own the code. But that dictate may kill gnome publicly - if
 distros would not want to be dictated.
 Back into the history, X11 provided mechanism, not policy. GNOME
 enforces policies. Fine, but let's not go too far with this dictate.

 And anyway, even if we dictate policies - at least we should have
 courtesy to put them in words, I guess.

We're not dictating anything; we're just making an awesome OS, the way
we envision, period.

Dictating is what Mozilla tried to pull with their trademark policy.
We aren't doing that. And I can't see us ever trying to do that,
either.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

[Jason D. Clinton]

On Tue, May 10, 2011 at 19:15, Luca Ferretti lferr...@gnome.org wrote:
 #3 -- I feel this no-API for gnome-cc approach crashes with planned
 and upcoming changes in GNOME Desktop modules definition

There is no GNOME Desktop module; we now have only core, platform and
bindings. What are you speaking of?

, as well as
 with the idea of GNOME as platform for everyone

What is this and where was it proposed?

. This proposal from
 Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core
 module (as per current definition of core: only stuff needed to start
 user session), but it's perfect as approved by GNOME module.

No, we do not have any such plans to approve or disapprove of modules.
If they are outside of core, platform or bindings, the only official
designation is that they might be featured in our marketing. That's
it. We do not bless modules any more.

 Also,
 IMHO the UI proposed changes to Deja-dup preferences are well designed
 for GNOME 3 experience (backup as a service, not as user launchable
 app). So, this seems to be a contradiction: we can't place you in core,
 but we don't want to provide the ability for a proper integration. Also,
 what about third parts, vendors and distros?

That's a technical problem, not political.

 For instance, Ubuntu
 provides a really useful Additional Drivers tool and I suppose the best
 place for it is System Settings  Hardware; same for Prey
 (http://preyproject.com/) and it's configuration panel. Are we going to
 make GNOME a closed desktop?

Again, technical.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Jason D. Clinton]

2011/5/8 Erick Pérez erick@gmail.com

 But if you want to go ahead and build whatever your idea appears to be,
 nobody's going to stop you.
 And this is just rude and useless.


This is how free software works. If you want something, you just do it. And
then show everyone how awesome it is. Or you find other people who already
agree with you and you all go off and just do it together. And then show
everyone how awesome it is.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no way to change theme or fonts in System Settings?

[Jason D. Clinton]

On Wed, Mar 16, 2011 at 21:31, Adam Dingle a...@yorba.org wrote:
 In the current GNOME 3 build the System Settings application doesn't seem to
 give me any way to change my fonts or theme.

Fonts  A11y capplet.
There are no other GTK+3 themes available at the moment.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moduleset Reorganization -- Take two

[Jason D. Clinton]

On Tue, Feb 1, 2011 at 02:47, Frederic Peters fpet...@gnome.org wrote:
 Too slow probably, so after discussing things at the Boston Summit,
 new modulesets written by Jon McCann[1] were pushed, those were
 certainly close to what the release team envisoned, but they also had
 their share of problems, and the release team, and other teams, had to
 follow suit, fixing both those new sets, and the various tools that
 had been broken in the change.

Hi everyone! I bet you were hoping you'd never see another email on
this thread! ;-)

For everyone's reference, the defined modulesets are here:
http://git.gnome.org/browse/jhbuild/tree/modulesets

But that's not what this email is about. This email is as much as
follow-up to this thread as it is a follow-up to the Summit discussion
documented here http://jasondclinton.livejournal.com/82450.html.
Specifically, the argument over Featured Applications. At the time,
after the session, Vincent, Ryan Lortie, and I spoke some more and I
proposed a compromise which they both liked: Release Team continue to
administer the formal new module proposal process for Core (that is,
everything which would be considered part of GNOME OS and is
currently in the Core moduleset) and external dependencies process as
they are handled today and Marketing Team would select applications
from the entire GNOME ecosystem to feature in marketing materials as a
means by which to promote application quality and our ecosystem. There
had been no further communication between us about this proposal until
today.

Today, representatives from the Marketing Team (Andreas, Allan and
myself) and Vincent, representing the Release Team, discussed this
because it is time to select featured applications for 3.0's
marketing. We agreed to move forward with this proposal. Beginning in
the next few days the Marketing Team will select applications to
feature for the 3.0 release. The criteria will be the following:

1. Quality
2. Solving a popular problem
3. GNOME-iness
4. Bonus points for cross-platform-iness

Our goal is simply to promote the GNOME ecosystem in any manner that
makes sense from a marketing perspective. Being a featured application
is transient, canonically maintained as a list that happens to be live
on our web sites at any given moment, and not particularly a badge of
honor to be fought over or bandied about from a module's perspective.
(It is not a statement that it is *the* GNOME app. of any particular
function.) It merely reflects the Marketing Team's feelings about the
application’s status on the above 4 criteria. And obviously, marketing
being visually dominated, visual things are likely to get more
attention.

Marketing Team will look at (and build from source with jhbuild!)
first applications which appear in the apps moduleset defined above
but we may look outside the jhbuild modulesets. New projects or new
application module maintainers are encouraged to continue to go
through the process of having their application included in the
jhbuild moduleset by the normal means (Bugzilla) to make it easier for
us to screenshot. We are not making any judgments about political
things like the locations of the project hosting. For example, we all
agree that Simple Scan, though hosted on LaunchPad, is going to be a
featured application. Also, we all agree that both Banshee and
Rhythmbox are excellent applications which will both be featured.
There's no reason to select just one.

In the meeting today we did not address the concern of translator
attention which was raised at the Summit but my personal feelings on
the matter are that translators will continue, as they always have, to
translate those modules which are popular regardless of whether they
are featured or not.

To make it absolutely clear, the list of featured applications is that
list which is featured on the web at any particular moment. There’s no
formal add or remove process except that normal process by which
marketing is done. People interested in having their application
featured are always welcome to mail the marketing-list to bring
something new to our attention.

Marketing Team, now more than ever, could use volunteers and is always
open to additional members. If you’re interested in joining the
Marketing Team, hop on IRC and join #marketing and join the mailing
list; we’d love the help.

One final note: at this point this is going to be JFDI by the
Marketing Team but we are always interested in hearing the GNOME
Community’s feedback. Please direct any comments or questions that you
have to marketing-list (note the CC).

Thanks for making so many awesome applications to choose from!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: (Re: GNOME 2.91.90 build issues (tracker, network-manager-applet, libpeas))

[Jason D. Clinton]

On Tue, Mar 8, 2011 at 13:22, bsquared bwcod...@gmail.com wrote:

 regarding the response here:
 http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00022.html

 where it indicates that these tarballs should be used.

 http://ftp.acc.umu.se/pub/gnome/sources/NetworkManager/0.8/NetworkManager-0.8.995.tar.bz2

 http://ftp.acc.umu.se/pub/gnome/sources/network-manager-applet/0.8/network-manager-applet-0.8.995.tar.bz2

 Is there a patch available for the moduleset(s) in
 http://ftp.gnome.org/pub/GNOME/teams/releng/2.91.90/?


With a little luck, 2.91.91 will be out tomorrow and it should have the
moduleset change you're looking for.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: UI Mockup for Gnome 3.XX Share section of System Settings

[Jason D. Clinton]

On Sun, Feb 6, 2011 at 15:10, Gendre Sebastien ko...@romandie.com wrote:
 To meet the demand of Jason D. Clinton, The orignial message of this
 trhead:
 http://mail.gnome.org/archives/desktop-devel-list/2010-December/msg1.html

 And the link to bugzilla:
 https://bugzilla.gnome.org/show_bug.cgi?id=636206

I contacted you off-list to help you understand that you were sending
an email with no context to a list that has nothing to do with the
topic without the danger of it being interpreted as a public rebuke.

In the future, please assume people mean well and do not direct
off-list email back to a public list.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IRC channels in gnome development

[Jason D. Clinton]

On Sat, Feb 5, 2011 at 13:43, Maciej Piechotka uzytkown...@gmail.com wrote:
 While it might be a stretch analogy but some people argue in various
 companies (not every company and it may be argued how good the policy
 is) to open the discussion/design process to community (I think I heard
 about Dell, Starbucks and others). Of course it is company who plays the
 role of beneficial dictator in this model nonetheless the consumers may
 be proven to be valuable source of feedback and ideas (even if the need
 to be filtered out).

You characterized the situation with the power manager as a crisis
and yet, while your description is more than a little hyperbolic, that
situation demonstrates that precisely what you are asking for is not
productive. There were a total of four blog posts on the topic and
approximately 200 comments posted to those. There wasn't any negative
feedback on any of those four post's comments that was well researched
or particularly informed about all the issues that need to be
considered. Even people who tried to offer alternatives didn't seem
particularly informed about common use cases or what other operating
systems are doing (all research that had previously been done by the
design team). There was some legitimate concerns expressed,
particularly about why the research shows that AC and on-battery are
the same situation, but that was a tiny minority of the feedback and
not surprisingly, a large majority of this informed discussion
happened on IRC in #gnome-os and #fedora-desktop--not on a mailing
list or blog.

Design is a process which anyone is welcome to get involved in by way
of researched proposals, mock-ups, or use-case studies. But asking the
design team to post every decision that they make to d-d-l so that
they can have the opportunity to be stop-energy-ed by community
members who haven't researched or considered the situation, would not
be productive.

That isn't to say that more wiki documentation couldn't help.
Specifically, I need some more documentation to make one of the
marketing videos that are upcoming. But I'm not asking for that
information so that I can argue about it--I'm not on the design team.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IRC channels in gnome development

[Jason D. Clinton]

On Feb 5, 2011 5:15 PM, Maciej Macin Piechotka 
maciej.piechotk...@imperial.ac.uk wrote:

 On 05/02/2011 21:55, Jason D. Clinton wrote:
  (all research that had previously been done by the
  design team).
...
 FLAMEThen show delyourdelinsdesign team/ins work!

http://live.gnome.org/action/info/Design/SystemSettings/Power?action=info
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Jason D. Clinton]

On Tue, Jan 4, 2011 at 12:00, Holger Berndt h...@gnome.org wrote:

 On Di, 04.01.2011 18:47, Gendre Sebastien wrote:

 Le mardi 04 janvier 2011 à 16:27 +0100, Holger Berndt a écrit :
  As it puts your posts into context, you could have mentioned that
  you're actually the maintainer of Sawfish. In all of your posts in
  this
  thread, I don't hear a concerned user, but an annoyed WM developer,
  angry that the GNOME Shell doesn't work with his baby.
 
  That also explains why your perception of the amount of users who want
  to replace their WM differs from others. I'm absolutely sure that you,
  as Sawfish maintainer, know a lot of users of Sawfish and other 3rd
  party WMs. I doubt that you're representative for the general GNOME
  user base, though.
 
  Non-IT users don't know what a WM is. They don't want to know, and if
  they need to know what it is and how to replace it, something is
  broken in the first place, and work should be spent on fixing
  the problems instead of abstracting them.
 
 Please, if you have no good arguments, don't try to marginalize and make
 personal atttak on people with whom you are desagree.

 I'm not personally attacking people with whom I disagree. I just
 described where the different perception of how many users want to
 replace their WM might come from. Which is quite a central point when
 discussing whether it's hugely important to be WM agnostic, or not.


Let me add, with my Marketing Team hat on, that we would *never* emphasis
the modularity of any part of GNOME as a feature to be marketed to end
users. Even if you look back through our release notes from past releases
all the way back to 2.0, we have never shown off the modularity of the
desktop. It's not a narrative that makes sense from a marketing perspective.
It would be like releasing a new car and then telling the buyer that the
tires that are included aren't good enough but that's okay because they are
free to go through the trouble of replacing them right after they take
ownership. Modularity is not a feature; a good feature is a feature.

If a user has to do a bunch of customization after installing to get
a tolerable desktop experience, we have failed at design. We are finally
addressing that and that is one of the many reasons that I love GNOME Shell.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Jason D. Clinton]

On Tue, Jan 4, 2011 at 12:25, Alan Cox a...@lxorguk.ukuu.org.uk wrote:

  It would be like releasing a new car and then telling the buyer that the
  tires that are included aren't good enough but that's okay because they
 are
  free to go through the trouble of replacing them right after they take
  ownership. Modularity is not a feature; a good feature is a feature.

 You wouldn't be a very good car salesman then would you ? In fact people
 loathe and hate the lock-ins wired into cars.


Please do not be hyperbolic; we aren't locking anyone in to anything except,
in this analogy, saying that putting a Hemi engine in a sub-compat is
outside the scope of our design goals.


 Plus of course the first
 thing anyone does when they get into a car is umm

Adjust the mirros
Adjust the seats
Adjust the music
Adjust the airconditioning
Adjust the satnav
Fit random personal objects (modularity)
...


That's personalization, not customization, and is completely within the
scope of will be implemented in GNOME 3: themes, backgrounds, localization,
a11y, favorite launch items, etc. And has been said before, that's just the
beginning: by 3.2 we hope to have a well-defined extension API so that even
more *personalization* is possible.

I'd like to use a random bluetooth hands free, sorry our car is only
 available with our official hands free option

 radio, ours only

 satnav, ours only

 engine management, ours only, DRM protected and we sued the other guys

 I need snow tyres, sorry we don't support snow tyres, you don't need
 them.

 I added go faster stripes You've voided the warranty

 The car market is such a mind-numbingly bad example, in fact it's the very
 market whose abuse led the european union to pass legislation to limit
 the power of no reverse engineering clauses, that later proved such a
 good situation for software !


Fine, pick another analogy then. You got my point and now you're just going
off on a rant about cars.


  If a user has to do a bunch of customization after installing to get
  a tolerable desktop experience, we have failed at design.

 If the user can't then customise it to get a nice desktop experience to
 suit their needs after that you've also failed. That of course cuts both
 ways - it can have so much stuff you can't configure it.


You appear to have missed my point: if it's not a nice desktop experience to
begin with, it's too late. We are working on *that*, not asking the user to
do it for us.


 The distros gather hardware info with permission from plenty of users so
 they ought to be able to answer what percentage of our users can run
 this stuff.


Anything newer than 5 years old. Though we started saying that last Spring
so it's going to be 6 years old by the time we release this Spring--which is
longer than I've kept any computer.


 Not sure if they have enough data to do what portion of our
 users desktops can be seamlessly migrated - ie all the equivalents for
 each applet exist and the settings can be mapped


None, and that's a completely unrealistic expectation. We don't change the
UI paradigm and expect things to behave as they always have; that would be
by its very definition be the same paradigm.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Jason D. Clinton]

On Tue, Jan 4, 2011 at 13:58, Christopher Roy Bratusek
zang...@freenet.dewrote:

  I'm not personally attacking people with whom I disagree. I just
  described where the different perception of how many users want to
  replace their WM might come from. Which is quite a central point when
  discussing whether it's hugely important to be WM agnostic, or not.

...

 Well, I already said, but still, I'm speaking what users think. I'm reading
 it
 on Forums, OpenDesktop, ProLinux, ML  Co. All I wanted is that people at
 least listen to it, but for some this seems impossible.

...

 But as some have unvealed today, it's not the real reason, marketing is the
 magic word and to provide a desktop made from one, and some other less
 valid
 reasons (eg.: even if you allow modularization you can provide great user-
 experience as modifications made by the user bother him/her not you).

 So today I finally got the real reasons told and I told you my opinion
 (with
 wich, as you can see from the responses, I'm not alone).


Your tone and behavior is outside the bounds of what I care to continue to
engage and so this will be my last response to you. I said that I was
speaking as a member of the Marketing Team. The MT had *no* involvement
whatsoever in guiding the design of GNOME Shell. Jon and Jakob's UI Shell
designs stand on their own as good user interface design--that is their
goal, nothing else. The MT's job is to take the finished product and narrate
that to the outside world. You cannot take anything else from what I wrote.


 Just one last thing for now: Most of those who disagreed with me are
 developers, most of them who agreed with me are users. For me that means
 that
 I'm right when I say I'm pointing out what I heard from users all around
 the
 places.


No one subscribed to d-d-l would be representative of our end users. I could
not even consider the occasional unhappy enthusiast on a forum
representative.


 Also note the discussion about the applets, there where several people
 complaining. Next take into account that you a) have to register for this
 ML
 and b) be brave enough (lots of users simply don't ask/complain/comment
 because they think they don't are allowed/have the right).

 Now if you take the complaining people from all places mentioned above and
 all
 other places I never visited (regional forums, LUGs etc pp), you can be
 sure
 that more than 1% is unhappy with your decision.

 Of course it's yours, but it must be possible that critics aren't
 automatically interpreted as rants or attacks. I got the feeling some
 around
 here do that.


You are ranting and your tone is entirely accusatory.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[Jason D. Clinton]

2011/1/4 Mario Blättermann mari...@gnome.org

 Am Dienstag, den 04.01.2011, 20:58 +0100 schrieb Christopher Roy
 Bratusek:
 Have a look at the most important GNOME-reseller Ubuntu: There will be
 no gnome-shell by default, they have decided to use Unity. Well, due to
 it is also clutter-based, there will be similar problems. Moreover, the
 help browser doesn't show the usual overview of the GNOME docs, instead
 users see the Ubuntu Help Center, and there's no way to browse to
 GNOME's Desktop User Guide. Most distributions have such »features«,
 which lead the user to accept his distribution as a unique OS, and to
 accept GNOME as a second stage free gift. Could be that the gnome-shell
 won't flop because of misusability, but because of too less users take
 notice of it.


Yes, we were concerned about this as a Marketing Team when we met in October
2009 at Google's office in Chicago and decided then to make a special effort
to reach out to distributors to offer marketing assets that they could brand
with their own logos. Unfortunately, Ubuntu made their Unity decision before
we could get to that point and for business reasons. I still hope that users
will see a vastly superior experience in other distributions (ie. Fedora)
which ship Shell by default and encourage Canonical to reevaluate their
decision. And we will still make the marketing assets in such a way that any
distribution can take and remix them for their own use. Hell, we don't even
care all that much that GNOME plays a prominent role in downstream
distributions' marketing. Enthusiasts who can become developers will
understand what GNOME is. All we have to do is help distributions get users
excited about the improved, awesome user experience--that's the only way an
end user can get GNOME anyway. We understand that this is a very different
situation from, say, Firefox.


 It can't be the goal to win new users with a »bleeding-edge new desktop
 experience« and, on the other hand, to ignore the other ones which want
 to keep the well-known desktop principles (kernel, X11, WM, DE) which
 allows them to put their own desktop experience together, if they like
 it (!).


I can't speak for the Shell team (my impression is that they are merely
interested in a great user experience) but the Marketing Team is focusing
entirely on current users for the 3.0 marketing push. We are not looking for
new users with 3.0--if they come it will be as a side effect of this effort
on current users. Specifically, marketing assets will focus on how your user
experience is better in GNOME 3 versus prior releases, especially with
regard to long-standing and now resolved warts on the GNOME 2.x user
interface.


 And, we shouldn't speak about »selling« GNOME. We don't sell it,
 we provide it. That's an important difference. If we would sell it, we
 had to concentrate our efforts to ship new hardware with an OS with very
 nice and exiting features. But because we provide it, we must recognize
 more than these users and their moneybags.


Yes, we know this and it's was an unintended implication of the car
analogy. We don't think of GNOME as a product; it is an upstream project
that is ultimately made available through distributions.


 As I already wrote, one of
 the most important advantages of GNOME is its modularity, which doesn't
 preclude integrity.


But modularity is not implicitly integrity.


 A desktop as strong bolted as Windows or MacOS which
 forces people to use this and not that is misplaced.


I think we are saying that Shell will be a better user experience because we
were able to much more rapidly develop GNOME Shell and that's partially
*because* the window manager cannot be switched with another. I just want to
make it abundantly clear: that is all that has changed. No other component
in the existing GNOME stack has lost its modularity.


 BTW, all these thoughts are from a user's point of view. I'm not a
 developer, just a translator, and I have subscribed to this list
 actually by accidence. But it is very interesting to see how decisions
 for the future are seem to made, ignoring a considerable number of
 long-standing users. It is more than a handful, be sure.


No one is ignoring anyone. We are listening.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-panel gnome-applets?

[Jason D. Clinton]

On Fri, Dec 31, 2010 at 03:28, Dave Neary dne...@gnome.org wrote:

 You may be aware that there was a recent initiative (from the marketing
 team, I think) to contact the release managers for various GNOME based


I'm not sure who it might have been because this is the first I've heard of
any thing like that but I can say with 98% certainty that it was not the
Marketing Team. We are fully and exclusively on-focus for marketing the
GNOME 3 release to our existing users and have been since October 2009.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-panel gnome-applets?

[Jason D. Clinton]

On Thu, Dec 23, 2010 at 12:54, Carlos Garcia Campos carlo...@gnome.orgwrote:

 I disagree. If I run gnome-session with the classic mode I expect to
 see exactly what I have right now, with all the applets. The
 definition of essential applet is probably different for every user.


I am not a designer but I've been paying attention to this process for about
1.5 years now so I think I can address your concerns.

We are on the path of ending the insanity of behavior customization with
GNOME 3 (though all are welcome to help with the maintenance of the
gnome-applets module, of course.) Obviously, personalization is staying
(wallpaper, themes, cursors, sounds, preferences). In GNOME 3, the objective
is create a desktop that actually works out of the box; one that doesn't
require that you help your family members fiddle with a bunch of settings
before it's a tolerable experience. (For example, the very first thing I
kill is the workspace switcher and show desktop applets because no family
member can comprehend looking at them to figure out where all their windows
just went after they accidentally click them. In Shell these are replaced
with the same features but in a way which has an actual usable UI.)

This means stopping the abuse of applets which in some cases are stand-ins
for something that should be a desktop widget (Finance and Deskbar, for
example)[1] and in other cases are horrible hacks that try to fix bad
design elsewhere in the OS (battery charge applet predates g-p-m, for
example). Others are just a pointless toys which are maintenance burden. In
most cases the outcome will be that some combination of the legacy
notification area icons and essential applets will provide access to
hardware-related and session-related functions in the order and locations
they located in the Shell design. Clearly, network, keyboard, power, a11y,
sound, bluetooth, system, applications and clock are staying. Probably
launchers. Places is a long-term unknown. There are going to be others; the
list is still a work in-progress.


 GNOME 2 fallback experience should be gnome-panel, metacity and
 gnome-applets.


It's a fallback but it's also going in to long-term maintenance mode which
means we need to have a coherent experience between the compatible and
Shell desktop environments. And they need to continue to adapt to API
changes. Try to imagine the next major vertical hardware integration to come
along, say, for example, that we get a desktop-wide, WiFi supported,
geolocation API with privacy guards. Now we have to write a geolocation
indicator and UI for both shells. (Just speculating.)

We're planning for the future here and for one in which everyone has a good
experience without having to muck around.

[1] There are no shortage of projects which try to do exactly this. See
Docky, Avant, Google Desktop, etc.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Boston Summit laptop charger found

[Jason D. Clinton]

Someone left their charger for their laptop in the MIT Media Lab space. We
discovered it as we were cleaning up for the day and so it could have been
left behind at any point.

I have it and would gladly ship it to whomever is missing it. Just contact
me off-list and describe it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Modulesets Reorganization

[Jason D. Clinton]

On Wed, Jun 2, 2010 at 11:00 AM, Shaun McCance sha...@gnome.org wrote:

 If we're to allow external hosting for blessed applications
 (to whatever extent we're blessing applications), these rules
 would go a long way towards helping bridge the gap. But the
 gap will still be there.

 It's just more stuff to think about for contributors, and for
 non-git hosting services, it's another VCS to learn. There's
 a lot of stuff I have to teach new documentation contributors,
 and adding another VCS to the mix doesn't help.


I think there's a misunderstanding that applications would be blessed at
all. The way this change was proposed in the GNOME Boston Summit 2009 and
the way the announcement reads, applications are merely awesome to the point
of having a sufficient level of community mind-share, like in other free
software communities, or they are hosted on our infrastructure (which is
really easy to have happen now) and easier to contribute to because of that.
Remember, any reasonably GNOME-related is welcome to be hosted on our
infrastructure.

From the Marketing Team's perspective, we will mention and showcase apps
which have that high level of community mind-share. That basically means
everything that's currently in the Desktop suite plus a whole lot more.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Modulesets Reorganization

[Jason D. Clinton]

On Tue, Jun 1, 2010 at 7:37 PM, Lucas Rocha luc...@gnome.org wrote:

 Extra Information
 -

 We're planning to do the actual reorganization of the modulesets as soon as
 possible during this development cycle. The idea is that GNOME 3 is
 released
 using the new modulesets.

 The long term plan for the GNOME applications that were removed from the
 Desktop, Admin and Dev Tools modulesets is to simply highlight the
 high-quality
 applications using the GNOME platform through our communication channels
 (release notes, website, etc). There will be no official apps anymore and
 no
 'Applications' moduleset in the GNOME releases. The goal here is be more
 open
 with the app developer community around GNOME and to highlight all the nice
 things that can be created using our platform.


I want to say that I am really happy about this proposal! As co-maintainer
of GNOME Games, I have had to constantly turn down people whom want their
game included in the distribution only to obtain the recognition that would
come with that inclusion. Some of the games that have been proposed have
been of a really high quality but, for example, didn't fit the language
knowledge of the current maintainers.

By downgrading GNOME Games to the same level as all those others that have
been proposed, distributions will be encouraged to find other alternative
games from the wider GNOME community. That would be a good thing!

Others have expressed worry about translations and documentation. I'm not
worried about that GNOME Games has the history and mind-share to ensure that
people working on our infrastructure make a habit out of working on the
GNOME Games, regardless of its status.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Modulesets Reorganization

[Jason D. Clinton]

On Wed, Jun 2, 2010 at 6:42 AM, Luca Ferretti lferr...@gnome.org wrote:

 Il giorno mer, 02/06/2010 alle 18.14 +0800, Paul Cutler ha scritto:

  To market these apps effectively, they will need to adhere to GNOME
  guidelines and processes.  They'll need to be free software, they'll
  need to be localized, they'll need documentation, they'll need to be
  accessible.  Then, and only then, should we be marketing to them on
  places like GNOME.org.

 Who will be in charge to choose those applications?

 I suppose we'll still need to propose them on some mailing list and ask
 comments from community and groups.


I didn't see anyone else respond to this so I wanted to chime in as a member
of the Marketing Committee.

We are all active members of the GNOME Community and we know which apps are
popular and are included by default in different distributions. We all use
different distributions which choose different defaults; each distribution
was well-represented by members of the Committee at the Zaragoza hackfest a
few weeks ago.

In short, the Marketing Committee is well-positioned to understand which
apps to highlight in release notes, videos and brocures, for example.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: GNOME Shell

[Jason D. Clinton]

On Sat, Apr 3, 2010 at 11:05 AM, j...@jsschmid.de wrote:

  I think it is better to say: GNOME 2 will still be available after
  GNOME 3 is released.  Perhaps in long term stable maintenance mode.
 
 
 http://live.gnome.org/GnomeShell/FAQ#What_led_to_the_decision_to_make_3D_acceleration_a_requirement_for_GNOME_Shell.3F

 I think this reduces GNOME 3.0 to gnome-shell which is not entirely right.
 Actually GNOME 3.0 is a API/ABI-broken release which includes some new
 interface elements if you have hardware support but also lots of other
 stuff (zeitgeist comes into my mind, mallard help, dropped Bonobo, etc.)


Actually, the Marketing Team is going to be spending all of our resources on
marketing to current users of 2.x and what we have found so far with our
research in to the matter is that the 3.0 experience is going to be almost
entirely revolving around the Shell. So, I think it is accurate to
characterize 3.0 as Shell. It's a simpler message and quite true.
Zeitgeist/GNOME Activity Journal appears to be at high-risk at the moment.
And, we aren't spending any effort on developers in the marketing for 3.0 so
the other things you listed aren't of much importance with regard to he
marketing message.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Freeze break request

[Jason D. Clinton]

Permission to add missing .js files to POTFILES.in?
https://bugzilla.gnome.org/show_bug.cgi?id=613092
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Freeze break request

[Jason D. Clinton]

We are in hard code freeze. I included i18n only as an informative measure.

On Mon, Mar 22, 2010 at 2:43 PM, Gabor Kelemen kelem...@gnome.hu wrote:

 Jason D. Clinton írta:

  Permission to add missing .js files to POTFILES.in?
 https://bugzilla.gnome.org/show_bug.cgi?id=613092



 This does not count as a break, as these files are already there. Just go
 ahead and commit.

 Regards
 Gabor Kelemen



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: bumping clutter's external dependencies for 2.30

[Jason D. Clinton]

On Fri, Mar 19, 2010 at 5:54 AM, Emmanuele Bassi eba...@gmail.com wrote:

 yep, the main reason for asking to bump from clutter-gtk 0.10.2 to
 0.10.4 is because of the fixes that went into making clutter-gtk compile
 against the version of gtk+ that's going to ship with Gnome 2.30. this
 brings clutter-1.2 along because of the changes in dealing with input
 device state which affect embedding a stage into another toolkit like
 gtk+.

 the proposed bumps for 2.30 are:

  clutter = 1.2.0
  clutter-gtk = 0.10.4


After a little more testing, it seems fine to bump, so if the release team
wants to bump, that would be fine with me.



 the artifacts might be due to the new sub-region update code, or if
 aisleriot is reading back texture data from cogl; we have two fixes
 already in the pipeline for that that will be backported to clutter-1.2
 today.


No luck on those commits. But it doesn't matter because the Clutter backend
is still not the default.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: bumping clutter's external dependencies for 2.30

[Jason D. Clinton]

On Thu, Mar 18, 2010 at 4:10 PM, Emmanuele Bassi eba...@gmail.com wrote:

 gnome-games depends on a recent version of clutter-gtk 0.10, which in
 turn depends on:

  • clutter = 1.2.0
  • gtk+ = 2.19.5

 can I bump the minimum and recommended versions for clutter and
 clutter-gtk on the wiki?


I was not aware that clutter-gtk had bumped its internal requirements. I saw
that Christian Persch had decided to bump us up to Clutter 1.2 and then
backed away from it but his work is regarding Aisleriot which he still
doesn't recommend distributions use in its Clutter form.

As of right now, master builds and works against Clutter 1.0.8 and
Clutter-GTK 0.10.2 so we can leave it there. Honestly, I haven't spent any
time verifying if it works well with Clutter 1.2 since some API has changed;
I just haven't had the time.

If there's some reason to bump that I don't know about, then we can, of
course, but everything will need to be checked and I don't have time for
that until this weekend.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: bumping clutter's external dependencies for 2.30

[Jason D. Clinton]

On Thu, Mar 18, 2010 at 6:51 PM, Jason D. Clinton m...@jasonclinton.comwrote:

 If there's some reason to bump that I don't know about, then we can, of
 course, but everything will need to be checked and I don't have time for
 that until this weekend.


I briefly compiled clutter-1.2 HEAD and clutter-gtk-0.10 HEAD and tried
everything. Aisleriot has some new rendering artifacts but other than that,
I'm cautiously optimistic that it would be safe to bump the dependency. It
appears to be needed anyway since older clutter-gtk-0.10 doesn't compile
against GTK+ 2.19.ish. (Two cherry picks were enough to fix it.)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GtkNotebook scrolling usability

[Jason D. Clinton]

On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org wrote:

  He
 suggested that maybe there's a use for it in the case that you have a
 ton of notebook tabs open, but I'm not quite convinced.  Just wanted to
 post on the lists and see if people have thoughts on this, otherwise I'm
 probably going to file a patch to either rip the feature out or at the
 very least make it so we can disable it. :)


I don't recall where but I'm fairly sure I saw someone using that to flip
through open tabs in Epiphany.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module semi-proposal: gnome-shell

[Jason D. Clinton]

On Wed, Nov 4, 2009 at 12:22 PM, Jamie McCracken 
jamie.mccr...@googlemail.com wrote:

 JS, whilst a good glue language, is nevertheless problematic in this it
 appears impotent (no native dbus support nor subclassing). I would only
 recommend it for scripting that does not need dbus. Currently a lot of
 code needs to be written in C to make up for these shortfalls in
 Gnome-Shell so I dont think its a particular good choice. I dont however
 see it as a blocker to gnome-shell acceptance


Regarding DBUS, there was a session about that and I blogged about it[1].
DBUS bindings will move in to in Glib/GIO, and by extension, br accessible
via GObject Introspection, and thus any language--including JavaScript--will
have first-class DBUS support for free. So the language is
completely orthogonal to DBUS this-or-that. But we're straying from the
point of this thread.

I would much rather see a discussion about the experience we would like our
users to have when GNOME 3.0 comes out and how Shell will get us there.

[1] http://jasondclinton.livejournal.com/76020.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application names

[Jason D. Clinton]

On Sun, Nov 1, 2009 at 1:35 PM, Matthias Clasen
matthias.cla...@gmail.comwrote:

  - Add X-FullName, with what was in Name
  - Set Name to the application name only

 http://live.gnome.org/GnomeGoals/CorrectDesktopFiles


To be clear, you say to use X-FullName and the linked doc says to use
X-GNOME-FullName; which is the correct way?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: dconf

[Jason D. Clinton]

2009/10/16 Josselin Mouette j...@debian.org

 Therefore a possible, sane transition plan looks like the following.
 1. A new, source-compatible (if possible binary-compatible, but
that’s less critical) GConf library is written on top of
GSettings. All applications using GConf start using it
together.
 2. A migration tool is written to convert GConf data to dconf
data.
 3. This tool is used by distributors to make GConf schemas and
system defaults available to dconf. (How it is done completely
depends on the distribution.)
 4. The tool is launched once by gnome-session.
 5. An interface is provided so that an application can be ported
from GConf to GSettings while still seeing the old data. To
achieve that, either the data is not moved at all, or the API
can specify an “old” location in GConf format as well as a “new”
location in GSettings format.


I like this proposal but, going back to the new module proposal for 2.30,
could way say that dconf is in for 2.30 but that the above five points are
not implemented until 2.32 to allow for a smooth transition and plenty of
testing? That is, dconf and gconf would co-exist for 2.30.x, only.

I don't see any value in trying to rush everything all at once for 2.30. If
we can give app. developers plenty of time with dconf available but not
mandatory, that would be preferable.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: ChangeLog generation and git

[Jason D. Clinton]

On Thu, Oct 1, 2009 at 2:31 PM, John Stowers
john.stowers.li...@gmail.comwrote:

 I am converting my projects to auto-generate ChangeLog at dist time.
 Looking at various GNOME modules, I cannot see a consensus on the
 correct way to do this. Some projects simply do

 $git log  ChangeLog

 while other use custom scripts [1]. Is there recommended way to do this?
 Could some module maintainers please point me at the method they are
 most proud of?


I prefer the direct method but omitting all entries prior to the change of
ChangeLog policy. We changed last year when we were still using SVN so the
date is a little older than others would use:

# Build ChangeLog from git log
ChangeLog:
$(AM_V_GEN) if test -f $(top_srcdir)/.git/HEAD; then \
git log --stat --no-color --since=2008-06-21  $@; \
fi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Request for removing clutter in current form

[Jason D. Clinton]

On Tue, Sep 8, 2009 at 10:36 AM, Jud Craft craft...@gmail.com wrote:

 Don't forget that the composited desktop itself on Linux still has
 some inherent flaws.

 Like that whole video garbage thing, that still shows glitches in
 OpenOffice even on Fedora 11 on an Intel 965, and leaves KDE out in
 the cold.
 https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/254468
 http://bugs.kde.org/show_bug.cgi?id=170462


This has been fixed for quite some time including on KDE so out in the
cold would be false hyperbole.


Or that you run into problems on some intel cards with 3D composited
 desktops and multimonitor setups.  (Due to the 2048x2048 problem).  Or
 glitches in TV output.


I believe that Owen Taylor, the lead developer of GNOME Shell, is doing his
development on an older Intel card with exactly this texture size limitation
without any issues.



 Or that UXA is still undergoing stabilization.


UXA has been considered stable since at least Intel 2.5.0. There have been
three point releases since then. There have been other issues but 2.8.0 is
rock-solid.


There are many potential hurdles besides mere drivers with a
 composited desktop on Linux.


What are they? Drivers and LTSP are the only two that have been raised and
both have been addressed in previous discussions on d-d-l.



 I will enjoy trying the composited GNOME Shell myself.  But I'm
 expecting the first real release that hits users (in Ubuntu and
 Fedora) to have all the polish of a KDE 4.0.x.  There's no way the
 myriad plethora of subtle Linux bugs in desktop composition can be
 fixed in time.

 As an aside, can accelerated Clutter UI still work outside of a
 composited X server?


Yes, Gnometris in GNOME Games 2.27.92 and libchamplain (contacts on a map)
in Empathy 2.27.92, both of which use a Clutter UI, work just fine outside
of a compositor. GNOME Shell+mutter *is* a compositor, though.

I am curious where you got all your mis-information. If you could, could you
pass along these answers to wherever it is that you heard all of this
incorrect information? Doing so will help us nip some of this hysteria in
the bud.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Request for removing clutter in current form

[Jason D. Clinton]

On Sun, Aug 16, 2009 at 5:55 PM, Emmanuele Bassi eba...@gmail.com wrote:

  When I tried new clutter-based gnometris I haven't see it running at
  all. The main portion of screen was the previous background. While I
  understend that it is not a gnome bug it shows that OpenGL is not
  perfect even on 'geeks' desktop.


http://bugzilla.gnome.org/show_bug.cgi?id=592139

You were seeing what you were seeing because I haven't been able to get
around to implementing a full update to the API usage. When clutter 0.9.2
was out--the last time I tracked the API--it was permitted to clone actors
that were not realized: a poor-man's texture cache. So, I'm having to
implement my own texture cache (copied from Aisleriot) and make the needed
API changes. It's a lot of code.

So that visual cacophony is not your drivers; it's our code.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson calum.ben...@sun.com wrote:

 So if it turns out that the GNOME community like the general direction
 we've suggested for the control center, then sure, I'd certainly like to see
 us widen out the discussion to visual panels as well.


Has there been any movement with regard to the mouse-over pop-up menu
criticism that I pointed out--that it breaks the metaphor and there's no
precedent for it? There wasn't any response on the blog post[1] from the
parties involved with creating the mock-up. Another criticism--not mine--was
the 90 degree rotated text for category naming. I didn't see a response to
that either. Communication needs to be two-way.

[1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Fri, Jul 24, 2009 at 12:52 PM, William Jon McCann 
william.jon.mcc...@gmail.com wrote:

 Hey Jason,

 On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clintonm...@jasonclinton.com
 wrote:
  On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson calum.ben...@sun.com
 wrote:
 
  So if it turns out that the GNOME community like the general direction
  we've suggested for the control center, then sure, I'd certainly like to
 see
  us widen out the discussion to visual panels as well.
 
  Has there been any movement with regard to the mouse-over pop-up menu
  criticism that I pointed out--that it breaks the metaphor and there's no
  precedent for it? There wasn't any response on the blog post[1] from the
  parties involved with creating the mock-up. Another criticism--not
 mine--was
  the 90 degree rotated text for category naming. I didn't see a response
 to
  that either. Communication needs to be two-way.
 
  [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/

 This is pretty far off topic.  I think discussing a control center
 design is really important.  But it should probably happen here:
 http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html


I am not on gnome-cc and have no desire to be. I didn't bring this topic up
and I think it's entirely relevant since Sun is essentially saying here that
they are offering up some two-way cooperation--the topic of the thread.
Those criticisms need to be addressed--even if it's just saying there's a
good counterargument that will be coming at some later point--if they aren't
going to replied to in the location in which critiques were solicited.

On another note, there are now just as many emails in my GMail view of this
conversation about the thread as there are of the thread itself (many of
them are off-list seething hate mail from current and former Sun and Red Hat
employees). By my count, there would be a 36% less noise in this thread if
people would stop appointing themselves d-d-l police. Incidentally, this is
the same reason that #gnome-hackers is now practically dead--everyone is so
afraid of offending un-written, ambiguous rules of content on #gnome-hackers
(apparently enforced at a whim vis-a-vis the ban of Rupert) that no one
talks at all.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On flames (Was: GNOME and non-linux platforms)

[Jason D. Clinton]

On Fri, Jul 24, 2009 at 5:15 PM, Alberto Ruiz ar...@gnome.org wrote:

  them are off-list seething hate mail from current and former Sun and Red
 Hat

 Jason, it is not acceptable to point to RH and Sun people over here,


*off-list*
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Thu, Jul 23, 2009 at 2:36 AM, Matej Cepl mc...@redhat.com wrote:

 I think the pointlessness (isn't it a beautiful word? :)) of flaming Sun
 is that the argument was not just about Solaris. Platform independence is
 a good thing for other platforms (*BSD/Mac?/Windows?) in itself.


I agree with you with one small distinction: OpenSolaris and *BSD need a
whole other level of platform independence that OSX and Win32 do not. One
doesn't need a panel/shell/nautilus on OSX and Win32 (from here on in,
application target platforms). Our application target platforms don't need
DeviceKit, PulseAudio or a sound mixer applet with a abstracted mixer
backend. They don't need gnome-settings-daemon running to handle triggering
screen saver or DPMS events. Or to toggle backlights with a
gnome-power-manager. We cover 99.9% of computer users' platforms on the face
of the earth by expending our limited resources on Linux, OSX and Win32 (and
increasingly mobile Linux via G* stack). And we don't sacrifice our free
software principals in the process.

In the (unimportant) module that I maintain, for example, there are #ifdef's
all over the code for Win32 support and I'm happy to accept patches for it.
However, we are in the process of pursuing the re-thinking of some core cool
features and other platforms have likely suffered as a result. There would
be no Clutter port of five games in the module if we had pursued the
strategy of installing seven VM's and testing all our changes on all of
them. It would be years yet, before they were available. No GSoC student
would have the time to do the seven VM's strategy and still achieve their
summer coding goals. There would be no telepathy tubes multiplayer support
on the way. We just don't have those kinds of resources.

David Zeuthen's eloquent explanation of the don't preclude portability but
leave the back-end work up to those who want it philosophy is spot-on. On
the other hand, two free software platforms do need this major extra effort
on the part of everyone who maintains a GNOME module: OpenSolaris and *BSD
(here on in, desktop target platforms). These platforms want all of the
things mentioned above. Unfortunately, from the perspective of hands to do
the actual work, the fact of the mater is that neither of the two platforms
have a lot of users.

On the *BSD side of things, the desktop-related driver situation is
lamentable. However, *BSD has a huge thing going for it: vast parts of the
user space are nearly identical to Linux. So with exception given to the
absence of udev, it really isn't all that different. Indeed, there is even a
semi-official *BSD kernel for Debian.

OpenSolaris, however, suffers from a legacy of esoterically cathedral-like
design on some fundamental sub-systems. The work to make all the things
mentioned above work is so, so much more than any other platform for GNOME.

I'm fairly confident in saying that Win32--if it isn't already working in
2.27.x--would be a trivial amount of additional effort for GNOME Games. And
while OSX still looks quite ugly and *BSD lacks good 3D drivers, they too
would continue to be a somewhat minimal amount of effort. As for
OpenSolaris, who knows. I have examined the packaging of GNOME Games in
OpenSolaris in the past and was not encouraged by what I saw.

And I don't even maintain a module that really cares all that much about the
underlying plumbing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 1:45 PM, Lennart Poettering mzta...@0pointer.dewrote:


 Please don't turn this in pointless and off-topic flamewar about the
 point or pointlessness of Solaris.


Obviously the alleged pointlessness of something that we are arguing about
is relevant. Whether or not there are--you know--actual people using said OS
is what this is really about. And apparently even Sun doesn't think so since
they no longer invest the same level of resources in it that they once did.
I'm calling a duck a duck here. It's a failure and even Sun knows that it
is. There's no reason we shouldn't be scrambling a few eggs on Solaris to
advance the Linux desktop experience.

I know you're a veteran of the flame-war (goodness knows you've gotten a lot
of practice in the past two years) but don't immediately try to shoot me
down with accusations of triviality. Back off.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 3:29 PM, Alberto Ruiz ar...@gnome.org wrote:

 +1 for Lennart here,


What exactly does *your* email add to this discussion?



 you don't even know what you are talking about


That's a terribly arrogant statement.



 and the comment is not helping to solve any problem.


What's the problem again? There isn't one. That's the point.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Jason D. Clinton]

On Wed, Jul 22, 2009 at 3:55 PM, Karl Lattimer k...@qdh.org.uk wrote:

 That's not arrogant, arrogant would be someone making a sweeping
 statement like nobody uses solaris so lets just not care about it, when
 no evidence is provided to back that up.


Are you really going to make the argument that Solaris does have a
non-trivial desktop install user base? What exactly are you getting at? Or
you decided you'd like to add flames?

If I'm going to give you the benefit of the doubt that you are not giving me
(I know quite a lot about Sun, by the way), then my suggestion to you--if
you are serious about pursuing this line of reasoning--would be to Google
some Solaris browser statistics.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Officially turn DropLibsexy into a GNOME Goal

[Jason D. Clinton]

On Thu, Jun 11, 2009 at 1:02 PM, Luis Medinas lmedi...@gnome.org wrote:

 On Thu, Jun 11, 2009 at 5:29 PM, Javijavierjc1...@gmail.com wrote:
  I've sent a mail to the gtk-devel list [3] about consolidate libsexy
  library in GTK+ in the
  context of the project Ridley [4] and seems that they agree.
 
  For that reason, I'd like to propose turn DropLibsexy [1] into a
  official GNOME Goal [2].
  (Further, almost all the work is done :))
 
  Any suggestion/objection?
 
  If you agree, I can update the GnomeGoal page with the new changes.
 
 +1 for me, i already helped with a patch and there isn't many modules
 using libsexy. So this should be a goal for 2.28.


How 'bout 2.30 after the GTK+ release incorporating these changes is fully
released and widely available?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Module Proposal. libseed

[Jason D. Clinton]

On Mon, May 11, 2009 at 9:59 PM, Robert Carr ca...@rpi.edu wrote:
 So far, Seed adoption is still somewhat light. Epiphany-webkit in GIT
 contains a system for writing
 extensions in Seed, which seems to be working fairly well. In addition
 GNOME-games contains
 lightsoff, a Clutter game written in Seed. Same GNOME is also likely
 to be replaced with
 something based off the same-seed example, over the 2.6.28 cycle (work
 on GNOME-games and
 Seed is occurring as part of
 http://socghop.appspot.com/student_project/show/google/gsoc2009/gnome/t124022402774
 ).

+1 from me. Robert has been very responsive and his team of minions
have made changes whenever I've asked.

I think we must have both engines. The JS optimization battle between
Mozilla and Apple is just now heating up; we cannot wait until the
battle is over to pick a winner and start working with JavaScript.

Having JS with which we can:

A) attract web developers to our platform with little relearning
B) interface with myriad JS-driven web-apps-to-desktop-apps; think
Mozilla Prism, Adobe AIR, HTML5, Google Gears

is critical to our ability to adapt to the web-oriented marketplace.

In summary: we need both engines and we need them in our platform
sooner rather than later.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Module Proposal. libseed

[Jason D. Clinton]

On Wed, May 13, 2009 at 10:23 AM, Alberto Ruiz ar...@gnome.org wrote:
 2009/5/13 Jason D. Clinton m...@jasonclinton.com:
 I think we must have both engines. The JS optimization battle between
 Mozilla and Apple is just now heating up; we cannot wait until the
 battle is over to pick a winner and start working with JavaScript.

 That sounds to me more of a counter argument, is the GNOME official
 desktop release the right place for a JavaScript engine battle? Isn't
 the performance of both already good enough for our purposes? It seems
 to me that they both already perform better than Python and we've been
 supporting it for ages already.

As has already been stated elsewhere, (with exception to the 'let'
statement) they should be runtime compatible. The battle will happen
regardless of what GNOME does.


 It also seems to me that JSC/Seed is being adopted in much more
 modules than GJS (please, correct me here if I'm wrong), plus there
 are quite a few modules going for WebKit. I think that having one, and
 only one choice for things like this (platform), are quite helpful in
 order to have a more consistent platform.

In this case, it would help in the sense of having more eyes
focusing on one JS implementation--I agree. OTOH, if we are willing to
forgo that benefit in favour of hedging our bets in the battle for the
fastest, most featureful JS virtual machine, we gain a heterogeneous
JS platform that's robust enough to withstand the growing pains.


 Note taht Javascript can be a potential entry vector for the GNOME
 platform (which is one of the most interesting points of getting a JS
 engine in), I think people will have a hard time to make a decision
 they might not fully understand (the engince choice), and
 documentation will get messier. Not to mention that we will end up
 with one extra dependency.

Hopefully everyone can agree on some solution WRT to let and then we
don't have to care which one they develop with: their work will run on
both.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Module Proposal. libseed

[Jason D. Clinton]

On Wed, May 13, 2009 at 11:07 AM, Murray Cumming murr...@murrayc.com wrote:
 Quite apart from choosing which 1 of 2 candidate engines we should
 choose, something seems very wrong if we have to maintain a runtime
 engine for a programming language that we want to use. It's not
 something we do for any other programming languages.

We're not discussing the addition of a module containing an engine.
We're discussing a module containing bindings to an engine.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Module Proposal. libseed

[Jason D. Clinton]

On Wed, May 13, 2009 at 11:09 AM, Xan Lopez x...@gnome.org wrote:
 I just want to point out that if the gnome-shell developers have any
 intention or desire of using Seed in the future this whole we need
 both engines debate is a bit pointless, since in theory there
 wouldn't be any module using gjs in GNOME, and thus moving forward
 with Seed would be the only sane choice IMHO. So I think their input
 would be quite valuable here.

I was a fly-on-the-wall to such a discussion between Robert and Owen
some months ago and it seemed then that mostly everyone working on G-S
didn't much have any opinion on the matter except for Havoc
Pennington. If I recall correctly, whatever he is doing at his
start-up depends on the features of JS 1.6/1.7 which can only
currently be exposed in GJS.

I have CC'd him. Perhaps he can elaborate.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposing libgdata as a new desktop module

[Jason D. Clinton]

On Thu, May 7, 2009 at 1:27 AM, Philip Withnall phi...@tecnocode.co.uk wrote:
 I would like to propose libgdata as a new desktop module for GNOME 2.28.

Awesome! +1
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-games requires clutter 0.9.x

[Jason D. Clinton]

On Tue, May 5, 2009 at 7:37 AM, Frederic Peters fpet...@gnome.org wrote:
 Emmanuele Bassi wrote:

  Hrm, then what's the point of the development tarballs? :-)

 providing snapshots, just like glib and gtk+ :-)

 but the API might change during the development cycle, so you should be
 aware of that. as far as I know, jhbuild does not build glib and gtk+
 from tarballs either.

 Clutter is an external dependency, while glib and gtk+ are part of the
 platform.  Policy (and experience) tells to build external dependencies
 from released tarballs.

It seems that we're well on our way to making Clutter part of our
platform so this formal distinction seems relatively meaningless at
this point.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-games requires clutter 0.9.x

[Jason D. Clinton]

On Tue, May 5, 2009 at 11:01 AM, Andre Klapper ak...@gmx.net wrote:
 It's not only a formal distinction.
 Such policies do not exist just because people are bored.
 It's based on bad experiences in the past.

Why are we having this argument? Is release team going to veto Clutter for 2.28?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-games requires clutter 0.9.x

[Jason D. Clinton]

On Mon, May 4, 2009 at 12:43 PM, Brian Cameron brian.came...@sun.com wrote:
 clutter-gtk 0.9 is not yet available.  Yet gnome-shell requires
 clutter-gtk 0.9 to build, so you currently have to build it from git
 master.

 Might it be better to wait until clutter-gtk 0.9 is released before
 jumping to the new version in jhbuild?

2.27 doesn't build with 0.8.x; the API has changed.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-games requires clutter 0.9.x

[Jason D. Clinton]

On Sun, May 3, 2009 at 2:39 PM, Kjartan Maraas kmar...@broadpark.no wrote:
 gnome-games stopped building in jhbuild for me since we still have
 clutter-0.8.8 there and the games want to use 0.9.x from what I can see
 in the logs.

The request was made Mar. 17th with no objections. So, it's mandatory now.

 Time to move forward for everyone? Anyone else using clutter and thus
 need to port to the new version first?

It's up to whoever is using it. 0.8 and 1.0 are co-installable.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On autogenerated ChangeLog

[Jason D. Clinton]

On Tue, Apr 21, 2009 at 3:32 PM, Tristan Van Berkom t...@gnome.org wrote:
 Sure,
   on the other hand projects with ChangeLogs that are hand-tended
 to are, in my personal experience richer than logs of arbitrary commits,
 if only by the simple virtue of forcing you to spend time caring for it.

 Anyway, lets see what some experiments yield ;-)

Anyone submitting patches to our module without a proper commit log
message will likely have their patch gently rejected until it's fixed.
That certainly is the case with the vast majority of FOSS projects out
there using git. See git format-patch.

Likewise, at some point, translators making a commit log message that
reads Updated a file. will have their commit reverted with an
explanation in the commit log as to why it was reverted.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: eggsmclient code syncing

[Jason D. Clinton]

On Wed, Apr 8, 2009 at 1:38 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 good idea to sync the eggsmclient code in the modules that use it for
 2.26.1, which seems to be at least the following:
...
 gnome-games

Done on master and gnome-2-26
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Jason D. Clinton]

On Mon, Apr 6, 2009 at 11:37 AM, Alberto Ruiz ar...@gnome.org wrote:
 You are missing the remote desktop scenario here. This is not only a
 matter of working on old hardware, being able to run gnome smoothly on
 a thin client solution through XDM, or VNC, or whatever is also
 needed.

VNC is not an issue--it works regardless of the compositor/WM running.
Speaking as a former LTSP admin/slave/developer, remote X11 is
*always* a non-starter regardless of whether we are talking about 3D
or not. More doesn't work than does. An approach similar to what Dave
Richards is using at City of Largo is actually the right way to do
this: the compositor and a few video-intensive apps run locally on the
hardware. There's no technical reason that Shell couldn't do the same
thing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Games will make 3D mandatory for 2.28

[Jason D. Clinton]

On Tue, Mar 24, 2009 at 10:58 AM, Olav Vitters o...@bkor.dhs.org wrote:
 On Mon, Mar 23, 2009 at 06:21:48PM -0500, Jason D. Clinton wrote:
 This is not a proposal or RFC. This is what is happening; I am merely
 make it abundantly clear well in advance of it being released to the
 general public.

 Games which will require 3D for 2.28:
  * Gnometris
  * Lights Off (pending approval of Seed/GJS dependency during proposal 
 period)
  * Same Gnome (pending approval of Seed/GJS dependency during proposal 
 period)

 So I assume release team should announce some dependencies earlier if it
 appears to be a no brainer?

Well, Clutter 1.0 is already in so we're good there.

Regarding the JavaScript games, it seems that everyone agrees that
JavaScript is going in to Gnome 2.28. GJS seems to have the leg-up as
the Gnome-Shell preferred engine. As for which one, Robert Carr has
plans to make Seed and GJS run-time compatible (to the extent that the
underlying engines have implemented the ECMA specs and same features)
by the time the module proposal period opens. I was planning on
leaving the proposal up to him due to the requirement that the
proposal must be made by the module maintainer. Currently, ScriptCore
(as seen in gtkwebkit 1.1, Safari 4 beta, Chrome 2 beta) is about 2x
faster than Tracemonkey (as seen in Firefox 3.1 beta) on the Sunspider
benchmarks. It seems like allowing both as dependencies is the only
way to go forward and since they should be (mostly) run-time
compatible, it shouldn't matter, really.

The only thing that worries me is Seed/GJS's both depend on the
stability of GIR/GOI. But since Owen knows more about the status of
that than I do and seems comfortable with the timeline, I do not
foresee this really being an issue.


 Whatever your opinion, remember: these are just games. Don't take this
 announcement too seriously.

 I saw you commenting (blog IIRC) about this, this is existing code right
 that is now used as the only method (scrapping of 2D)? Or totally new
 code? Assume new for Lights Off and Same Gnome. Anyway, looking forward
 to the change.

Aisleriot is the only game that we are committing to maintaining the
old 2D engine on, for now. We're strapped for resources and the
thought of doubling our maintenance burden for every game that gets an
upgraded engine is not appealing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Jason D. Clinton]

On Tue, Mar 24, 2009 at 12:33 PM, Xavier Bestel xavier.bes...@free.fr wrote:
 On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote:
 On 03/24/2009 08:47 AM, Owen Taylor wrote:
  Using Compiz to create a GNOME desktop using GNOME applications, the
  GNOME control-center, and so forth will of course remain possible. We
  have no current plans to create hard dependencies on GNOME Shell within
  the GNOME desktop (just as there are no hard dependencies on gnome-panel
  now.)

 Yeah, but I can still use gnome-panel in compiz.  I understand the
 reasoning here, and don't have any suggestions or anything, but it's a
 bit disappointing that the new desktop experience will be so tied to the
 window manager.

 Asking to leave all the compiz goodness will be a tough sell :)

There is nothing good about compiz other than as a spectacle and
general proof of concept. It has myriad application compatibility
issues and configuring it is a usability nightmare. It tried to be
desktop agnostic, so now it has four configuation backends and three
window decorators--all of which are half-baked. The community around
it very nearly died about a month ago.

I would encourage you to try gnome-shell before you lament compiz.
You'll see that already it is quite functional and there's lots of
bling for those who care about such things. And since it's based on
Metacity, all the app. compatibility bugs in compiz are gone.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Gnome Games will make 3D mandatory for 2.28

[Jason D. Clinton]

Now that 2.26 is out and we've begun to work on 2.28, I want to get
this out early so that no one feels like this was a last minute
surprise. This has been a year in the making and this development
cycle appears to be the right time to put some polish on our new game
engines and make them the default.

This is not a proposal or RFC. This is what is happening; I am merely
make it abundantly clear well in advance of it being released to the
general public.

Games which will require 3D for 2.28:
 * Gnometris
 * Lights Off (pending approval of Seed/GJS dependency during proposal period)
 * Same Gnome (pending approval of Seed/GJS dependency during proposal period)

Games which may require 3D depending on the maturity of the engine for 2.28:
 * Aisleriot
 * GSoC project results (whatever they may be)

I anticipate that two parties will be disappointed: LTSP deployments
and owners of ATI graphics cards. Taking the later first, this group
appears to be being well-addressed by Airlied's work; hopefully
everything will just work by the time 2.28 is released. As a former
LTSP admin/engineer/slave, I believe that this style of Linux terminal
server deployment is deeply flawed and well on the way to being
replaced by Live environments.

Whatever your opinion, remember: these are just games. Don't take this
announcement too seriously.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME accepted as a Google Summer o Code project

[Jason D. Clinton]

On Wed, Mar 18, 2009 at 5:00 PM, Adam Schreiber sa...@clemson.edu wrote:
 GNOME has been accepted as a GSoC project for 2009.  If you're
 interested in being a mentor and/or reviewing student applications,
 make your way to [1] and sign up.

As far as I can tell, students have to start submitting their proposal
in five days and we have not yet triaged the bug proposals. Can we do
this soon; do you need help?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dependency bump for Clutter for Gnome 2.28

[Jason D. Clinton]

On Tue, Mar 17, 2009 at 8:26 AM, Olav Vitters o...@bkor.dhs.org wrote:
 On Mon, Mar 16, 2009 at 10:54:58PM -0500, Jason D. Clinton wrote:
 Okay to bump official depends on Clutter and Clutter-GTK from the
 0.8.x API to 0.9/1.0 API? I fully expect it to stabilize and have a
 1.0 release before 2.28. Also, Clutter Cairo is now part of Clutter.

 You mean as of 2.27.x?

Yes.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Dependency bump for Clutter for Gnome 2.28

[Jason D. Clinton]

Okay to bump official depends on Clutter and Clutter-GTK from the
0.8.x API to 0.9/1.0 API? I fully expect it to stabilize and have a
1.0 release before 2.28. Also, Clutter Cairo is now part of Clutter.

Also, it's unclear from reading the archives but is libcanberra
blessed now? Planning on using it as a poor man's replacement for SDL
mixer...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module decisions for 2.26

[Jason D. Clinton]

On Wed, Jan 21, 2009 at 1:41 PM, Damien Sandras dsand...@seconix.com wrote:
 Perhaps pulseaudio developers could try ekiga before we write a
 pulseaudio plugin for it ?

Lennart's last blog post on the matter[1] indicated that we should be
using alsa--not writing pulseaudio plugins for our apps. So, it should
Just Work... This is how I have been working on a private git branch
for Gnome Games. I didn't see that ticket 23 until now. Quite scary.

[1] http://0pointer.de/blog/projects/guide-to-sound-apis-followup.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dependency bump for GGZ

[Jason D. Clinton]

On Mon, Jan 19, 2009 at 5:41 AM, Josselin Mouette j...@debian.org wrote:
 Le dimanche 18 janvier 2009 à 14:52 -0600, Jason D. Clinton a écrit :
 On Sun, Jan 18, 2009 at 1:41 PM, Jason D. Clinton m...@jasonclinton.com 
 wrote:
  Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to
  this library breaking API. It appears that no distro. (at least Debian
  and Fedora) has decided to do versioned soname for libggz so we are
  forced bump dependency to continue to be able to build in these
  distros. See bug #551455.
 
  I'll take the liberty of updating l.g.o

 As an addendum, upstream is really unhappy with the soname situation
 in both Debian and Fedora. If upstream can manage to get either of
 these to revert the change to 0.99.5 or make it a soname bump instead,
 Gnome Games will revert to 0.0.14. I'll update this list as I hear
 more.

 For the record, if the soname has not changed between the two while the
 ABI is broken, this is a clear violation of our policy so we'll have no
 trouble to get it changed.

Alright, Gnome Games is reverted to 0.0.14. Updating all the relevant
pages. Fedora will have to revert their rawhide version to continue to
build.

Bump retracted.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 2.26 module inclusion discussion heats up

[Jason D. Clinton]

On Mon, Jan 19, 2009 at 8:46 AM, Lennart Poettering mzta...@0pointer.de wrote:
 Oh, is that so?

 This is some old Topaz mockup:

 http://farm1.static.flickr.com/20/70003494_668cfdc0dd.jpg

Your attitude is making it really hard to take sides with PA. Yes,
it's *the* only way forward at the moment. But you don't need to be a
dick about it. Why are you (and your supporters) resisting a fall back
mode so strongly?

BTW, I updated the proposal pages some time ago to indicate that PA is
essentially being proposed as a dependency as a result of this thread.
What about your attitude toward hardware compatibility lends to the
argument that we *should* depend on PA at this point?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Dependency bump for GGZ

[Jason D. Clinton]

Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to
this library breaking API. It appears that no distro. (at least Debian
and Fedora) has decided to do versioned soname for libggz so we are
forced bump dependency to continue to be able to build in these
distros. See bug #551455.

I'll take the liberty of updating l.g.o
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dependency bump for GGZ

[Jason D. Clinton]

On Sun, Jan 18, 2009 at 1:41 PM, Jason D. Clinton m...@jasonclinton.com wrote:
 Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to
 this library breaking API. It appears that no distro. (at least Debian
 and Fedora) has decided to do versioned soname for libggz so we are
 forced bump dependency to continue to be able to build in these
 distros. See bug #551455.

 I'll take the liberty of updating l.g.o

As an addendum, upstream is really unhappy with the soname situation
in both Debian and Fedora. If upstream can manage to get either of
these to revert the change to 0.99.5 or make it a soname bump instead,
Gnome Games will revert to 0.0.14. I'll update this list as I hear
more.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New Module Proposal: libseed

[Jason D. Clinton]

On Mon, Jan 5, 2009 at 9:12 PM, Robert Carr ca...@rpi.edu wrote:
 I was not planning to do this until .28, however a nice Clutter game
 written in Seed was merged in to gnome-games today, and there is some
 interest in being able to include this in .26.

 I would like to propose Seed (http://live.gnome.org/Seed) as a beta -bindings 
 module for .26
 For those not following, Seed is a set of bindings between WebKit's
 JavaScriptCore interpreter, and GObject (through GObject introspection).
 Seed provides a standalone interpreter, and a library with a clean API
 for embedding Seed as a scripting language. Through GOBject-introspection
 Seed automatically provides bindings to dozens of libraries, in a
 convenient fashion where individual bindings do not have to be maintained
 (but just the core library).

+1 from me, obviously.

Even if this is approved as a blessed depends, we may not end up
turning Lightsoff on by default for 2.26 simply due to the number of
outstanding tasks; we'll just have to see where we stand when feature
freeze comes.

It seems like a good time to make this a blessed dependency so that
there's more than just Gnome Shell doing JS+GOI when/if it becomes the
default shell for 3.0.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: JavaScript engines

[Jason D. Clinton]

On Tue, Jan 6, 2009 at 11:14 AM, Johan Dahlin jo...@gnome.org wrote:
 The language is pretty different, SpiderMonkey supports quite a few
 /language/ extensions which JSCore doesn't.[1][2][3]

s/doesn't./doesn't yet./g
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: JavaScript engines

[Jason D. Clinton]

On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson al...@redhat.com wrote:
 The APIs will certainly not automatically be the same. There are lots
 and lots of little decisions you have to make when you bind gtk. If just
 one of these differ then they won't be compatible.

It's not clear to me why this would not be considered a bug.

Hopefully Robert will jump in here and say he's willing to treat GJS
as the reference implementation and then everyone can just be happy
with two implementations with the same API on which any app can Just
Work.

Let's wait for Robert to reply before we get too carried away...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 8:51 AM, Olav Vitters o...@bkor.dhs.org wrote:
 That isn't a contest. It is a survey.

Please don't read more in to my email than I intended. There's no need
to get defensive.


 http://www.gnome.org/~shaunm/survey/first-picks-permutations.png It
 seems to me that a lot of brain power, sysadmin time, and general

 I am a sysadmin and disagree with your notion that sysadmin time is
 somehow saved. I'd rather asses such things myself. Further, sysadmin
 time is not so important.

Thank you for voicing your opinion.


 just all move on?

 Further, your explanation is incomplete. As you said, the graph is about
 people knowing two DVCS systems. I wouldn't say I knew 2. Those 6 are
 incomplete.

I highlighted this statistical analysis because those 6 contain the
subset of  4 vocal users demanding that we /also/ support bzr.


 Now before you reply: we have a clear need for git to work (ranked 1st
 50% of the time, etc). But if you say move on, how do you think a
 switch is made? Magic?

Please don't be patronizing. I'm not an idiot.


 Anyway, I'd rather add John Carr to the sysadmin team. I plan to make a
 proposal to switch GNOME to a DVCS where Git works using Johns
 suggestion. Then other sysadmins[1] can suggest whatever proposal they
 want. These proposals can be investigated on merit and then a one can be
 chosen (chosen as in: go ahead and try if this would work, not go
 ahead blindly; everything must be tested before a cutover).

John's idea is a good one but it patently loses on technical merit. As
stated by John here, git will only be support in a degraded,
bastardized form because he chose bzr as the repository format:

http://blogs.gnome.org/johncarr/2008/12/11/dvcs-for-gnome/#comment-172

Are we really going to go back to the days of CVS where file moves
aren't supported?

It strikes me that this very vocal minority--John and Robert Carr,
Karl Lattimer and Rob Taylor (whom are four of the six people I
mentioned above)--are potentially delaying even longer what we've
wanted for more than two years, now. It is from these same people that
came the suggestion that git users were a rapid, vocal minority. Why
are we letting them derail this process?

Moving will not be easy, obviously. But doing it John's way will be,
in my technical analysis, an order of magnitude more painful.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 2:43 AM, Karl Lattimer k...@qdh.org.uk wrote:
 Elijah Newren did an initial analysis of the data.  His analysis also 
 includes
 the survey questions and answers.  Find it at:

   http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/


 This is pretty decent analysis going on here :)

 I'd like to remind people of John Carr's recent blog post too, someone 
 mentioned in the survey results actually. JC has been working on bzr with git 
 protocol support, which would fulfil many of the requirements for having a 
 GNOME DVCS.


I'd like to point out that--of the 15 people who regularly use git and
bzr--git still won.
http://www.gnome.org/~shaunm/survey/first-picks-permutations.png It
seems to me that a lot of brain power, sysadmin time, and general
proliferation of Things To Learn for New People(tm) can be saved if
the six people (1.04% of respondents) who ranked bzr above git in that
graph can just bite the bullet and admit that git won. Can we please
just all move on?

My fear is that this effort to keep bzr on life support will cause bzr
to show up as a requirement in distcheck for modules maintained by
people who are still holding out.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 11:48 AM, John Carr john.c...@unrouted.co.uk wrote:
 I'm not a complete idiot - if it was going to be a degraded,
 bastardized form of Git I wouldn't waste my time on it. I suppose I
 might be an evil genius stalling for Bazaar DS9 to be written (sorry
 for the very bad joke that probably only i get...).

I don't think you're an idiot. I think you're quite smart.

Can you please tell us exactly what your words, This is a price that
a maintainer pays for using Git and one reason why eventually they
might decide to (and have the option to) switch to using Bazaar, mean
and to which git features you are planning on this statement applying
to encourage people to use bzr?

Or do you mean that you taking that sentence back?

Also, can you tell us if Canonical is directing you to work on this?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 3:01 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote:
  How about we set-up a task-force of volunteers who would want to
 help in the move, each volunteer promising at least 3 hours a week? 3
 hours is a very small amount of time but I am hoping that we'll be
 able to gather at least 10 volunteers and together we can do it, even
 using our spare time.

I can commit that much time as long as there's clear delegation of
work by--preferably--the sysadmin team. I don't want to sit on a
committee that does a lot of deciding and no actual doing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 3:27 PM, Olav Vitters o...@bkor.dhs.org wrote:
 I can commit that much time as long as there's clear delegation of
 work by--preferably--the sysadmin team. I don't want to sit on a
 committee that does a lot of deciding and no actual doing.

 What do you mean with delegation?

 Which do you mean: (yes, exaggerating)
  - Hey, do the switch, hopefully it'll work out in the end?
  - Run this command, then this one, then that

More of a, Given this requirement, you find a solution to this
specific problem. Report back in a week and ask for help if you get
stuck, where solution may involve writing code in the form of
post-commit hooks.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Jason D. Clinton]

On Sun, Jan 4, 2009 at 3:47 PM, Luca Ferretti elle@libero.it wrote:
 bzr allows lightweight checkouts [1]. What about git?

Yes, it does. This is not an issue.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: update of jhbuild module dependencies

[Jason D. Clinton]

On Sat, Nov 8, 2008 at 3:06 PM, Luca Ferretti [EMAIL PROTECTED] wrote:

  * a little mess with clutter stuff: we have clutter in
gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn
trunk) and clutter-0.8 (svn branch) as well as a lot of
clutter-XXX-0.8: clutter 0.8.x is official external dep for
GNOME 2.24. Will we switch to 0.9/1.0 in 2.26? Emmanuele?


No, 0.6.x is official external for 2.24. My request bumped that to 0.8 for
2.26. 1.0's release is scheduled too close to our freezes, I think.

clutter-cairo, -gstream, -gtk, should all be set to the latest releases of
those modules. 0.8.x is API stable.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 2.25.1 Released!

[Jason D. Clinton]

Why was Gnome Games omitted from the release notes? This was the worst
possible release that could have been left out. There are more changes in
dependencies and packaging in this release than any other point in my recent
memory.

On Thu, Nov 6, 2008 at 6:02 AM, Vincent Untz [EMAIL PROTECTED] wrote:

 GNOME 2.25.1 Development Release
 

...


 desktop  - 
 http://download.gnome.org/desktop/2.25/2.25.1/NEWShttp://mail.gnome.org/mailman/listinfo/devel-announce-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new module proposal: brasero

[Jason D. Clinton]

2008/11/1 Philippe Rouquier [EMAIL PROTECTED]

  Hi,

 We'd be interested in having brasero integrated into the GNOME desktop.


+1, a wonderful application. n-c-b should be completely removed.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Dependency bump request for Clutter

[Jason D. Clinton]

0.6 was cleared for use for 2.24 but no module actually ended up using it. I
would like to request that the dependency be bumped to 0.8.2. Aisleriot now
supports Clutter thanks to the work of Neil Roberts. The gnome-games team is
committed to releasing 2.26 with some Clutter support.

For 2.26, the 0.8 series seems like the way to go. As we near release, I may
update this bump request to the 1.0 API.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Laptop power disconnect alarm

[Jason D. Clinton]

This should probably be done as a patch to gnome-power-manager.

Thinkpad laptops in particular already do something like this (it's
implemented in the BIOS) that does a chime to notify the user that the
laptop is still on when the lid is closed and the power cord is detached to
prevent people from putting their laptop in their bag and having it
overheat.


On Sun, Oct 12, 2008 at 5:26 AM, Bram Neijt [EMAIL PROTECTED] wrote:

 Dear GNOME developers,

 I have  a program idea that I would like to create and test out, but I
 have no idea whether something like this has already been created and
 what documentation to read in order to create it.

 I want an application that will sound an alarm if my laptop adapter is
 unplugged while the screen is locked. The idea is that if somebody tries
 to steal my locked laptop, disconnecting the power, it will start
 shouting I'm being stolen! (by playing a sound file).

 Because it needs both power information and screen-lock information and
 is laptop specific, I think a separate program is needed. The questions
 I have are:

 - How do I keep an eye on the power status? What interface should I
 register, dbus something??
 - How do I keep an eye on the screen-saver status, where can I register
 for locking/unlocking events?
 - Is there something like this already created, would it be scriptable
 instead of programming it out completely?

 For most of these questions, links would suffice. Any ideas are of
 course also welcome.

 Greetings,
  Bram Neijt

 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: indentation of c code

[Jason D. Clinton]

On Mon, Aug 18, 2008 at 7:22 AM, Dodji Seketeli [EMAIL PROTECTED] wrote:

 BJörn Lindqvist a écrit :

 [...]

  There is no GNOME standard for indenting C code -- every project use
 their own indentation style (unfortunately). But to reformat a file to
 an indentation style many projects use, you can just run indent
 without any arguments.


 I am sorry, but I think there is a GNOME standard for indenting C code.
 It's at
 http://developer.gnome.org/doc/guides/programming-guidelines/book1.html,
 chapter
 http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
 .

 If GNOME C projects use their own indentation style, I think it's just
 because only a few people have read that documentation or because GNOME as a
 project does not enforce it that much.

 GTK+ uses the GNU indentation style that is documented at
 http://www.gnu.org/prep/standards/standards.html.


I would love to clean up indentation in my module but I fear that it creates
useless svn blame output henceforth.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Jason D. Clinton]

On Tue, Jul 22, 2008 at 10:03 AM, David Zeuthen [EMAIL PROTECTED] wrote:

 So maybe you just haven't tried hard enough.


Fuck you.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Jason D. Clinton]

On Tue, Jul 22, 2008 at 7:02 PM, Michael Biebl [EMAIL PROTECTED] wrote:

 2008/7/22 Rob Taylor [EMAIL PROTECTED]:

 Hi Rob,

  Just as a quick note, Jason's problem is completly a debian unstable
  packaging issue, as far as I can tell.

 Care to eloborate, why and what the actual problem actually is
 (especially regarding Debian)?


/usr/share/PolicyKit/policy files in the 0.5.11 upstream distribution are
not being installed by the Debian hal package.

But as I said in the last line of my email which apparently no one has read,
after correcting for the packaging problem, it's still broken. So that's
only a tiny aspect of the issue. The issue is that there is no user
documentation at all. Not in the distribution. Not in the GUI with a Help
button. Not in stub README files. Nothing. ... Unless you're a programmer
and want to read developer documentation to get your USB hotplug working
again.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Jason D. Clinton]

On Tue, Jul 22, 2008 at 8:09 PM, Michael Biebl [EMAIL PROTECTED] wrote:

  If that's your policy, then you need to patch
 /etc/dbus-1/system.d/hal.conf
  to NOT use PolicyKit in a package that doesn't have support for it. This
  is--AFAICT--an upstream bug in hal that this stanza is not removed when
  ./configure finds that PK is not going to be enabled. Now THAT is a bug I
  could file. But, as I've said, I already corrected for that and the
 problem
  appears to be deeper.

 I'm honestly not sure what you are talking about, sorry.
 There are no PolicyKit bits in Debians hal.conf. We use the group
 based approach as we always did.


This is the PK bits that David was discussion in his previous message that
are in the Debian hal which appears to be a security problem, if nothing
else:
http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=5b4c664f7b40e85148bd3c32946388e23fe8b384

Would you like me to open the BTS bug?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Jason D. Clinton]

On Tue, Jul 22, 2008 at 8:27 PM, Jason D. Clinton [EMAIL PROTECTED]
wrote:

 This is the PK bits that David was discussion in his previous message that
 are in the Debian hal which appears to be a security problem, if nothing
 else:

 http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=5b4c664f7b40e85148bd3c32946388e23fe8b384

 Would you like me to open the BTS bug?


Never mind, I was looking at the Debian hal.conf cross-ways while examining
the one I installed as a part of my jhbuild work tracking 2.23. There's
nothing wrong with the Debian package; it correctly kills PK support as
suggested by the configure.in message that David referenced. jhbuilding
appears to be the source of PK being enabled WRT to hal.

When I have time I'll investiage why the default allow policy is having PK
returning permission denied for active sessions. It'll have to be some time
next week.

Thank you for your attention to the Debian side of things, Michael.

Here is the Debian patch, FTWCA such things:

diff --git a/hal.conf.in b/hal.conf.in
index ef97b8f..3646deb 100644
--- a/hal.conf.in
+++ b/hal.conf.in
@@ -40,6 +40,26 @@
   !-- Default policy for the exported interfaces; if PolicyKit is not used
for access control you will need to modify this --
   policy context=default
+deny
send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/
+deny send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/
+deny send_interface=org.freedesktop.Hal.Device.LaptopPanel/
+deny send_interface=org.freedesktop.Hal.Device.Volume/
+deny send_interface=org.freedesktop.Hal.Device.Volume.Crypto/
+  /policy
+
+  !-- Debian groups policies --
+  policy group=powerdev
+allow
send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/
+allow send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/
+allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/
+  /policy
+  policy group=plugdev
+allow send_interface=org.freedesktop.Hal.Device.Volume/
+allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/
+  /policy
+
+  !-- You can change this to a more suitable user, or make per-group --
+  policy user=root
 allow
send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/
 allow send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/
 allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Jason D. Clinton]

On Fri, Jun 20, 2008 at 1:47 PM, David Zeuthen [EMAIL PROTECTED] wrote:

 On Fri, 2008-06-20 at 15:57 +0200, Murray Cumming wrote:
  Going off topic a bit: It would be really nice if PolicyKit had a proper
  web page and mailing list. It's too important for information on it to
  be so fragmented.

 Right. I'm actually going to try and fix this (dedicated mailing list
 and website); stay tuned.


Hi,

I am tracking relatively unstable development repositories. As a result, I
have hal 0.5.11 installed which appears to have--undocumentedly--suddenly
required PackageKit as a hard dependency. For example, removable storage
mounting no longer works if PK is not installed due to the way that the
default dbus fdi rule is written. Aside from the hal harddep problem, it
appears that PK is sorely, sorely missing its documentation. For example,
having this new dependency thrust upon me would have been fine if things
like /usr/share/doc/policykit-gnome/README didn't contain:

TODO: write me

If RH is going to thrust PK on us, please, please, please provide some kind
of documentation (not an API reference). When things don't work (as they
aren't now and were previously) I have absolutely no idea what's wrong,
where to look or who to blame. Most importantly, I wanted to file a bug but
couldn't even manage that with the spectular lack of information out there.

Luckilly, Rob Taylor was gracious enough to point me in the right direction
from what he has in his own memory. Alas, correcting for an obvious
packaging error hasn't solved to problem so I'm stuck again. I'm sure others
would not be even this fortunate...

Ever so politely,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list