Re: AT-SPI hard code freeze break request

[Elijah Newren]

On 9/15/07, Willie Walker <[EMAIL PROTECTED]> wrote:
> Hi All:
>
> GNOME 2.20.0 is pyatspi's first official release to the world, so we
> want to get the API as close to AT-SPI as possible.  In addition, we
> want it to support the impending FF3 event type annotation feature.  The
> patches in question accomplish these goals and have been tested by
> various members of the AT-SPI, Accerciser, and Orca teams.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=467366 is most important
> because it will allow the new Firefox 3 annotated event types to come
> through to users of pyatspi (e.g., Dogtail, LDTP, Accerciser, and soon
> Orca).  Without this patch, the annotated Firefox 3 event types do not
> make it through, breaking any pyatspi client that happens to be
> listening for the events, whether they are annotated or not.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=472301 is important as well
> because it will allow users of pyatspi to get the expected experience of
> AT-SPI where the return value of the event handler specifies whether or
> not to consume a device event.  Without this patch, the return value is
> ignored, breaking with the expected experience of AT-SPI.

I really hate hard code freeze break requests of this magnitude, but
given your testing and careful explanation...and the fact that new
changes in FF are somewhat forcing your hand, here's approval 1 of 2.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: AT-SPI hard code freeze break request

[Elijah Newren]

On 9/15/07, Eitan Isaacson <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I am assuming this is the green light to apply the patch of the first
> bug?

Nope, you need two approvals from r-t members for any freeze break
approval.  I gave you one of them (for each patch).  You'll need
another for each patch before they can be committed.

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

Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))

[Elijah Newren]

On 9/16/07, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit :
> > Ok, lets be fair:  most people who care about hacking on GNOME already
> > know git, why should other options be selected?
>
> I don't think it is fair to state this. A lot of people certainly care
> about hacking on GNOME and don't know git (and don't care about it).

Interestingly enough, I think I can see both sides.  While I haven't
done a thorough poll or anything, I have long taken note of others in
the community adopting various VCSes.  I don't have any solid records,
but my guess is that you'd find a relatively high correlation between
git users and those hacking on low-level bits of GNOME.  I don't
recall seeing any adoptions of VCSes other than git by those I'd
consider a low-level hacker (which, now that I make that statement, I
fully expect one such person to adopt one and then email me just to
prove me wrong.)

Also, I'd guess from what I've seen that those hacking on higher-level
bits of GNOME are both less likely to have adopted a different SCM
than cvs/svn, and among those that have, are less likely to have
chosen git than one of the other alternatives.

This may be an important point to investigate before weighing
advantages/disadvantages of various systems, as the appropriate
weights may vary considerably depending on which part of the community
someone is involved in.

Just some food for thought,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))

[Elijah Newren]

On 9/17/07, Sebastien Bacher <[EMAIL PROTECTED]> wrote:
> Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit :
> > Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit :
> > > Ok, lets be fair:  most people who care about hacking on GNOME already
> > > know git, why should other options be selected?
> >
> > I don't think it is fair to state this. A lot of people certainly care
> > about hacking on GNOME and don't know git (and don't care about it).
>
> I think Vincent is right there, looks like some people are using git and
> trying to make it look like that's the case for everybody else in the
> GNOME world which is not correct

To be fair, if my guess is right that low-level GNOME hackers are
highly correlated with git users (and anti-correlated to usage of
other SCM systems)[1], then it may well have seemed to Behdad that
this was in fact the case, as he is most likely to interact
development wise with his fellow low-level hackers.

Again, just some food for thought.

Elijah

[1] 
http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00195.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: NetworkManager and nm-applet inconsistences in 2.20 jhbuild moduleset

[Elijah Newren]

On 9/21/07, Claudio Saavedra <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-09-17 at 12:40 +0200, Rodrigo Moya wrote:
> >
> > you need to change it in jhbuild/modulesets/gnome-2.20.modules
>
> Oh, yes. I know. But the question is whether to use the nm-applet branch
> officially in the module set or not.
>
> I'm locally using the branch, but haven't committed that change. It
> seems the sane thing to do, though.

gnome-2.20.modules might be misleading; it's not "official modules in
the release set" (that's what gnome-suites-2.20.modules is), but
rather just "other cool and useful modules."  So I don't see any
problem having nm-applet and NM in it.

I'd say that we'd usually want to build stuff in gnome-2.20.modules
from trunk/HEAD/whatever-development-is-called, unless the module
isn't able to keep their development version dogfoodable and just
introduces too many build problems.

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

Re: NetworkManager and nm-applet inconsistences in 2.20 jhbuild moduleset

[Elijah Newren]

On 9/21/07, Claudio Saavedra <[EMAIL PROTECTED]> wrote:
> I'd say, that given 2.20 is stable now, using the stable brach of
> NM(-applet) is the right thing to do. I tried trunk branches for these
> apps, and they are not dogfoodable to my taste, and probably more
> appropriate for the 2.22 release set.

Sounds good.

> So, I'm installing the patch below in SVN. It is worth remembering that
> current status in gnome-2.2x.modules won't allow nm-applet to be built,
> and after this patch installation, it will.

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

Proposed passing of the baton

[Elijah Newren]

Hi all,

Recently I proposed to the release team that it's time for someone
else to take the role of GNOME's Release Manager.  With their
agreement, I bring the proposal to the development community at large
to have Vincent Untz take the reins.

Rock on, Vincent. :-)

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

Re: Panel Applet Development For Gnomd 2.22

[Elijah Newren]

On 10/8/07, Edwin Marshall <[EMAIL PROTECTED]> wrote:
> I've been doing a lot of research lately, and have decided that I want to
> start developing gnome panel applets. Unfortunately, all of the tutorials
> are outdated (with the latest one I found being dated 15 April 2007).
> Furthermore, it would seem that the current version of panel applet
> development uses the bonobo architecture, which will be obsolete as of Gnome
> 2.22 (as per releas notes).

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

Re: Lowering the barrier (was: Re: build systems)

[Elijah Newren]

On Nov 10, 2007 7:41 AM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote:
>
> >  * GObjects are conceptually difficult when you have standard
> > knowledge of C# or Java
>
> you know you don't have to use GObjects with C, right? you can write
> native C# and Java applications.

...or python or perl or c++.  I'm an example of someone who never
bothered learning much of anything about GObject, yet have still done
a fair number of contributions.  In fact, my contributions have mostly
been to existing apps/libraries written in C (just avoiding any parts
of the code dealing with GObject).

> >  * Autotools are exceptionally hard to work with
>
> they are not "exceptionally hard". they require documentation, and we

I'll agree with Mikkel, here.  They are exceptionally hard.  And I
think "getting started" tutorials which include info on autotools do a
disservice to would-be contributors.  My eyes glazed over lots of
times trying to read such documentation and it definitely hindered my
becoming a contributor.  I eventually figured out that I didn't need
to bother with that mess in most cases (someone else will always
contribute auto-tooling patches), though I did eventually learn a fair
amount and have fixed various issues here and there.

> >  * Some parts of the Gnome API are just plain hard to use. Ever tried
> > implementing a panle applet? Wonder why we have to many apps using
> > tray icons?
>
> from a cursory glance in my chat logs of #gnome on irc.gimp.org and
> gtk-list archives it seems that everybody start with panel applets; I

Not me!  But I agree with the rest of your comments.

> >  * General API docs are not as good as they could be. Compare QT4
> > documentation with GLib to see the point.
>
> maintainers in glib and gtk+ have been incredibly responsive in pushing
> documentation patches; people rarely have to wait a day for a commit
> authorisation (insert kudos to Matthias and Tim here). we need more
> people fixing the documentation and attaching patches to bugzilla. it's
> quite easy.

I agree with Emmanuele here, though I have some extra comments about
helping out with developer documentation:

I thought it'd only take me a couple weeks of spare time to get up to
speed and start contributing way back when I was getting started.  I
was off by at least an order of magnitude, in large part due to
lacking documentation.  Lacking either because it didn't exist, or
because it was inappropriate for beginners (despite the fact that
everyone would point beginners at these documents).  The documents
that did exist would often waste my time on stuff like autotools,
intltool, popt, gobject, compiling from cvs, etc.  Just give me enough
info to get started on creating *something*!  (I can learn how to
generalize the thing later to handle a11y, i18n, u7y, a1t, portable
building, source control...but let me start by being able to create
something simple I can see now!)  At some point when I (and others)
were complaining about this, Luis suggested that I write such a
document.  Sure, it took me a while to be able to do so as I had to
learn some stuff, and the document I wrote was pretty simple and far
from complete (http://www.gnome.org/~newren/tutorials/developing-with-gnome/,
and is now a little bit out of date too) but I had LOTS of people
thanking me for writing it and saying that it was VERY helpful to
them.

Someone else needs to pick up the torch and write more.  But please
don't waste the time of beginners at the start by making them learn
every possible technology that might be used.  Help them make
something simple.  Then extend it a bit.  Let all the general stuff
come later.  Putting it up front just means  they'll either give up or
take *far* longer to become a useful contributor.

> >  * It is sometimes hard to grok how an application or lib is
> > internally structured. While
> > http://library.gnome.org/devel/platform-overview/stable/ goes some of
> > the way describing the platform as a whole, the internal structure of
> > apps and libs are sometimes elusive.
>
> you have the code. if the application/library is complicated pester the
> maintainers for explanations and submit a patch documenting the nasty
> bits. or removing them, if possible.

I had the same difficulty as Mikkel, and believe that several people
do.  After learning metacity, I added some documents to try to fix
this.  See

http://svn.gnome.org/viewvc/metacity/trunk/HACKING?view=markup
http://svn.gnome.org/viewvc/metacity/trunk/doc/code-overview.txt?view=markup

Comments I've heard since that time seem to suggest that these
documents have been very helpful for others wanting to contribute.  I
meant to add such documentation for libwnck and bugzilla as well; I
wrote a little bit of information for both (though I only committed
the libwnck stuff; and lost my preliminary bugzilla docs at some
point).  It'd be great to find other volunteers willing to learn a
module 

Re: Lowering the barrier

[Elijah Newren]

On Nov 11, 2007 3:16 AM, Sebastian Pölsterl <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Who schrieb:>
> > *** In the case of 'Gnome Love' bugs - perhaps people people could
> > offer to 'mentor' on them, so anyone needing to ask questions in
> > attempts to fix them can have a ready contact. I understand, of
> > course, that time is important and it may well be quicker for that
> > mentor to fix the bug themselves - even so, perhaps it is worth it?
> >
> I totally agree on this. Each GNOME love bugs should have a mentor and a
> short explanation how to contact that mentor. If you know that you can
> ask someone who's familiar with the particular application it's much
> much easier to start contributing, instead of programming without
> "supervision" where you'll feel lost pretty soon.

Go to http://bugzilla.gnome.org/reports/gnome-love.cgi.  You'll see
the following:

This report shows bugs marked with the gnome-love keyword. That
keyword is used as follows:
Marking a bug with this keyword means that you're willing to help
someone fix the bug, or that it should be fixable by a beginner
without any help. This should ONLY be set by a maintainer or people
familiar with the code base, and ONLY when it looks like a project
suitable for a new developer looking for a task.

The report also lists who marked the bug with the gnome-love keyword,
and if you are logged in you can get anyone's account name (i.e. email
address) in bugzilla.

The same text describing the gnome-love keyword can be found at
http://bugzilla.gnome.org/describekeywords.cgi.


Is the gnome-love keyword being misused, or are potential contributors
just unaware of this?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: strawman (Was Re: build systems)

[Elijah Newren]

On Nov 12, 2007 2:09 AM, Nicolas Trangez <[EMAIL PROTECTED]> wrote:
> While I do agree using some declarative language to describe a build
> process is useful for IDE integration, I think this wouldn't be a gain
> for maintainers not using any IDE, as maintaining the build files would
> be rather hard

Perhaps, but would that be any change from now?  I literally left that
for other people to take care of in packages that I maintained
(metacity, libwnck) for a long time for two reasons: (1) I couldn't at
the time, (2) why bother when someone (or something) else will handle
it -- I'd rather concentrate on useful stuff.


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

Re: Bumping avahi requirement for GNOME to 0.6.21

[Elijah Newren]

On Nov 13, 2007 12:21 PM, Olav Vitters <[EMAIL PROTECTED]> wrote:
> > In that case I ask to bump it to 0.6.17
>
> +1 for me (needs another +1)

Nah, external deps aren't like freeze break requests.  Any member of
the release team should feel free to update the external deps page or
direct anyone else to do so (e.g. build-brigade).  It's just that if
the build breaks due to the update, you're (at least partially) to
blame.  :-)  If my text on the ExternalDependencies page isn't clear
on this point, let me know how to fix it up.

Basically, I think version bump approvals should be somewhat
automatic; the approval is mostly there to avoid surprising people
with additional dependencies and build breaks (which got completely
out of control a few releases back).

Oh, and didn't we agree at the last r-t meeting to have build break
requests moved from d-d-l to release-team@, in order to lower the mail
volume there?  We need to update that wiki page with the new
instructions...


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

Re: Bumping avahi requirement for GNOME to 0.6.21

[Elijah Newren]

On Nov 13, 2007 10:34 PM, Elijah Newren <[EMAIL PROTECTED]> wrote:
> Nah, external deps aren't like freeze break requests.  Any member of
> the release team should feel free to update the external deps page or
> direct anyone else to do so (e.g. build-brigade).  It's just that if
> the build breaks due to the update, you're (at least partially) to
> blame.  :-)  If my text on the ExternalDependencies page isn't clear
> on this point, let me know how to fix it up.
>
> Basically, I think version bump approvals should be somewhat
> automatic; the approval is mostly there to avoid surprising people
> with additional dependencies and build breaks (which got completely
> out of control a few releases back).
>
> Oh, and didn't we agree at the last r-t meeting to have build break
> requests moved from d-d-l to release-team@, in order to lower the mail
> volume there?  We need to update that wiki page with the new
> instructions...

Note to self: remember to trim the CC list when you mean to respond
only to certain individuals.

Oh, well, perhaps it's useful info to others as well.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bumping avahi requirement for GNOME to 0.6.21

[Elijah Newren]

On Nov 14, 2007 9:44 AM, Shaun McCance <[EMAIL PROTECTED]> wrote:
> > Oh, and didn't we agree at the last r-t meeting to have build break
> > requests moved from d-d-l to release-team@, in order to lower the mail

s/build break requests/external dependency changes/

What in the world does build break requests mean anyway?  I need more
sleep or something...

> > volume there?  We need to update that wiki page with the new
> > instructions...
>
> That would preclude me from seeing the requests.  While none
> of the freezes require approval from the documentation team
> approval, the release team often makes their UI freeze break
> approvals contingent on approval from the documentation team.

This has nothing to do with freezes and freeze break requests and
there are no plans to change those.

> On a related note, is this the authoritative page for freezes?
> http://live.gnome.org/ReleasePlanning/Freezes
> I thought it was agreed that UI and string breaks required
> notification to the documentation team, but I don't see any
> mention of that on the page.  I'll gladly fix it, unless I'm
> mistaken about the notification requirement.

Um, it almost looks more historical taking a look at it, but we have
page that is more official.  Feel free to fix it up.  Thanks!

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

Re: TARBALLS DUE: GNOME 2.20.2 Stable Release [date correction]

[Elijah Newren]

On Nov 23, 2007 11:08 AM, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Tarballs are due by Monday November 19th before 23:59 UTC for the GNOME
> 2.20.2 Stable Release, which will be delivered on Wednesday.

Quick correction: This should read Monday November 26th (see also
http://live.gnome.org/TwoPointTwentyone).

Please everyone, get those tarballs in because ice cream consumption
causes typos for certain French GNOME contributors and he needs help
kicking the habit.  Otherwise, those typos may enter the source code
for gnome-session, gnome-panel, libwnck, or any of several other
modules.


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

Re: Extreme memory usage for gnome-panel related apps

[Elijah Newren]

On Nov 30, 2007 2:46 PM, Mark <[EMAIL PROTECTED]> wrote:
> 2007/11/30, David Zeuthen <[EMAIL PROTECTED]>:
> >  http://live.gnome.org/GnomeLove
> >
> > to learn more about how you can help fix these things in the GNOME
> > Desktop. Thanks.
>
> oh men.. do they really have that.. they must have been in a funny
> mode when they thought about that name. But about the contributing

The name was coined by a non-native English speaker if memory serves
me right.  But yeah, it's a lousy name.


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

Re: Request for Rarian external dependancy bump

[Elijah Newren]

On Nov 27, 2007 3:30 PM, Don Scorgie <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As some of the eagle-eyed among you may have noticed, I released Rarian
> 0.7.0 several days ago.  Since then I've been working on making yelp
> work with the (incompatible) new series.
>
> I've now done this to the point I'm fairly happy and am now requesting
> permission to update the Rarian external dependency for GNOME 2.22 to
> the Rarian 0.8 series (i.e. 0.7.0 - 0.8.0).  For now, the minimum and
> recommended version would be 0.7.0 but Rarian follows the GNOME release
> cycle so this will be 0.8.0 when GNOME 2.22 is released.
>
> (For those interested, the attached patch is the work required to port
> across.  Oh, and I also made category icons work again ;) )
>
> If I've missed a list, please let me know and I'll add them.

/me continues waiting for a build brigade member to start jumping on
all external dependency bump requests, testing their buildability with
all of gnome, and if there's no build issues or cascades of other deps
needing version bumps, then updating the jhbuild modulesets, notifying
garnome, and updating the wiki page to reflect the bumped version.

Someday, it'll happen.  I'll keep prodding people here and there until
someone decides to.  And when it happens, we'll all be happier.  You
can be that someone.  :-)


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

Re: WAF (Was: build tools)

[Elijah Newren]

On Dec 2, 2007 3:46 PM, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote:
> In case anyone is interested, feel free to try out a 100% WAF-ied
> version of gnome-python:
>
> http://www.gnome.org/~gjc/gnome-python-2.21.0.tar.bz2
>
> The WAF based tarball (including a self contained waf script, which is
> all you need to build) is 249K, while an autotools version is 424K.  I
> could reduce the size even more if I removed configure.ac and the
> Makefile.am's.  It also builds much faster, especially if you count
> the ./autogen.sh part, though I didn't to get actual numbers.

Ooh, I'd love to see timing numbers.  The size differences are pretty
impressive; it would likely make a noticable impact on times for
building releases for garnome users, release team members, and others.
 Anyone want to cook up a patch for libwnck/metacity so I can see how
quick and small it is on my module(s)?  (Hey, if I'm too lazy to deal
with autotools for my modules and almost always delegate it, I can
also be too lazy to deal with any other system, right?)

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

Re: WAF (Was: build tools)

[Elijah Newren]

On Dec 2, 2007 5:07 PM, Colin Walters <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-12-02 at 16:55 -0700, Elijah Newren wrote:
> > Ooh, I'd love to see timing numbers.  The size differences are pretty
> > impressive; it would likely make a noticable impact on times for
> > building releases for garnome users, release team members, and others.
>
> Time I don't think as interesting as "Is it easier to debug than auto*"?
> So we have a hope of new contributors not being totally lost when the
> chain of makefiles generating shell scripts generating makefiles
> generating shell scripts has some error somewhere.
>
> I'm leaning towards yes - I'd take a Python traceback over that any day.

I had implicitly assumed that it couldn't be any harder.  I do agree,
though, that it's definitely important and it'd be better to find out
than just assume.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dependency: PolicyKit/PolicyKit-gnome

[Elijah Newren]

On Dec 20, 2007 8:59 AM, David Zeuthen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I actually asked the release team and got two replies saying external
> deps are fine and there was no need to bless/ditch such deps. So maybe
> we want to wait until the 2.24 proposal period for this discussion?

I believe you meant to say "soft deps" rather than "external deps",
yes?  If no one wants to add a hard dependency on PolicyKit, then yes
we don't need to worry about this right now.

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

Re: Time for the annual bugzilla statistics!

[Elijah Newren]

On Jan 8, 2008 4:24 PM, Olav Vitters <[EMAIL PROTECTED]> wrote:
> > The following people closed more than 4000 bugs in 2007:
> >   9800 Tom Parker
> >   7047 Susana Pereira
> >   6882 Bruno Boaventura
> >   6649 Pedro Villavicencio
>
> For some reason the people making these overviews:
> 1. Often are at the top of the triager list
> 2. Never mention themselves

The reason?  That I can tell you in one word: TRADITION![1]

> anyway:
>
> #1 triager for 2007:
>   14254Andre Klapper

Hey, that's not part of the tradition.  I call foul play.  :-)

Awesome work, Olav and Andre; thanks for sending out this round of
annual bugzilla statistics.  And congrats to the many who obviously
worked incredibly hard this year.  These stats are impressive.

Elijah


[1] http://www.imdb.com/title/tt0067093/
___
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.22

[Elijah Newren]

On Jan 9, 2008 5:51 PM, David Zeuthen <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-01-09 at 18:45 -0600, Federico Mena Quintero wrote:
> > On Thu, 2008-01-10 at 00:34 +0100, Vincent Untz wrote:
> >
> > > Retracted:
> > >   PolicyKit & PolicyKit-gnome (external dependency)
>
> I kinda dislike the wording here. I didn't retract anything. What did
> happen was that several members of the release team pointed out to me
> that it was just an external dependency and thus didn't need to be
> proposed.

Clarification: ...that it was an external dependency *which no one
plans to have a hard dependency on*.  Huge difference.

> > Eeep.  Do you think we can/should push intlclock into
> > gnome-panel/applets/clock for 2.22?  If so, we'll need PolicyKit (not
> > PK-gnome as far as I can tell).
>
> It should use PolicyKit-gnome (for code reuse etc.) and as far as I
> understand it's fine for it to do so. Both PK and PK-gnome are blessed
> external dependencies.

??

Blessed as far as gnome releases goes means allowed as a hard
dependency for modules.  PK and PK-gnome are not blessed external
dependencies because you said that no hard dependencies were needed at
this time.

(I'd give my +1 for blessing them now if we need it, it just was
assumed that we didn't need to discuss it.)
___
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.22

[Elijah Newren]

On Jan 9, 2008 6:16 PM, David Zeuthen <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-01-09 at 18:10 -0700, Elijah Newren wrote:
> > Blessed as far as gnome releases goes means allowed as a hard
> > dependency for modules.  PK and PK-gnome are not blessed external
> > dependencies because you said that no hard dependencies were needed at
> > this time.
>
> Oh, the use in intlclock should be optional if it isn't already. That
> does not equate to "pull out PolicyKit deps" as I believe it made
> Fedoric think. Sorry for the confusion.

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

Re: GNOME 2.20.3 released!

[Elijah Newren]

Hi Carlos,

On Jan 10, 2008 5:10 AM, Carlos Diógenes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to know why gnome-mag-0.15 wasn't included in this release?

Sorry, apparently someone (probably me) assumed that the stable
release version numbers of gnome-mag would be 0.14.x and that 0.15 or
higher would represent development releases for the 2.21 release
cycle.  The stable release scripts are set to ignore gnome-mag>=0.15
for the 2.20 stable cycle.  I do apologize for the error.  However,
please also note that despite our best efforts, errors of this sort
are likely to occur again (with other modules if not gnome-mag); there
are hundreds of modules in GNOME and by not using GNOME major and
minor version numbering, there's just too much room for human error.

You can also take a look at
http://svn.gnome.org/viewvc/releng/trunk/tools/smoketesting/tarball-conversion-stable.config?view=markup
and
http://svn.gnome.org/viewvc/releng/trunk/tools/smoketesting/tarball-conversion.config?view=markup
to make sure the release team is using sane settings.  We do our best
to make them right, but limited time & natural human error means that
we're not perfect.  Unfortunately, fixing the stable one right now
won't do any good as all the values will be modified again when 2.22
comes out.

Hope that helps,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bump Avahi external dependency

[Elijah Newren]

2008/1/16 Wouter Bolsterlee <[EMAIL PROTECTED]>:
> 2008-01-16 klockan 11:31 skrev Luca Ferretti:
> > Changes in avahi:
> > [snip]
> > * i18n support - from 0.6.22 (well, by now there are no
> > translations available...)
>
> For this sole reason I'd say we'd want to bump the dep up. Thanks for
> listening to a non-native speaker! :)

For this and the other reasons listed, sounds good to me.  Updated.  :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Swfdec: required external packages

[Elijah Newren]

On Jan 29, 2008 12:32 PM, Benjamin Otte <[EMAIL PROTECTED]> wrote:
> I looked into jhbuild and external deps are always tarballs. So I was
> wondering if there was a policy against depending on development
> versions for external deps. It's a bit more work for jhbuilders after
> all.
> Otherwise I'd update the modules to depend on Swfdec git until 0.6.0 is out.

Yes, this was a very deliberate policy decision.  Tracking
svn/cvs/git/whatever of external dependencies made gnome essentially
unbuildable a few cycles back.  It wasn't just SoC students spending
their first three *weeks* trying to do nothing but get Gnome to build,
we had lots of developers saying they couldn't complete the task
either and couldn't test their own module against current svn of other
modules.  Despite updating my build several times a week, even I was
struggling to keep things built.  It was a nightmare.

But, as you control swfdec, you can handle this situation relatively
easily: release early & release often is your friend.  I don't think
there would be any problem bumping the external dependencies page
every week or even every day if you need it to depend on whatever new
version of swfdec you have released (of course, we want someone to
verify svn still builds before bumping, but beyond that I'm not
opposed to bumps leading up to swfdec-0.6).

Thanks for the awesome work.  Hope this response helps,

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

Re: GNOME 2.21.90 Development Release

[Elijah Newren]

On Jan 31, 2008 3:21 PM, Mike Kestner <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-01-30 at 21:49 -0700, Elijah Newren wrote:
> > =
> > GNOME 2.21.90 Development Release
> > =
>
> Hey Elijah,
>
> I noticed that you folks picked up gnome-sharp-2.19.91 for this release.
> In our current development releases, we have split the existing
> gnome-sharp binding set into two packages: gnome-sharp and
> gnome-desktop-sharp.
>
> We have moved our rsvg, vte, and gtkhtml bindings from gnome-sharp to
> gnome-desktop-sharp in an attempt to clarify the stable/unstable status
> of the APIs.  We also have added a few new bindings to
> gnome-desktop-sharp.
>
> I didn't officially pursue inclusion of gnome-desktop-sharp for 2.22
> because of the timing of when all this started coming together, though
> at this point, I'm confident gnome-desktop-sharp 2.20 will be ready when
> GNOME 2.22 ships.
>
> It would be great if the gnome-desktop-sharp package can be included in
> 2.22.  If it's too late or too controversial to do so at this point,  I
> would suggest that you revert to gnome-sharp 2.16.x for 2.22, since
> shipping gnome-sharp 2.20 without gnome-desktop-sharp will remove
> functionality.
>
> Let me know if I can provide any more info.

Given that it's primarily a split of an existing module, I think it'd
make sense to include both rather than reverting.

What does everyone else say?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: install-module on master.gnome.org

[Elijah Newren]

On Fri, Mar 21, 2008 at 4:06 AM, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Le jeudi 20 mars 2008, à 22:27 -0400, Andrew Cowie a écrit :
>
> > On Thu, 2008-03-20 at 22:39 +0100, Olav Vitters wrote:
>  > > There is no reliable way to determine
>  > > the latest versions.
>  >
>  > You said you'd be working in Python; the Gentoo linux people have some
>  > excellent ordering algorithms embodied in Portage. I can ask around to
>  > find out the particular code to look at if you're interested.
>  >
>  > But either way, it'd be nice if we can manage to make this not be a
>  > bugaboo that gets in your way. I know we're going to keep using rc's.
>
>  Any reason to not switch to the GNOME module versioning scheme? See
>  http://developer.gnome.org/gep/gep-4.html
>
>  It's not mandatory, but it makes it easier for a lot of people to use
>  the same scheme.

Not all parts of gep-4 are mandatory.  But that gep is 6 years old,
and since that time *every* gnome module has adopted the
numeric-characters-(and-period-)only rule...except for very recent
versions of java-gnome.

In fact, I would have stuck this exact piece of information on
http://live.gnome.org/ReleasePlanning/ModuleRequirements when writing
that, except for the fact that I noticed all modules were already
following it so I didn't think it was worth repeating.

In my opinion, this part of the gep should be mandatory for the
reasons Olav and Christian has pointed out.


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

Re: Removing libgnomeprint* from the desktop set

[Elijah Newren]

On Fri, Mar 28, 2008 at 10:12 AM, Vincent Untz <[EMAIL PROTECTED]> wrote:
>  I'd like us to finally stop shipping libgnomeprint/libgnomeprintui as
>  part of the desktop set. As far as I can tell from the jhbuild
>  moduleset, it's only used by:
>
>   + anjuta, with the scintilla editor plugin (but there's the
>gtksourceview editor plugin)
>   + tomboy: http://bugzilla.gnome.org/show_bug.cgi?id=512369
>   + gnome-python-desktop, for bindings
>   + gnome-sharp, for bindings
>   + gtksourceview 1.x, which I'd like to kill :-) see previous mail for
>this.
>
>  Opinions?

Sounds like a good idea to me.  :-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Why do GNOMEdevelopers almost exclusively use git mirrors and for example not bzr mirrors

[Elijah Newren]

On Tue, Apr 8, 2008 at 12:35 AM, Jaap A. Haitsma <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  I was just wondering why many GNOME developers are using git mirror
>  and for example not a bzr mirror? If I for example read
>  http://live.gnome.org/DistributedSCM I have the feeling that bzr would
>  also be a very good fit. However I haven't seen any gnome.org project
>  in a bzr mirror while of many projects there exists git mirrors.

It can more or less be explained here:
http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/

People learn about good tools and practices from other developers.
bzr was far too slow to be used on big projects for many years, and
during that time, git came along and impressed many people with speed
and some of its features.  Thus, developers from big projects started
adopting it.  Then other developers on those big projects started
looking at it.  Then developers of related big projects started
looking at it.  linux kernel->xorg->lowlevel gnome/kde library
maintainers   Meanwhile, while bzr had superb usability from an
interface point of view, it was (and remember, I am talking past
tense) painful to use even on small personal projects simply due to
the amount of time operations took; there was no way it could be used
for large projects due to these time issues and thus it was cut off
from a lot of the same network effects.

An additional effect causing some of the adoption you've seen were the
svn bridges.  bzr's would require a number of patches to subversion
and still have problems with larger repositories, while git's would
work -- once you figured the commands out (but for those working on
larger projects, they use the version control system a higher
percentage of their day and thus could spend their effort learning the
less friendly interface).

bzr is much faster now and on par with hg & git...but it's way behind
the curve in terms of adoption; it's highest penetration is probably
within gnome users, but even there as you note in your email you find
it lagging and often not used on the larger projects where it could
cause more network effects.  While perhaps it could be...most such
projects have already adopted git.  There are many compelling reasons
to move away from svn, there's not so many for switching between
bzr/hg/git.

Does that help?

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

Re: Why do GNOMEdevelopers almost exclusively use git mirrors and for example not bzr mirrors

[Elijah Newren]

On Tue, Apr 8, 2008 at 4:55 AM, Olav Vitters <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 08, 2008 at 11:45:34AM +0100, Scott James Remnant wrote:
>  > (At least, that's what I understand)
>
>  Indeed. This might be hard to do within Bzr (IIRC what Elijah said), due
>  to repository format / design.

No, I mispoke in the email you're referring to.  bzr's repository
format does not prevent such a feature (in fact, they likely already
have most needed capabilities), and shared repositories are much
closer to what I'd like than I realized at that time.  The UI design
does seem somewhat antithetical to such a feature, but perhaps that
could be changed.

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

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

[Elijah Newren]

Hi Max,

On Thu, Dec 4, 2008 at 2:28 PM, Max Kanat-Alexander <[EMAIL PROTECTED]> wrote:
>Hey folks. I'm Max, from the Bugzilla Project. I also have a
> company called Everything Solved, and we'd be the ones doing the
> upgrade work if it happens.

This is great news.  :-)

>All the attachment status stuff will still be there. The fact
> that they *show up* in the attachment table will probably even be there.
> They haven't ever been *changeable* from show_bug.cgi, as far as I
> could see in the code.

They are readily changeable in show_bug.cgi in Gnome's customized
version of bugzilla.  (See
http://bugzilla.gnome.org/show_bug.cgi?id=135697; note that the status
column in the attachment table changes from text to a drop-down combo
box when logged in with appropriate privileges so we might need to
hand you some of those first).  Not being able to change patch
statuses there all in one go, as would be the case with stock upstream
bugzilla right now, would be a big loss.  In my opinion, anyway.

>As far as collaboration goes, we're always looking for new
> contractors (that is, we're willing to pay people who are good
> Bugzilla developers to help us out on the project), but there is a
> definite code quality concern. I will be reviewing everything, and so
> somebody has to be able to demonstrate that they can produce
> high-quality Bugzilla code quickly, or they're going to be spending
> more of my time than they're saving.
>
>As far as upstreaming goes, I think we'd all like that, but
> that's up to the funder, not me. If anybody else would like to fund
> upstreaming, that would work, too. Or anybody is free to take the
> patches that we create (which will be under the Mozilla Public License)
> and attempt to upstream them, themselves--that's fine, too.
>
>From the feedback, it sounds like the most important items to
> bring back immediately after we have an upgraded bugzilla.gnome.org are:
>
>1. Canned responses
>2. simple-dup-finder
>3. Patch and keyword emblems
>4. NEEDINFO asking
>5. show_bug re-ordering
>6. Other layout modifications
>
>And then the other features after that.
>
>Is that right?

Those may be first, but I think it's also important to explicitly list
the following:

* patch review statuses editable from show_bug.cgi.  This was
mentioned by Olav, Cosimo, Matthias already, and is important to me.
IIRC, this feature originated as a developer request from Mark
McLoughlin to streamline an otherwise quite slow process, and has been
a hit with many developers ever since.

* boogle replacement + product pages (mentioned by Olav and Matthias;
I'd also list it as the thing most important to me.)  See
http://bugzilla.gnome.org/browse.cgi?product=pango for an example;
note that some items change depending on whether you're logged in,
though most of the page is the same either way.  This page provides
lots of information at a glance and provides all kinds of links to
make it easy to dig deeper about a module.  It also serves a nice UI
discoverability purpose: teaching users how to form quick useful
searches (click on various non-underlined links in the page)

* describeuser.cgi webpage (mentioned by both Olav and Cosimo; only
viewable if you're logged in).  Gnome Bugzilla puts quite a bit of
useful information on this page, such as which modules the user
maintains, which modules the user is interested in (i.e. which
modules' -maint aliases the user has elected to watch), which bugs and
patches they've filed (all with lots of useful links), etc.

* some system of user identification.  Currently, this is done in
Gnome bugzilla by specifying whether particular users are the
maintainer of the given module, a developer of some gnome module, how
active the given user has been in gnome bugzilla (the points system),
and links to the describeuser.cgi webpage.  Each small piece of this
almost seems trivial, but the net effect really adds up.  Think of it
as some kind of rudimentary combination of online trust system and
social networking.


I agree it's probably more important to get the upgrade done and
running than to get all the features in, but I wanted to provide some
perspective on some of these other important features.


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

Re: GNOME DVCS Survey Results

[Elijah Newren]

Hi,

On Sun, Jan 4, 2009 at 7:51 AM, Olav Vitters  wrote:
> 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).
>
> [1] or whomever. Although I don't see how that would work.

While I'm sure John will at least be able to get basic functionality
working, and the project has a certain amount of cool geek factor,
taking John's proposal as a path forward concerns many in the
community for a variety of reasons[*1].  (In fact, I bet such an
option would rank lower than any native vcs option had it been
included in the survey.)

I'd like to help with another path forward, namely native git
repositories since I believe that is what most of the community wants.
 As you said, it isn't clear how it could work for non-sysadmins to
come up with clear proposal strategies and implementations.  Are there
others on the sysadmin team who are willing to work on such a
transition?  If so, how can I help?

Elijah


[*1] Reasons I've seen or can think of off the top of my head:
* As James H. mentioned on John's blog, you'd likely end up with "the
intersection of the features of the two version control systems rather
than improving things."
* John's project does not have a large community behind it and
supporting it.  In fact, it may end up with a bus factor of 1[*2].
Even if it increases, it doesn't have the kind of large community
that, say, git-svn has.  In general, it's unsettling to many to adopt
a project without a large community behind it.
* John's bridge would have to be updated whenever either the bzr or
git formats changed (in particular, bzr has changed repository formats
several times and even promotes it's ability to seamlessly change
repository formats as an advantage), or whenever the network protocols
changed (including protocol extensions, such as the git push
tell-me-more extension).
* It would introduce extra lag between when new features become
available, since the bridge would need to be updated for each such
change.
* There's no guarantee bzr and git will change in ways that will make
them remain compatible, so we run the risk of accepting (additional)
feature losses as time goes on.  It may be a small risk, but we simply
don't know and have no way of knowing.
* All software has bugs.  John's bridge can't be exempt, and
particularly as new and not-yet-tested software, it's more of a risk.
Will that mean data loss?  Loss of features?  Inability to perform
certain operations?  While the bugs are being investigated and fixed,
what do maintainers do?  Use bzr since it's the official format?  I
think John's pretty clever and that we would likely avoid most such
issues -- but there's no guarantee and this is something that affects
developers daily work.
* I believe bzr proponents even admit that bzr is still slow for
network operations.  John's bridge would essentially add another layer
on top of that.

[*2] http://en.wikipedia.org/wiki/Bus_factor
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Elijah Newren]

Hi,

[Disclaimer: I wasn't involved in the construction or running of the
survey, other than the analysis you saw plus some late feedback on the
survey questions (I think my feedback was merely to suggest the
"other" answer for contributor types.)]


2009/1/5 Andrew Cowie :
> On Sat, 2009-01-03 at 22:46 -0500, Behdad Esfahbod wrote:
>> GNOME contributors with an SVN account who had an SSH key installed on
>> their account were invited to fill in the survey.
>
> [It is NOT my intention to get all negative here; I understand - and
> accept - that projects make decisions and not everyone is happy with
> them. Luckily this decision ultimately is one I can ignore.
> Nevertheless, I have been asked by a number of people to write to this
> thread with why I am so dissatisfied. I do appreciate the effort people
> made, even if I feel that the way the whole survey exercise was
> conducted it was impossible for Git to lose]

Thanks for taking the time to do so.  I'm sorry you feel that way
about the survey exercise; I was encouraged that people were moving
forward and that they had created what I felt was an unbiased survey
as possible (Behdad asked for feedback from the foundation board,
release team, and others before sending it out, and I think my main
comment at the time was that I was happy to see the lack of bias in
the survey; my only other comment was the "other" contributor thing,
IIRC.)

> Some comments:
>
> ++
>
> It's a shame that hackers who contribute to GNOME projects which don't
> use svn.gnome.org were excluded.
>
>(I was told their opinions didn't matter. {shrug} that's fine,
>so long as nobody tries to represent this survey as "what GNOME
>hackers think")

How would you draw the line?  Who should be included and who
shouldn't?  And how do we contact them all?  I think doing a survey of
any group other than those with svn commit access would be practically
unmanageable...and far more likely to be suspected of
non-representative-ness [New word!].

Also, if users aren't using GNOME svn then why would they care if we
switch or not?  Shouldn't the survey poll those whom it would affect?

> ++
>
> It was also a shame that I (one who does happen to have a GNOME svn
> account) was not able to complete the survey either because it crashes
> Epiphany when you i) vote for bzr and ii) withhold your vote from git,
> hg, and svn.
>
>(When I asked if it might be possible to fix the survey so that
>GNOME's web browser didn't crash, I was told "known bug" and
>"too bad, you have to express a preference for Git and Mercurial
>even if you don't want to". Strange take on democracy. I am
>rather accustomed to the idea that declining to express a
>preference for something is an acceptable form of voting.
>Whatever)
>
> I explicitly did not want to chose Git or Mercurial, because I knew
> exactly what was going to happen. I've heard it several times already in
> #gnome-hackers and elsewhere:
>
>"so it seems the people who prefer Bazaar like Git as their
>second choice, so surely it's ok to go with that. Great!
>Decision made"
>
> No. The rest of the survey was irrelevant. It was quite evident that the
> object of the exercise was to allow people to say "lots of people said
> Git was either their first or second choice" which sounds very
> impressive, and was exactly the one thing I did NOT want to support.
>
> So it crashed my browser. Nice.

That sucks.  Big time.

However, you'll be happy to know that most of my analyzing work was
originally performed on an alternative output file that included all
partial answers.  (It also contained a bit more data, such as svn
usernames -- and thus I can verify that your response was included in
this file and just did so.)  Now the reason this is relevant is that
when I got the final data in an alternate format from Behdad, I had
already generated all my plots and written my analysis.  So I had to
regenerate all the plots and compare old and new versions.  It turns
out the two sets were basically indistinguishable to my eye.  I spot
checked a couple of my claims in my analysis (e.g. that translators
preferred git over svn since it was so close in both data sets), but
actually didn't check them all.  Thus, you could say that my analysis
is more valid (or at least more verified) for the set of users that
also includes partial answers like yours.

On a related note, it looks like the total number of people who ranked
the various systems (taken from the data file including partial
answers) are:
  any: 581
  bzr: 585
  git: 583
  hg: 581
  svn: 582
So, yes, it looks like there were more people who left git unranked
than bzr -- the difference being two people.


However, I'm a bit confused by this statement:

   No. The rest of the survey was irrelevant. It was quite evident that the
   object of the exercise was to allow people to say "lots of people said
   Git was either their first

Re: fast-forward only policy

[Elijah Newren]

Hi,

On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras
 wrote:
> On the other hand 'gnome-2-0' is not pointing to any release, there
> where commits after the last release. So my question here is: who
> would care about those commits? They were done 6 years ago and nobody
> made a tag that contains them. The arguments I've heard apply to the
> stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0
> build, or make GEDIT_2_0_6 release, they'll probably go for the latest
> code that was actually released and used.

I disagree; I think they'd check out the branch and use it;
particularly since that has been the practice for a number of years
now.  But that's only one side of the issue, and the less interesting
one at that...

The reason these branches were created and kept was not merely because
subversion and cvs suck and can't reasonably delete old branches.  Due
to the various enterprise distributions, developers needed to continue
to apply patches and make other fixes to versions of the code that
were several years old and they were duplicating each others' work.
They had trouble discovering when others were doing similar backports
and where their work was.  So there was an effort to standardize old
branch names to make it easy to know where to put their fixes, and
where other developers could go to find them; these fixes were often
not straightforward backports given the divergence of the development
branch and these old versions.  (I believe it was started by an email
from Federico on desktop-devel-list, but it's been so many years that
my memory may be faulty there.) Yes, people decided that it was okay
for developers to commit their fixes without maintainer approval to
otherwise "unsupported" branches for this particular use.  Think what
you will of that solution, but if you delete these old branches you
will make finding and/or recording such fixes harder.  Those 6 patches
that are not part of any tag are evidence that the old system was
being used.  (I don't know if this is the optimal solution to the
problem, particularly given the better VCS available to us today, but
it was certainly low cost and made people happy.  I believe this email
thread is the first time in years anyone has expressed any issues with
that decision.)

Even in git.git there were maint-1.5.1, maint-1.5.4, maint-1.6.0, and
maint-1.6.1 branches, in addition to the standard pu, next, master,
and maint (check the log; you'll see the evidence these were there).
Since only Junio can push to git.git, he can create or delete branches
as he wants without affecting others; so he can (and did) delete these
branches once he knew they were no longer active.  But we have
multiple people accessing git.gnome.org, and others may be using these
old branches for years after most consider them to no longer be
'active'.  Since they were particularly there for people who were
_not_ the maintainer, the maintainer can't really know when they
aren't being used anymore.  (Maybe we could try to find out when a
particular version is no longer being used in *any* stable or
enterprise distribution?  I bet we could kill the 1.x branches, but
Solaris would probably cause us to keep all the 2.x ones around.)

Yes, I understand the desire to clean things up; it's nice to prune
stuff that's "not used" in git, especially since it is so easy to
recreate or even work without it.  However, these branches really do
have a reason and do have an important (though infrequent) use; so
unless you can come up with a convincing proposal for an alternate way
to handle these issues (and I may not be remembering all the issues
either), *and* can convince others that adopting a new mechanism and
trying to get it disseminated to everyone (which isn't easy due to
this being an infrequent use case and the fact of how few read
desktop-devel-list and even devel-announce-list) and show that it
should be less of a cost than keeping some branches around that appear
to be unused, then it's really unlikely that such a change will occur.

I think you could easily come up with such a proposal that I would not
have a problem with in my personal use (I don't like lots of branches
for the public repositories either); however, I'm not sure that others
are going to see changing a policy that will take time to communicate
to everyone is worth the cost of making things a little bit tidier for
you and me.  So I'm betting on a very uphill battle if you want to
pursue this; I certainly don't see the cost/benefit tradeoff as being
very encouraging and wouldn't put my time into it.

Anyway, I hope that at least provides some perspectives on why these
things exist and why you're seeing people oppose your proposal.


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

Re: fast-forward only policy

[Elijah Newren]

Hi,

On Wed, May 6, 2009 at 3:52 PM, Felipe Contreras
 wrote:
> On Wed, May 6, 2009 at 6:44 AM, Elijah Newren  wrote:
>> On Tue, May 5, 2009 at 4:24 PM, Felipe Contreras
>>  wrote:
>>> On the other hand 'gnome-2-0' is not pointing to any release, there
>>> where commits after the last release. So my question here is: who
>>> would care about those commits? They were done 6 years ago and nobody
>>> made a tag that contains them. The arguments I've heard apply to the
>>> stable releases (GEDIT_2_0_5), if somebody wants to create a GNOME 2.0
>>> build, or make GEDIT_2_0_6 release, they'll probably go for the latest
>>> code that was actually released and used.
>>
>> I disagree; I think they'd check out the branch and use it;
>> particularly since that has been the practice for a number of years
>> now.  But that's only one side of the issue, and the less interesting
>> one at that...
>
> *sigh*
>
> Do this command:
> $git checkout GEDIT_2_0_5
>
> Then do 'git branch'. What do you see? "(no branch)" Of course,
> completely unintuitive, how contributors are expected to create a
> 2.0.6 release under such hard conditions!
>
> Well, now do this command:
> $git checkout origin/gnome-2-0
>
> What does 'git branch' show this time? "(no branch)" Ah, much better!
> Now contributors will be on their element.
>
> Creating a local branch is a step that you need to do on both cases,
> there's no difference whatsoever.

That's kind of orthogonal to the point I was making and responding to.
 I was responding to your two comments, "who would care about those
commits" and "if somebody wants to create a GNOME 2.0 build, or make
GEDIT_2_0_6 release, they'll probably go for the latest code that was
actually released and used."  Using the GEDIT_2_0_5 tag vs. the
origin/gnome-2-0 branch give you different answers, since the branch
may have advanced past the tag; so there's a decision to be made.  You
have consistently claimed that those commits on the branch were
useless and no one would even look at them, and I was pointing out
historical precedent that was in conflict with this assumption of
yours.

> I express concern because when you use git properly branches are a
> central part of development (unlike other SCMs) therefore you *see*
> these branches all the time, which is annoying.

I agree.

> I understand the need for such branches like 'gnome-2-20'. It's
> unlikely, but some one might make a release out of that. But
> 'gnome-2-0'?

Maybe I missed your switch, but I thought you had been advocating
'master' and 'devel' and getting rid of 'gnome-2-x' branches until
today.  So I was responding to that.

I agree it'd be nice to move known-to-be-unused branches to some
archival or legacy area (refs/archive/*, refs/legacy/*?).  You just
have to be reasonably certain they are really unused (no enterprise
distro could possibly be using them anymore, etc.).  I'm guessing
there's very few gnome-2-x branches that are ready for archiving by
now.

> Do you seriously think because git.git is maintained by Junio nobody
> else has a clone of that repo? Of course not! Every git developer had
> a clone, and they all saw the maint branches. Some might have have
> work on top of those branches.
>
> Why didn't the world fell to pieces when Junio removed those branches?
> git is *distributed* if you have local main-1.6.0 branch with 4
> commits and Junio removes the branch what happens? Nothing, you only
> see that "origin/main-1.6.0" was removed, big deal. Your local
> main-1.6.0 remains intact.

I must have done a really poor job communicating; sorry about that.
You had been advocating only having 'master' and 'stable' branches.  I
was pointing out that even git.git went further than that and had the
equivalent of stable-x.y branches, and that I thought we would need
those too.  I figured you'd say, "yes, but they have since been
deleted in git.git", and so I proceeded to point out why I think gnome
is different and would need to keep several of those stable-x.y
branches around for a long time and not delete them.

> Yes, but what about branches like CORBA_ENABLED, GEDIT_VIEW, GNOME_MDI.

Oh, I'm a big fan of archiving old branches like these; that sounds
great.  I just think the gnome-2-x branches will need to be around
longer (e.g. rhel4 is still supported and ships with gnome 2.8), but
it sounds like you're now in agreement with that.


I hope this email is a bit clearer than my last; sorry about that.

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

Re: Qt as acceptable GNOME dependency

[Elijah Newren]

On Mon, Jul 13, 2009 at 9:52 PM, adel wrote:
> hey
>
> now Qt can be plugged into the Glib main loop and uses GTK+ for
> drawing, if I respected HIG and used GNOME API, can my Qt application
> be consider a GNOME application or even be part of default GNOME
> stack?

For a module to be part of the GNOME stack, its dependencies must
either also be part of GNOME, or be an approved external dependency
(http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies).

To have an app that depends on Qt be accepted into a GNOME release
set, you'd have to propose Qt itself for inclusion in GNOME or to be
made an official external dependency.  And then you'd have to see how
community consensus played out regarding your proposal.  In addition
to the community consensus bit being difficult to pull off in this
case, you'll also note that extra dependencies, especially at the
widget level, have historically gotten a fairly rough reception (e.g.
libsexy).

So, currently the answer is no.  There is a process by which that
could change...but the odds of being able to pull off that change are
not in your favor, to say the least.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Version numbers of apps in the gnome desktop.

[Elijah Newren]

On 9/10/05, Jaap Haitsma <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Currently most of the applications which are part of the gnome-desktop
> are the same 2.12 however some apps like evolution, totem, gnome-volume
> manager, epiphany (and maybe a couple more) have different version numbers.
> 
> Wouldn't it be handier when apps are entering the gnome-desktop to have
> their version numbers bumped to the current gnome version. This way it
> is clearer to users that of all the gnome-desktop apps they run the
> latest version.

Yes, it would be much handier for many people (including the release
team, or at least me).  This is a basic guideline, combined with
others it is written out as http://developer.gnome.org/gep/gep-4.html.
 This GEP was written before my time, but I'm guessing it was probably
too hard to make it a strict requirement at the time, and I think it
probably still is now, but it doesn't hurt to ask individual app
authors if they'd be willing to switch version numbering.  It seems a
few more do so every release or so.  (e.g. ORBit recently was made to
match, gdm will do so soon...)

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

Re: When will Topaz development begin?

[Elijah Newren]

On 9/11/05, Jono Bacon <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> This may sound a rather simplistic question, and I fully acknowledge
> that there may not actually be an answer, but has there been any
> targetted timeframes for when Topaz hacking will begin?

No.

> I realise that Topaz is currently in the ideas stage, but how will the
> finalised ideas and direction for Topaz be decided?

Your guess is as good as any.  (No point in working on it unless we
know what 'it' is and why we even want/need to do it)

My guess is that someone will go off and do something cool, we'll want
to incorporate it, and it'll be a big enough shift that we want a new
name (and as long as I'm taking wild guesses, here's another: it won't
require a 3.x versioning and despite us staying with the 2.x line, we
won't come up with any good names and just call it Topaz anyway)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [EMAIL PROTECTED]

[Elijah Newren]

On 9/11/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> It doesn't exist. I think a metacity-list would be really really
> useful. Pretty please? :)

As Havoc, said, I think the big question is finding out what problems
this would address or what new advantages it would bring.  I believe
there may be things that we should address, but I'm not sure yet if a
mailing list is what we need (a wiki page, an extra file in CVS with a
little more info, or other solutions may work).  If it is though, I'd
like to avoid the "annoying discussions" that could easily happen[1].

Your question did make me think about potential problems, though. 
Besides sucking at reviewing patches[2], I did think of one other
potential problem (please let me know if there are others).  We're not
doing very well about communicating what is being worked on and
why[3], which makes it a little harder for potential contributors
trying to find their way around.  Yet it looks like we may
(hopefully!) be gaining more and more contributors[4].  Some way of
sharing this information better may help this group.

Thanks for your work on Metacity, btw.

Cheers,
Elijah

[1] Perhaps this could be done by calling it metacity-devel-list and
limiting it to stuff that didn't fit into bugzilla (e.g. roadmap,
who's working on what, what the development branches are for,
questions about how certain parts of the code work by those who are
trying to certain bugs, etc.)

[2] Such as with bug 314977 and bug 170475 from you--both of which
looked fine at quick glance, btw, though I didn't have time to test or
look closer yet.

[3] For example, the spiffifity branch was created and was being
worked on without me even knowing until after the fact (though Havoc
did tell me soon after in email).  Similar thing happened with the
constraints_experiments branch that was created recently, though this
time I was the one doing the creating.  There's also been emails I
sent Havoc asking for details about how certain parts of the code
worked or bouncing preliminary ideas off him that could have
potentially helped others.

[4] Those who have contributed at least some and have said or somehow
hinted to me that they plan to work more on Metacity include you, Ray
Strode, Brent Smith, Billy Biggs, Aidan Delaney, Jaap Haitsma, Dave
Ahlswede, Soeren, Rob, Havoc (does the maintainer count as a
contributor?), me, and probably others I missed. Granted, we still
have periods with lower amounts of development and maintenance since
none of us are super active, and some on that list may not still be
interested, but it does seem like it's growing and getting better
overall.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [EMAIL PROTECTED]

[Elijah Newren]

On 9/11/05, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> If there are topics that really need a list, they are on topic for
> desktop-devel-list, usability list, and other gnome lists. I don't think
> we need a metacity list until the metacity-specific content becomes a
> significant amount of traffic on the main gnome lists, no?

Well, there's been cases before where I've claimed that it wasn't on
topic for d-d-l[1] and people may be afraid because of that.  ;-)

Cheers,
Elijah

[1] We scare too many developers away from d-d-l due to email volume
and single-product-specific emails seemed like an easy candidate for
moving elsewhere.  (I left my responses here, though, because the
question has come up before, it looks like Bjorn is trying to get more
involved, and I have the feeling that we might be making things
difficult without realizing it and wanted to get feedback from him as
well as others on what those problems might be)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Preliminary Gnome 2.14 Schedule

[Elijah Newren]

So, it's time to hammer out a schedule for the 2.14 release (and 2.12
point releases) and cover a couple closely related issues.  I've put
together a preliminary schedule, based on moving the 2.11 schedule
forward 6 months (with a slight change).

There are some specific issues I'd like to address:

  - In past releases, we did not specify an exact time when tarballs
were due nor when
freezes began.  This ended up causing some misunderstandings, cut
down on testing
time, and made it harder for release-oriented projects (e.g. live
cd, garnome).  So I'd like
to make this precise.
  - Having feature freeze two weeks after Christmas last year caused
some complaints.  To
avoid something like that, we need to extend the schedule by a
week, shorten it by at
least 3 weeks, or do something even more drastic.
  - We didn't list any point releases other than 2.10.1 last time
(though we did get a 2.10.2
release out--Kjartan just surprised us when he was ready ;-)

The specific solutions I'm proposing are:

  - Tarballs are due by 23:59 UTC on the Monday specified
  - Freezes begin by 23:59 UTC on the Monday specified
  - Extend the schedule by one week to push feature freeze back
  - Put 2.12.1, 2.12.2, and 2.12.3 on the schedule

Some statistics about the proposed calendar, comparisons to previous
release cycles, and the proposed calendar are as follows:

  + Number of weeks development between each release:

  2.12.x Series |  2.13.x/2.14.0 Series
 --+
  2.12.1: 4  weeks  |  2.13.1:   7 weeks
  2.12.2: 8  weeks  |  2.13.2:   3 weeks
  2.12.3: 10 weeks  |  2.13.3:   4 weeks
|  2.13.4:   3 weeks
|  2.13.5:   2 weeks
|  Beta 1:   2 weeks
|  Beta 2:   2 weeks
|  RC1:  2 weeks
|  2.10.0:   2 weeks

  + Number of weeks between each freeze compared with other development
cycles - the numbers in parenthesis are the hard freeze dates where
there are slushy freezes.

| 2.13.x | 2.11.x | 2.9.x  | 2.7.x  | 2.5.x  | 2.3.x
++++++---
API/ABI FREEZE  | 14(19) | 18 | 14(17) | 14(17) | 13 | 18
FEATURE/MOD. FREEZE | 19 | 18 | 17 | 17 | 18 | 18
UI FREEZE   | 17(21) | 16(20) | 17(19) | 17(19) | 18(22) | 26(22)
STRING FREEZE   | 17(23) | 16(22) | 17(21) | 17(21) | 18(22) | 26
CODE FREEZE | 26 | 25 | 23 | 23 | 26 | 29
FINAL RELEASE   | 27 | 26 | 25 | 25 | 28 | 31

   + Proposed calendar:

 Wk  September 2005
  Su Mo Tu We Th Fr Sa
   1  2  3
   4 (5) 6 (7) 8  9 10   RELEASE: GNOME 2.12.0
  1   11 12 13 14 15 16 17
  2   18 19 20 21 22 23 24
  3   25 26 27 28 29 30

  October 2005
  Su Mo Tu We Th Fr Sa
 1
  42 (3) 4 (5) 6  7  8   RELEASE: GNOME 2.12.1
  59 10 11 12 13 14 15   [GNOME SUMMIT, 8-10]
  6   16 17 18 19 20 21 22
  7   23(24)25(26)27 28 29   RELEASE: GNOME 2.13.1 [new mod. proposal start]
  8   30 31

  November 2005
  Su Mo Tu We Th Fr Sa
 1  2  3  4  5
  96  7  8  9 10 11 12
 10   13(14)15(16)17 18 19   RELEASE: GNOME 2.13.2
 11   20 21 22 23 24 25 26
 12   27(28)29(30)   RELEASE: GNOME 2.12.2

  December 2005
  Su Mo Tu We Th Fr Sa
   1  2  3
 134  5  6  7  8  9 10
 14   11(12)13(14)15 16 17   RELEASE: GNOME 2.13.3
 15   18 19 20 21 22 23 24
 16   25 26 27 28 29 30 31

  January 2006
  Su Mo Tu We Th Fr Sa
 171 (2) 3 (4) 5  6  7   RELEASE: GNOME 2.13.4 [String, UI change ann.]
 188  9 10 11 12 13 14 
 19   15(16)17(18)19 20 21   RELEASE: GNOME 2.13.5 [API/feat./mod. freeze]
 20   22 23 24 25 26 27 28
 21   29(30)31   RELEASE: GNOME 2.14.0 Beta 1 [UI Freeze]

  February 2006
  Su Mo Tu We Th Fr Sa
   (1) 2  3  4
 225 (6) 7 (8) 9 10 11   RELEASE: GNOME 2.12.3
 23   12(13)14(15)16 17 18   RELEASE: GNOME 2.14.0 Beta 2 [String freeze]
 24   19 20 21 22 23 24 25
 25   26(27)28

   March 2006
  Su Mo Tu We Th Fr Sa
   (1) 2  3  4   RELEASE: GNOME 2.14.0 RC 1   
 265  6  7  8  9 10 11  [Hard code freeze]
 27   12(13)14(15)16 17 18   RELEASE: GNOME 2.14.0! [End hard code freeze]
 28   19 20 21 22 23 24 25
 29   26 27 28 29 30 31

   April 2006
  Su Mo Tu We Th Fr Sa
 1
 302  3  4  5  6  7  8
 319(10)11(12)13 14 15   RELEASE: GNOME 2.14.1
  16 17 18 19 20 21 22
  23 24 25 26 27 28 29
  30


So...comments?  Complaints?  Issues?  Gossip?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-d

Re: Preliminary Gnome 2.14 Schedule

[Elijah Newren]

Sorry for the slow response...

On 9/14/05, Danilo Šegan <[EMAIL PROTECTED]> wrote:
> Today at 7:42, Elijah Newren wrote:
> 
> > The specific solutions I'm proposing are:
> >
> >   - Tarballs are due by 23:59 UTC on the Monday specified
> 
> Can we also add a general guideline as to *earliest* when tarballs
> should be rolled out?  I know we can't be too strict on this one
> (every now and then there will be a couple of exceptions; for some we
> will be using very old tarballs such as previous Gnome releases), but
> I believe documentation and translation projects would benefit from
> having exact date until they can work on something while being sure
> that their work will end up in the release.

> Asking for a simple "notify gnome-i18n, gnome-doc-list if you are
> releasing early" (just like Rich did with gcalctool in this round)
> would be a great help as well.

I like the general idea of this, but I'm worried about adding too many
strict deadlines all at once.  Also, we may find the
too-early-to-release time needs to be adjusted (e.g. 3 days instead of
2 or whatever) after we've tried it out.  And, well...we currently
don't have a way of flagging release-too-early modules, just
release-too-late ones.  ;-)

How about we make it a non-binding guideline[1] for 2.14 (which
appears at the end of the release-dates page as a reminder), and then
make it a little more strict for the next cycle after we've tried it
out and have a better idea what the right timing is (and have some
scripts and stuff to assist with it)?  Sound reasonable?

Thanks,
Elijah

[1] Basically meaning that we can still contact module authors that
don't follow it and ask them nicely if they'll be able to notify the
right people and/or release within the right window in the future. 
This is different from the strict release-too-late deadline where
modules that miss it can be appear on public
didn't-make-the-deadline-and-were-not-included-in-the-specific-release
list.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Preliminary Gnome 2.14 Schedule

[Elijah Newren]

On 9/13/05, Elijah Newren <[EMAIL PROTECTED]> wrote:
> So, it's time to hammer out a schedule for the 2.14 release

So, we've just had some clarifications and an additional request so
far...no other complaints?  Is this schedule fine?  Hurry and speak up
if it's not.  :-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: cdda:// URIs and the default handler

[Elijah Newren]

On 9/22/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-09-21 at 19:36 -0500, Federico Mena Quintero wrote:
> > On Wed, 2005-09-21 at 09:38 +0200, Alexander Larsson wrote:
> >
> > > I'm not sure where we should ship the script (or perhaps a c-based
> > > version of it) though. In gnome-vfs? If its in gnome-volume-manager then
> > > people with g-v-m not installed will get the bizarre cdda:// error
> > > message, which is pretty bad. If we want the script to have e.g. warning
> > > dialogs then it needs to link to gtk+ though, which isn't very nice for
> > > gnome-vfs. Maybe libgnomeui?
> >
> > I'd rather not scatter this particular piece any more - having two
> > barely-matching pieces in gnome-vfs and g-v-m is bad enough.
> >
> > Do we care about people who run gnome-vfs but don't run g-v-m?
>
> Is g-v-m part of the desktop these days?

Yes, it is part of the desktop[1] since Gnome 2.7[2].

Cheers,
Elijah

[1] http://live.gnome.org/ReleasePlanning_2fTwoPointEleven_2fDesktop
[2] http://www.gnome.org/start/2.7/desktop/,
http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00367.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Successful built of Gnome 2.12 with Jhbuild on FC4? Anyone?

[Elijah Newren]

On 9/22/05, Ali Sobhi <[EMAIL PROTECTED]> wrote:
> Seems like the list "gnome-build-status" is not active (last posting June
> 2005). So I'm posting this note to this list.

gnome-love would be a better list to try on.

> I've been trying to build Gnome 2.12 using jhbuild on a Fedora Core 4.

Are you building from tarballs with jhbuild or from cvs?  (If you
don't know, the answer is cvs)  If from cvs, realize that it's
possible the jhbuild moduleset hasn't kept up with the branching
(especially if you have been trying to get the build to work over a
longer period of time and haven't manually updated your jhbuild
checkout).

> After going at it several rounds and opening defects for build failures
> for iso-codes, evolution-data-server, evolution-exchange and reopening few

I've just skipped evolution-exchange as I don't have any way to test
it anyway (it's just for allowing evolution to connect to Windows mail
servers, and I don't have access to any)...

> older ones I'm still unable to have good clean build.
> This is despite my own home brewed patches for mozilla, memprof,
> gst-plugins (which made them be built).

> So the question is: Can  Gnome 2.12 be built completely and successfully
> on Fedora Core 4 using jhbuild on an Intel-32 machine?
> :(

I would be _really_ surprised if it couldn't, though I haven't tried
out that exact version myself yet.  (I have built it on RHEL4,
CentOS4, and at least a beta build on FC3, all of which ought to be
fairly close to FC4).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [EMAIL PROTECTED]

[Elijah Newren]

On 9/13/05, Benjamin Kahn <[EMAIL PROTECTED]> wrote:
> Havoc,
>
> For some reason, this sounds suspiciously like a semi-moderated list
> to me.  Known contributors could post without moderation, but others have
> posting access only if the moderator approves the message.  Contributer
> only lists suck (IMO) because the whole point is to allow outside people
> to bring up interesting topics on occasion.

Yep, done (metacity-devel-list).

> Anyway, then the question simply becomes: who would be the
> moderator of such a list?

Me.

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

2.14 schedule is up

[Elijah Newren]

Hey all,

The schedule towards 2.14 (plus 2.12 stable releases) is now up at
http://live.gnome.org/TwoPointThirteen[1].  Note that 2.12.1 is coming
up in less than a week with 2.13.x releases starting in just under a
month!

- The release team

[1] Or from http://www.gnome.org/start/unstable for those that want a
permanent whatever-the-current-development-version-is link for the
developement schedule.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Eel and Nautilus branched

[Elijah Newren]

On 10/3/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> Eel and Nautilus has been branched for 2.13. 2.12.x work go in the
> gnome-2-12 branch.

Don't forget gnome-doc-list.  :-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-vfs branched

[Elijah Newren]

On 10/3/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> Gnome-vfs has branched for 2.13. Work for 2.12 goes in the gnome-2-12
> branch.

Don't forget gnome-doc-list...  ;-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Metacity branched

[Elijah Newren]

Metacity has branched.  gnome-2-12 is now the stable branch, and
not-as-stable stuff will go in on HEAD (or the spiffifity or
constraints_experiments branches...)

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

Re: gnome-utils patch

[Elijah Newren]

On 10/4/05, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> Hi
>
> Just found out a missing argument in a call to g_snprintf, in logview.
> Attached patch fixes it.
>
> Ok to commit?

Is bugzilla not working?  ;-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-utils patch

[Elijah Newren]

On 10/4/05, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> I guess it is, but usually it is much quicker to send the patch
> directly, and when that doesn't work, add it to bugzilla :)

Well, I guess there's a number of poeple that do this but to me it
sounds like a scary slippery slope that could lead to things getting
out of hand, especially with this statement of yours (just imagine if
everyone starts bypassing bugzilla and posts all patches to
d-d-l--you've suggested that it's effective in some sense or another).
 Of course, I'm just one of the jerks that thinks d-d-l volume is way
too high...  ;-)  Seriously, though, I'd personally prefer if d-d-l
was used for discussions that can't be contained to a single module.

Just my $0.02,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-utils patch

[Elijah Newren]

On 10/4/05, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-10-04 at 16:42 -0600, Elijah Newren wrote:
> > On 10/4/05, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> > > I guess it is, but usually it is much quicker to send the patch
> > > directly, and when that doesn't work, add it to bugzilla :)
> >
> > Well, I guess there's a number of poeple that do this but to me it
> > sounds like a scary slippery slope that could lead to things getting
> > out of hand, especially with this statement of yours (just imagine if
> > everyone starts bypassing bugzilla and posts all patches to
> > d-d-l--you've suggested that it's effective in some sense or another).
> >
> I did it this way, because for years, in the Evolution team, we found
> out patches got lost in Bugzilla, whereas having them sent to a list
> (evolution-patches@, not the main list), made them more visible to us,
> the developers. Of course, if that behaviour is not acceptable, I'll
> just submit my patches to bugzilla.
>
> I am not going to discuss whether that's a good idea or not, since we
> already had that discussion for Evolution for weeks, but in my
> experience, people tend to pay more attention to mailing lists than to
> bugzilla.
>
> Maybe we want a desktop-devel-patches@ list?

Yeah, it's definitely an issue that would be great to improve, whether
by creating mailing lists for each module, creating a
desktop-devel-patches@ list, listing the maintainers better, getting
better patch queries, having automated patch reminders from bugzilla
in some not-overwhelming-but-condensed way so that people actually
look at them, or whatever, it's something we should think about (Olav
and I have discussed a number of ideas on the bugzilla side of things
and I'll try to be helping him out with some of them sometime soon...)

> >  Of course, I'm just one of the jerks that thinks d-d-l volume is way
> > too high...  ;-)  Seriously, though, I'd personally prefer if d-d-l
> > was used for discussions that can't be contained to a single module.
> >
> yes, you are right. Maybe each project should have their own lists for
> this sort of things? In fact, some modules in GNOME CVS have no
> MAINTAINERS file, so it is very difficult to find out who are those
> maintainers, and thus the first thought is to send it to d-d-l, and thus
> its volume increases.

We're trying to at least keep the maintainers up to date on the wiki,
e.g. http://live.gnome.org/TwoPointThirteen/Desktop.  That is one
thing that may help you with things like this.  Olav and I have some
more ideas for improving bugzilla that may help with this as well, and
I intend to help with it soon...

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

Opportunity for participation in Gnome releases

[Elijah Newren]

Gnome releases have always been a community process, but the release
team is trying to find ways to also broaden the involvement for some
of the handful of tasks traditionally handled by release team members
(this is somewhat of a continuing process; we've been doing this
before and this effort is, in some sense, just another push in that
direction).  If you browse on over to
http://live.gnome.org/ReleasePlanning/Tasks you'll see the main tasks
that the release team needs to ensure are take care of.  We don't know
how to broaden the involvement for all the tasks, but there are some
obvious candidates:

 - Creating an ical file for the 2.13 release cycle
 - Writing release notes; in particular Murray has signalled in his
   blog that he would like others in the community to take charge of
   this.
 - Various bug/patch nagging; this mainly means showstopper bugs, but
   possibly also nagging about i18n bugs before string freeze, about
   accepted-commit_after_freeze bugs before freezes start again and
   other such things.
 - Smoketesting release sets; In particular, we'd like to make the
   jhbuild modulesets we generate available soon after tarballs are
   in and let others also build and test with them before the
   release.

If you'd like to get involved with any of these, please contact the
release-team and/or the individual whose name appears next to the task
on the http://live.gnome.org/ReleasePlanning/Tasks wiki page.

Thanks,
The Release Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

More general patch notification? [Was: Re: gnome-utils patch]

[Elijah Newren]

On 10/6/05, Colin Walters <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-10-05 at 00:50 +0200, Rodrigo Moya wrote:
>
> > Maybe we want a desktop-devel-patches@ list?
>
> Regardless of where the canonical place to store patches is (mailing
> list archive or Bugzilla), I think it is valuable to make it easy for
> groups of interested people to review incoming patches, even if they're
> not the official maintainer of the module or are actively tracking
> Bugzilla for that module.  More eyes spot problems more easily.
>
> Probably just need a Bugzilla hack where if a patch is attached to a bug
> (or an existing one is updated) it gets autosent to some mailing list.
> Digging about it's kind of like this:
> http://bugzilla.gnome.org/reports/patch-diligence-report.cgi
>
> Except we want to make it push instead of pull so to speak =)
>
> And we'd probably want to restrict it to modules in the official core so
> as to not drown in the noise; also people interested in other modules
> can just watch that module's bugs anyways.

Could you clarify some?  I'm hoping to find some time to work on patch
stuff in bugzilla in the coming months (if Olav doesn't beat me to
it--he's getting all kinds of bugzilla stuff done right now) and some
kind of auto-notification/reminder was already on my list; it'd make
sense to tackle something like this at the same time if I can.  So, a
few questions, for you and others that might be interested:

What kind of information is wanted?  Is it just a sheer number of
unreviewed patches and a percentage compared to total as found in the
patch-diligence-report you linked to?  Would it be more along the
lines of short patch descriptions?  Are corresponding bug #s (links?)
w/ priority, severity, product, or component wanted?  An updated
report sent out every N days with new patches, or emails sent out the
very instant a patch is attached (the former is easier, as we already
have the infrastructure for it; see
http://bugzilla.gnome.org/reports/patch-report.cgi?product=metacity&max_days=7
for which we also have a little front end at
http://bugzilla.gnome.org/reports/patch-status.cgi).

How is the information wanted?  A mailing list?  An RSS feed (The
former shouldn't be too hard to add.  We also have code that does the
latter for something else that could be used here; take a look at bugs
for beginners can be found at
http://bugzilla.gnome.org/reports/keyword-search.cgi?keyword=gnome-love
and the corresponding RSS feed at
http://bugzilla.gnome.org/reports/keyword-search-rss.cgi?keyword=gnome-love)

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

Re: [gnome-love] Re: Opportunity for participation in Gnome releases

[Elijah Newren]

On 10/6/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 10/6/05, Murray Cumming <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > Just a thought -
> > >  A web calendar hosted by the release team would be useful to push
> > > new/modified notifications, marginally scoring over the ical file.
> > [snip]
> >
> > Is this just a matter of hosting the .ical file on our http server?
>
> We used to have one on gnome.org/start/ - should still be in CVS.

Yes, 
http://cvs.gnome.org/viewcvs/gnomeweb-wml/www.gnome.org/start/2.9/schedule.ics?rev=1.1&view=log,
for example.  I guess we could make a 2.13 directory, stick the ical
file there, and then link to it from
http://live.gnome.org/TwoPointThirteen.  But doesn't the wiki have a
way to upload small files directly?  If so, wouldn't it be easier to
do that?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Updated and non-updated modules in 2.12.1; releasing modules late

[Elijah Newren]

So, it looks like releasing modules late is going to be a habit that
will be hard to break for quite a few people.  ;-) Anyway, this is
mainly a reminder that if you can't make the deadline for some reason,
let the release-team know so that we can help you out.  If a last
minute critical issue comes up requiring an additional
after-the-deadline release of your module, please contact us.

Jeff was working on an automated way of tracking modules that have
been updated or not, but until that's up and running here's the brute
force method for encouraging everyone to make their releases.  :)

Modules updated from 2.12.0 to 2.12.1:
glib  2.8.1  2.8.3
gnome-vfs 2.12.0 2.12.1.1
gtk+  2.8.3  2.8.6
libxml2   2.6.21 2.6.22
pango 1.10.0 1.10.1
bug-buddy 2.12.0 2.12.1
control-center2.12.0 2.12.1
eel   2.12.0 2.12.1
epiphany  1.8.0  1.8.2
evolution 2.4.0  2.4.1
evolution-data-server 1.4.0  1.4.1
evolution-exchange2.4.0  2.4.1
evolution-webcal  2.4.0.12.4.1
file-roller   2.12.0 2.12.1
gedit 2.12.0 2.12.1
gnome-backgrounds 2.12.0 2.12.1
gnome-desktop 2.12.0 2.12.1
gnome-doc-utils   0.4.0  0.4.2
gnome-games   2.12.0 2.12.1
gnome-icon-theme  2.12.0 2.12.1
gnome-keyring 0.4.4  0.4.5
gnome-nettool 1.4.0  1.4.1
gnome-panel   2.12.0 2.12.1
gnome-speech  0.3.7  0.3.8
gnome-system-monitor  2.12.0 2.12.1
gnome-themes  2.12.0 2.12.1
gnopernicus   0.11.6 0.11.7
gtkhtml   3.8.0  3.8.1
gtksourceview 1.4.1  1.4.2
gucharmap 1.4.3  1.4.4
libgnomeprint 2.11.0 2.12.1
libgnomeprintui   2.11.0 2.12.1
librsvg   2.11.1 2.12.4
libwnck   2.12.0 2.12.1
metacity  2.12.0 2.12.1
nautilus  2.12.0 2.12.1
nautilus-cd-burner2.12.0 2.12.1
sound-juicer  2.12.0 2.12.2
yelp  2.12.0 2.12.1
zenity2.12.0 2.12.1
Glib  1.100  1.101
gnome-python  2.12.0 2.12.1
Gtk2  1.100  1.101
libxml++  2.11.0 2.12.0

Modules not updated from 2.12.0 to 2.12.1:
atk   1.10.3 1.10.3
at-spi1.6.6  1.6.6
audiofile 0.2.6  0.2.6
esound0.2.36 0.2.36
gail  1.8.5  1.8.5
GConf 2.12.0 2.12.0
gnome-mime-data   2.4.2  2.4.2
gtk-doc   1.41.4
intltool  0.34.1 0.34.1
libart_lgpl   2.3.17 2.3.17
libbonobo 2.10.1 2.10.1
libbonoboui   2.10.1 2.10.1
libglade  2.5.1  2.5.1
libgnome  2.12.0.1   2.12.0.1
libgnomecanvas2.12.0 2.12.0
libgnomeui2.12.0 2.12.0
libIDL0.8.6  0.8.6
libxslt   1.1.15 1.1.15
ORBit22.12.4 2.12.4
pkg-config0.19   0.19
dasher3.2.18 3.2.18
eog   2.12.0 2.12.0
evince0.4.0  0.4.0
gcalctool 5.6.31 5.6.31
gconf-editor  2.12.0 2.12.0
gdm   2.8.0.42.8.0.4
gnome2-user-docs  2.8.1  2.8.1
gnome-applets 2.12.0 2.12.0
gnome-keyring-manager 2.12.0 2.12.0
gnome-mag 0.12.1 0.12.1
gnome-media   2.12.0 2.12.0
gnomemeeting  1.2.2  1.2.2
gnome-menus   2.12.0 2.12.0
gnome-netstatus   2.12.0 2.12.0
gnome-session 2.12.0 2.12.0
gnome-system-tools1.4.0  1.4.0
gnome-terminal2.12.0 2.12.0
gnome-utils   2.12.0 2.12.0
gnome-volume-manager  1.5.1  1.5.1
gok   1.0.5  1.0.5
gst-plugins   0.8.11 0.8.11
gstreamer 0.8.11 0.8.11
gtk-engines   2.6.5  2.6.5
libgail-gnome 1.1.1  1.1.1
libgtop   2.12.0 2.12.0
libsoup   2.2.6.12.2.6.1
libxklavier   2.02.0
scrollkeeper  0.3.14 0.3.14
startup-notification  0.80.8
system-tools-backends 1.4.0  1.4.0
totem 1.2.0  1.2.0
vino  2.12.0 2.12.0
vte   0.11.150.11.15
gconfmm   2.12.0 2.12.0
glibmm2.8.0  2.8.0
Gn

Re: do we really need xrdb?

[Elijah Newren]

On 10/17/05, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> Hi
>
> One of the best improvements we've seen while working on speeding up the
> GNOME startup time has been the removal of the xsettings thing, via xrdb
> -merge execution.

It was also one of the things identified by Lorenzo as providing a
significant boost in speed-up time, discussed in the thread started at
http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00245.html.
 I'm hoping we can remove it, although Lorenzo also pointed out that
we could achieve the same benefit by just calling xrdb with the -nocpp
switch 
(http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00266.html)
-- something that would most likely work for 99% of the users of any
of the apps you have in your list below.

> Ben Kahn came up with a list of apps that still need this:
>
> acroread 5
> Emacs
> Anything written in Tk (aMSN, crossover office, much corporate custom
> software)
> Anything written in Motif (slowly being replaced, but still a lot of
> software)
> Anything written in XForms (oddly, a lot of scientific software...)
> Apps that ship with the X server: xterm, xedit, xclock, etc.
>
> Anything else?
>
> So, do we really want to keep around the xrdb thing in
> gnome-settings-daemon?

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

Re: Keyboard usage on some Gnome windows not working

[Elijah Newren]

On 10/20/05, Shaun McCance <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-10-20 at 08:49 -0200, Matthew Thomas wrote:
> > No, there aren't. 
> >
> > I see there is some research showing that the keyboard is faster for
> > common commands
> >  > publication_id=1508&lang=en>, but that wouldn't include access keys
> > unless you were encountering particular dialogs or alerts very often.

> When Tog says "The stopwatch consistently proves mousing is
> faster than keyboarding." I'm curious what he means.  I'd
> really like to see what tests were performed and what the
> actual results were, rather than a one-line synopsis.  As
> a mathematician, I'm suspicious of pretty much any one-line
> statistical synopsis.  Imagine this test:

Agreed, I thought the AskTog article was being overused and
mis-applied in a number of cases, so I at one point went and read
through the relevant article pretty closely, plus related ones and
comments.  Unfortunately, it's been a long time, but from what I
recall, the tests were done in the 80's or so and users were not yet
familiar with shortcut keys (i.e. no muscle memory to "bias" the
results).  In the explanations he provided for the mouse being faster
than the keyboard, he said the reasoning was something along the lines
of users need to do all kinds of shape recognition to recognize what
the hotkeys are (including finding which letter is underlined, I
presume) and then translate that into a letter, and then get their
fingers to strike the right key.

He did specifically say, perhaps in another article, that having
certain shortcuts would save time over the mouse for very common
operations (cut, copy, paste...; also, on a related note that I found
amusing, he argued that command-p should be reserved for making text
be plain (as opposed to bold or italic) instead of using the key for
printing on the grounds that computers were almost exclusively used as
word processors and making text plain was a far more common task...). 
Now, the big question is--how many have memorized the shortcut keys
for certain dialogs that appear?  Unless they show up often, users
probably haven't memorized them and thus using them for those dialogs
may actually be slower.

Also, another interesting tidbit: A number of years back, I went for
about 2 years without using emacs (or computers much at all, though
that's beside the point...).  It was kind of painful when I started
using emacs again, because I couldn't recall what any of the necessary
shortcuts were and didn't have a nearby listing of them.  If someone
asked me how to save my document, I would not have been able to tell
them what the key sequence was.  But, I started typing along anyway
and at some point, nearly out of habit (I guess I don't trust autosave
and have developed this habit of hitting the save sequence early and
often), I found myself pushing my fingers down in a certain pattern
that I hadn't forgotten--I quickly pressed the lower left key on the
keyboard with my pinky and held it down and pressed two keys in
succession with my index finger of the same hand.  The sequence I
happened to type was Ctrl-X, Ctrl-S.  I then went "whoa, so that's how
you save, cool."  I had remembered where the keys were when I was in a
rhythm, but not what they were.  For the vast majority of the emacs
shortcuts, I had to go look them up and learn them again, but for this
one and a few others, I relearned them merely by using them in this
only-know-how-to-move-my-fingers when not really thinking about it.

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

Re: Proposal for inclusion in Desktop: pessulus

[Elijah Newren]

On 10/28/05, Pat Suwalski <[EMAIL PROTECTED]> wrote:
> Jeff Waugh wrote:
> >>Could we have a separate 'Administrator Tools' release set?  I suppose we
> >>could, but what would be the point?  We aren't categorizing any of our
> >>other modules.
> >
> > Which is a problem. I fully support the creation of an admin release suite.
>
> How would this look in terms of the release? The release would obviously
> coincide with the gnome-desktop release.

We already have 3 release sets (desktop, platform, and bindings), and
have discussed a fourth (productivity--gnumeric, abiword, etc.). 
Having an admin suite would just mean defining rules for it (probably
would be very similar to the desktop rules) and having modules
proposed for it

> The source tarballs would be in the same place.

Not quite; It'd be
http://ftp.gnome.org/pub/GNOME//$MAJMIN/$VERSION  
http://ftp.gnome.org/pub/GNOME/desktop/$MAJMIN/$VERSION

> So the only difference would be suggested grouping to indicate to
> distros how to categorize their packages and/or create a gnome-admin
> metapackage?

There may be different rules associated with the different sets, but
it is possible that it merely serves as a grouping.  Also worth note
is that there has been talk about trying to "franchise the release
process" (on r-t? d-d-l?  I don't remember anymore...) in order to try
to make our releases feel more inclusive.  (As people have pointed out
before, "Why aren't Inkspace, GIMP, AbiWord, etc. part of the
"official" "Gnome releases"?!?)

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

Re: Gnome 2.14 Module Proposal: Deskbar Applet

[Elijah Newren]

On 10/29/05, Raphael Slinckx <[EMAIL PROTECTED]> wrote:
> Ok, i like the approach of an expermiental gconf key to enable alt-f2
> replacement, maybe we can try to make that happen, it won't hurt
> anybody, and yet will allow to receive feedback from user who choose to
> activate it.
>
> A question though, wouldn't this require to disable alt-f2 if the
> specific key is found (by patching wherever alt-f2 lives, where ?) ?

Alt-F2 is a global metacity keybinding; when Metacity detects that
keypress, it sends a message to the root window that gnome-panel
monitors for; gnome-panel then launches the run application dialog.

One possibility (though I don't know how difficult this would be to
do) would be having gnome-panel detect if deskbar is running and
forward any open-run-dialog messages to it instead of what it normally
does; if deskbar isn't running, then gnome-panel could just launch the
normal dialog it has.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Making GNOME crash

[Elijah Newren]

On 11/6/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> As I said in IRC, I'm not terribly convinced we do a great job of
> fixing the crashes we already have, much less all the new crashes this
> will introduce. But I'm willing to be swayed by analysis of the
> incoming/outgoing crasher bug flow we currently have.

It might be easier to track and fix bugs given something closer to the
root cause than bugs that happen to be triggered later, though. 
Personally, I think it's worth a try; we can disable it if it causes
too many problems.

Just my $0.02,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Making GNOME crash

[Elijah Newren]

On 11/7/05, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote:
>   This could also mean that developers start thinking twice before
> adding a g_warning, and start using g_message instead, thus defeating is
> purpose.  g_warning is for reporting real problems, but no critical
> ones; for critical problems we have g_error.
>
>   It's so easy to turn on abort on warnings, just run your program with:
> $ G_DEBUG=all ./myprogram
> or even:
> $ ./myprogram --g-fatal-warnings
>
>   Only lazy developers let g_warnings go on indefinitely.  We need to
> educate developers, that's all.

I think you missed Vincent's original email (either that or I
misunderstood it).  I believe he was talking about making g_critical()
calls result in crashes, not g_warning() calls.  So these examples
don't do what was proposed, though they are close (just use
"G_DEBUG=fatal_criticals" instead of "G_DEBUG=all", if I understand
correctly).

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

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/11/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-11 at 12:20 -0500, David Malcolm wrote:
>
> > So here's a (possibly crazy) suggestion: during development releases,
> > enable a11y by default, and during stable releases, disable it by
> > default.  That way people running jhbuild, GARNOME etc would be running
> > all of the a11y code, and any bugs in that layer would be discovered
> > more quickly.
>
> Let's do it.
>
> On a few conditions:
>
> - You will write a short tutorial of how to write profiling scripts with
> Dogtail.
>
> - You will write a little bunch of Dogtail scripts that will help us
> profile particularly slow operations (opening the panel menu, doing
> stuff in Evolution)
>
> - Sun will write the dtrace scripts to figure out why/how enabling a11y
> is a performance problem for the desktop:  a11y does a lot of IPC, and
> profiling that is hard unless you have something like dtrace.
>
> All agreed? :)

FWIW, it effectively disables the reduced resources mode in metacity
(except that the minimization animation remains off) which would
result in part of Metacity being untested.  It may also drive users
mad from the constant slow keys and sticky keys dialogs that appear. 
(I know it shouldn't seem like common operations to press shift 5
times in a row or hold it down for over 8 seconds but I seem to
periodically do one or the other without thinking about it,
particularly the latter fairly often)

Those may not be big enough reason to avoid doing it, I'm just
pointing out things to consider.

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

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/11/05, Vincent Untz <[EMAIL PROTECTED]> wrote:
> > FWIW, it effectively disables the reduced resources mode in metacity
> > (except that the minimization animation remains off) which would
> > result in part of Metacity being untested.
>
> Is there any reason for this behavior?

It was done before I got involved with Metacity.  You'd have to ask
Bill, Havoc, or Rob, or maybe all three and hope that they all
remember enough pieces to get the whole answer.  I don't use
reduced_resources (except when trying to duplicate bugs and fix some
of them) and I don't use accessibility (with similar rare
exceptions...), so I really don't know.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/11/05, Claudio Saavedra <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-11 at 12:00 -0700, Elijah Newren wrote:
> [...]
> > FWIW, it effectively disables the reduced resources mode in metacity
> > (except that the minimization animation remains off) which would
> > result in part of Metacity being untested.  It may also drive users
> > mad from the constant slow keys and sticky keys dialogs that appear.
> > (I know it shouldn't seem like common operations to press shift 5
> > times in a row or hold it down for over 8 seconds but I seem to
> > periodically do one or the other without thinking about it,
> > particularly the latter fairly often)
>
> Considering that there are pros and cons, why force all developers,
> contributors and testers to take part in this? It would be good for the
> debugging of a specific part of the desktop, sure, but at a cost that
> probably not everyone wants to pay.

That sounds like "since there are tradeoffs, let's ignore the proposal
(and implicitly all the tradeoffs) and keep things as they are."  Why
not weigh the tradeoffs and determine which is the more sane default? 
In particular, it's not hard to manually turn accessibility off. 
There's even a little dialog for it.

If you don't like it on by default, please explain why the change
overall does more harm than good.

> Just like with the suggestion that Vicent made a few days ago regarding
> making GNOME crash. Instead of making this changes a *must* for all the
> people involved with the HEAD code, why not better making more noise
> (mailing lists, p.g.o, etc.) so everyone know that exists some areas of
> the desktop development that need some love?

Most developers may not trigger the critical warnings, or may not be
aware of them since they don't watch the terminal (or, even if they
do, they don't watch closely enough and the critical warnings get
drowned out by all the normal warnings).  Granted, work should be done
to get rid of any common ones before it's turned on, but I think
Vincent's proposal makes sense as a default at some point.  (However,
if it turns out that crashes aren't rare after turning it on, then of
course we'd need to turn it back off until we could fix stuff to the
point that they are more rare.)

Just my $0.02,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IMPORTANT: fix critical warnings before January 1st

[Elijah Newren]

On 11/11/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 11/11/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > Remember, on January 1st 2006 this change will happen automatically, and
> > things that have not been fixed will start crashing all over the place.
> > So fix them now.
>
> In the meantime, maybe someone can collect and post lists of them?
> [And maybe someone should create a keyword for them in bugzilla?]

Why a keyword over say the status whiteboard?  I don't imagine that
people will widely search for these after a couple months down the
road (i.e. when we've cleaned almost all of them out), meaning it
would just be keyword pollution.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/11/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-11 at 12:18 -0700, Elijah Newren wrote:
>
> > It was done before I got involved with Metacity.  You'd have to ask
> > Bill, Havoc, or Rob, or maybe all three and hope that they all
> > remember enough pieces to get the whole answer.  I don't use
> > reduced_resources (except when trying to duplicate bugs and fix some
> > of them) and I don't use accessibility (with similar rare
> > exceptions...), so I really don't know.
>
> So...
>
> - What does reduced_resources do?

Basically, (1) wireframe mode for moves/resizes instead of opaque
windows, and (2) no minimization animation.  (In other words, "crack"
as Havoc would say)

> - Does it really reduce resource consumption?  Of which resources?

Yes, applications don't need to repaint themselves until the
move/resize operation is over in the case of the wireframe
move/resize, and they don't need to worry about repainting themselves
at all when the ugly minimization animation puts black lines over it.


Note that I'm of the opinion that this accessibility vs. reduced
resources stuff is by no means important enough for keeping
accessibility turned off by default.  If it were one of dozens of
similar issues then it might be worth considering.  It's just that I'm
only familiar with metacity (well, and libwnck), so I thought I'd
point it out.  So far, it doesn't seem like others have pointed out
any similar issues, plus having someone turn off accessibility is
*really simple*, so I'm currently in favor of the
accessibility-on-by-default proposal.

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

Re: IMPORTANT: fix critical warnings before January 1st

[Elijah Newren]

[Dropping the devel-announce-list cc until we have an announcement
rather than discussion]

On 11/11/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 11/11/05, Elijah Newren <[EMAIL PROTECTED]> wrote:
> > Why a keyword over say the status whiteboard?  I don't imagine that
> > people will widely search for these after a couple months down the
> > road (i.e. when we've cleaned almost all of them out), meaning it
> > would just be keyword pollution.
>
> Point. What would the standard word be to use in the whiteboard?

I dunno.  Anyone have good suggestions?  "critical-warning-crasher" maybe?

Also, as an aside,
http://bugzilla.gnome.org/reports/boogle.cgi?query="-CRITICAL"; seems
to be fairly good at catching these as a first approximation, though
the lack of case sensitivity also catches places where people say
things like "non-critical".  It may be possible to generate a good
enough query without manually marking all the relevant bugs.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: IMPORTANT: fix critical warnings before January 1st

[Elijah Newren]

On 11/11/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 11/11/05, Elijah Newren <[EMAIL PROTECTED]> wrote:
> > I dunno.  Anyone have good suggestions?  "critical-warning-crasher" maybe?
> >
> > Also, as an aside,
> > http://bugzilla.gnome.org/reports/boogle.cgi?query="-CRITICAL"; seems
> > to be fairly good at catching these as a first approximation, though
> > the lack of case sensitivity also catches places where people say
> > things like "non-critical".  It may be possible to generate a good
> > enough query without manually marking all the relevant bugs.
>
> Oh, hrm, good point- I was assuming they'd be unqueryable.

Well, it's still not perfect (though I'm guessing an enhancement to
boogle or a manually crafted query could be much better).  Also, in
fact, my previous query only caught the cases where people printed the
warnings printed at the terminal.  If the user didn't do that but
instead just submitted a stack trace, the query would be more like
http://bugzilla.gnome.org/reports/boogle.cgi?query=G_LOG_LEVEL_CRITICAL
(which happens to be a really tiny list, at the moment)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: First weekly status report on GNOME Dictionary

[Elijah Newren]

Hi,

On 11/11/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> In order to let others know how's the status of GNOME Dictionary
> Breaking is progressing (and in order to force myself hacking on it
> regularly ;-)), I'm sending the
>
> Not So Weekly Status Report on GNOME Dictionary
>
> Containing the status of the review-slash-breaking-slash-rewrite process
> of the GNOME Dictionary application and applet.  Okay, it won't be
> weekly, and I could simply use my blog (see signature and link on
> Vincent's own blog) instead of email; nevertheless, having someone to
> report to makes room for public discussion, and since I'm breaking
> (mostly) working stuff better be sure that some discussion actually
> happens at all.

Sounds like awesome work.  I don't want to be discouraging, but please
consider that desktop-devel-list is better reserved for discussion
that crosses multiple modules than for discussing all aspects of
individual modules.  There are exceptions (e.g. branching
notification, since it affects i18n, bugsquad, and possibly
documentation and other groups), and not everyone totally agrees on
this rule, but this does appear to be the kind of thing that appears
contained to a single module and perhaps would be better discussed
elsewhere.  Blogging about it and/or gnome-utils-list would be
awesome.

Thanks for understanding.  I look forward to seeing a much improved
dictionary applet.  ;-)

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

Re: Should I propose sabayon?

[Elijah Newren]

On 11/14/05, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> I've been working a bit on Sabayon recently. See e.g. my blog entry:
> http://blogs.gnome.org/view/alexl/2005/11/07/0
>
> Now I'm thinking maybe I should propose it for inclusion into the gnome
> desktop. However, its really not a desktop app, but rather something for
> administrators of desktops, so it feels strange to propose it for
> desktop inclusion. Its a very interesting app though, and KDE get lots
> of credits for their Kiosktool, so its important that we have something
> in this area.
>
> I'm not sure what to do here. Should I propose it?

There has been mention of creating some kind of admin release suite,
but as long as one doesn't exist and isn't really even being worked
on, I think it's a good idea to go ahead an propose for the desktop
suite.  Maybe if/when an admin release suite is created, we can just
shift the appropriate modules over to the other release.

Just my $0.02,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libwnck branched for 2.12

[Elijah Newren]

On 11/14/05, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> libwnck has been branched for 2.12. The stable branch is gnome-2-12.
>
> There's no specific plans for HEAD, as far as I know. But maybe Elijah
> has some secret plans?

Uh, try to get Vincent to review the patches that Christian Neumair
has been politely pinging me to look at since I haven't had the time? 
;-)  (Sorry Chris, I know that I really suck...)  Actually, there is
an EWMH violation I'm aware of that will require an API addition, but
that should only affect a pair of other modules (which I'll write the
patch for) and users likely won't notice any differences.  Other than
those few things, bugfixes and reviewing other patches is all I have
planned this cycle.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Should I propose sabayon?

[Elijah Newren]

On 11/14/05, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> 
>
> > There has been mention of creating some kind of admin release suite, but
> > as long as one doesn't exist and isn't really even being worked on, I
> > think it's a good idea to go ahead an propose for the desktop suite.
> > Maybe if/when an admin release suite is created, we can just shift the
> > appropriate modules over to the other release.
>
> ... hold on - what's stopping us creating the admin suite? We can do that!

laziness.  ;-)

But, uh, by all means feel free to head up the effort to get the new
release set created!  Go go go!  :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Should I propose sabayon?

[Elijah Newren]

On 11/14/05, Paul Drain <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-11-15 at 12:15 +1100, Jeff Waugh wrote:
> > 
> >
> > > There has been mention of creating some kind of admin release suite, but
> > > as long as one doesn't exist and isn't really even being worked on, I
> > > think it's a good idea to go ahead an propose for the desktop suite.
> > > Maybe if/when an admin release suite is created, we can just shift the
> > > appropriate modules over to the other release.
> >
> > ... hold on - what's stopping us creating the admin suite? We can do that!
>
> "Desktop, Admin and Platform" Release does actually have quite a nice
> ring to it, too.

Yeah, but you'd have to kill the bindings release (not an option) in
order to get that nice ring.  Instead, it's "Desktop, Bindings, Admin,
and Platform" or some permutation thereof.  Luckily, "has a nice ring"
isn't a requirement.  ;-)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Building the admin suite (was Re: Should I propose sabayon?)

[Elijah Newren]

On 11/14/05, Vincent Untz <[EMAIL PROTECTED]> wrote:
> Le lundi 14 novembre 2005 à 22:10 -0700, Elijah Newren a écrit :
> > On 11/14/05, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > > 
> > >
> > > > There has been mention of creating some kind of admin release suite, but
> > > > as long as one doesn't exist and isn't really even being worked on, I
> > > > think it's a good idea to go ahead an propose for the desktop suite.
> > > > Maybe if/when an admin release suite is created, we can just shift the
> > > > appropriate modules over to the other release.
> > >
> > > ... hold on - what's stopping us creating the admin suite? We can do that!
> >
> > laziness.  ;-)
> >
> > But, uh, by all means feel free to head up the effort to get the new
> > release set created!  Go go go!  :)
>
> So, let's do it if pessulus or sabayon (or both) is/are accepted.

We'd need to come up with a set of rules for the admin release set
too, along the lines of http://developer.gnome.org/gep/gep-10.html,
http://developer.gnome.org/dotplan/api_rules.html, or
http://developer.gnome.org/dotplan/bindings/rules.html (except that
I'm not fond of the discoverability of the first nor that it's kind of
out-of-date and incomplete, and the other two only touch on a subset
of the rules for the modules).

(I'm guessing the rules for the admin set are "nearly identical to the
desktop rules, the exception being that modules need to be admin
oriented for inclusion")

As an aside, I'd really love to have a maintainer-oriented version
(i.e. a succinct version) of the rules for each set that just quickly
list the requirements of each.  This would include stuff like which
freezes apply (API/ABI isn't applicable to desktop despite the common
misconception to the contrary, though recent efforts have tried to
change that a little for libraries in the desktop; also, it has
slightly different meaning for platform and bindings), dependency
issues (which bindings are allowed to be used, hard and soft
dependencies and consensus, etc), making releases even if only
translations or documentation has changed, making use of Gnome
resources, and various other details.  I think it would have reduced
some of the confusion people have had in the past.  I've been meaning
to write it up and have an incomplete initial draft somewhere...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python bindings

[Elijah Newren]

On 11/15/05, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Alexander Larsson wrote:
> > I've been convinced that proposing Sabayon for inclusion is the right
> > thing to do. I'm also fully behind splitting it into an admin suite if
> > it gets accepted.
> >
> > So, I hereby propose Sabayon for inclusion into the Gnome 2.14 Desktop.
> > Information about sabayon is available at:
> > http://www.gnome.org/projects/sabayon/
> > and an example screencast at:
> > http://blogs.gnome.org/view/alexl/2005/11/07/0
>
> Since sabayon required pygtk, gnome-python (gconf) and pyorbit (for the
> applet) do they need to be proposed for inclusion separately?

Modules in the desktop are allowed to depend on the python bindings in
the bindings release set, as was agreed upon previously.  pyorbit is
not currently in that set.  If pyoribt isn't proposed, that may be a
reason to reject the inclusion of sabayon (unless, of course, it can
be made a soft dependency).  So this is yet another reason[1] someone
needs to make sure pyorbit is proposed.

Cheers,
Elijah

[1] http://mail.gnome.org/archives/release-team/2005-November/msg00058.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/15/05, Zack Cerza <[EMAIL PROTECTED]> wrote:
> Elijah Newren wrote:
> > It may also drive users
> > mad from the constant slow keys and sticky keys dialogs that appear.
> > (I know it shouldn't seem like common operations to press shift 5
> > times in a row or hold it down for over 8 seconds but I seem to
> > periodically do one or the other without thinking about it,
> > particularly the latter fairly often)
>
> This is actually a separate setting. Keyboard accessibility features are
> different from the general "assistive technology support". There's
> probably not a huge reason to enable the former by default.

Ah, right.  I forgot that I had to do something different to enable
the former (in order to test out a certain bug in bugzilla) and never
went back and disabled it.  Thanks for setting me straight.

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

Re: Denoting Remote Machines (Re: Custom Icons for GNOME Terminal Profiles)

[Elijah Newren]

On 11/19/05, Davyd Madeley <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-11-19 at 03:11 -0500, Havoc Pennington wrote:
> > On Sat, 2005-11-19 at 14:16 +0800, Davyd Madeley wrote:
> > > A feature like this might be interesting in Metacity. Same as
> > > Nautilus says "documents on floyd" it would be cool if Metacity
> > > could say "MGiva on charlie17". This would be particularly useful
> > > when you're running the same application on multiple cluster heads.
> >
> > On an LTSP setup it'd look awful though... and for terminals it's kind
> > of misleading (don't most people set the host they are ssh'd to in the
> > titlebar via bash, not the host the terminal is running on...)
>
> If you're X forwarding an entire session then it wouldn't make a lot of
> sense. I would suggest that it would only be shown if the name of the
> client is different to the name of the machine that Metacity is running
> on (which is often the same machine as the Xserver, it may not be on
> some LTSP and X-terminal setups).

Well, that would definitely mean no change for normal desktop setups
(i.e. everything-runs-locally) and I'm guessing it would also mean no
change for LTSP setups; both of which are good things.  It would seem
to make sense for the mix-and-match case (that I occasionally run
too), so it may be worth trying.

> The idea is not to tell someone where they are logged in to, but what
> machine their remote X window is running on. So if you're running xterm
> on charlie2 but logged into charlie17 you would see "XTerm:
> [EMAIL PROTECTED]:~ (on charlie2)".

Though that would seem fairly unusual, to me at least.  Most people
would probably run the xterm from the machine they are logged into and
then ssh into the machine they want to get to--and by your suggestion,
that case wouldn't cause the title of the terminal to be any different
than it is now, which I think is good.

> Something to consider is how we find out the hostname of the X-client if
> they're X-forwarding of ssh.

Via the WM_CLIENT_MACHINE property (which is stored in Metacity, not
too surprisingly, as the wm_client_machine field in the MetaWindow
struct if you want to take a look at the code).  This property in
combination with the _NET_WM_PID property is currently used in order
for the WM to offer the user the opportunity to kill unresponsive
windows.

If you want to try to code this up, take a look at
metacity/src/delete.c:meta_window_kill() for detecting windows which
run on the same host as metacity, and at
metacity/src/window-props.c:set_window_title() for how to modify the
window title (you may also want to look at set_icon_title() in the
same function if you want the title when iconified to be modified in
the same way).

You can find descriptions of WM_CLIENT_MACHINE (which is actually an
ICCCM property), _NET_WM_PID, _NET_WM_VISIBLE_NAME, and other EWMH
properties at http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html.

Anyway, feel free to have a shot at it if you like.  It seems to me
like it'd probably make sense, but Havoc would be the one that you
need to convince whether this feature is going to be 'right' or not. 
Either way, it might be a fun little coding exercise.

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

Re: gruler

[Elijah Newren]

On 11/21/05, Kalle Vahlman <[EMAIL PROTECTED]> wrote:
> 2005/11/21, Davyd Madeley <[EMAIL PROTECTED]>:
> > >From the whackarse bug reports we get at work:
> >
> > It can be very hard to line a series of windows up vertically, with the
> > top and bottom edges in line. This is a thing that people viewing
> > seismic data apparently want to do quite often.
>
> While it doesn't apply to resizing (why not?), moving windows with the
> shift key pressed does snap to window edges etc with Metacity.

Someone doesn't have an up-to-date system.  ;-)  That was a bug fixed
in metacity-2.13.2, namely bug 86644.

> It's really handy, even if it's only a part of the solution.
>
> If there's no particluar reason why it doesn't work with resize, I'd
> like to see it enabled there too.

It has been.  Please update to head.  Note that edge-resistance (as
opposed to auto-snapping) for normal moves and resizes has also been
added.

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

Re: Enable accessibility by default in development releases?

[Elijah Newren]

On 11/23/05, Padraig O'Briain <[EMAIL PROTECTED]> wrote:
> The problem seems to be that the function vte_terminal_process_incoming
> causes the "text-inserted" signal to be emitted for what seems like
> every character.
>
> The attached patch cauwes about 6% degradation when cat'ing a large file
> in gnome-terminal with accessibility enabled.

6% more degradation?  Or do you mean that it improves the performance
to the point where accessibility-enabled gnome-terminal only has 6%
degradation relative to the performance of gnome-terminal without
accessibility enabled?

> It would be useful to know whether it has any impact on the accessibility
> of gnome-terminal.
>
> Padraig

Actually, stuff like this makes me wonder if it's an additional reason
to turn accessibility on rather than a reason to keep it off.  It'll
help us find other little performance problems.  ;-)

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

Re: Reminder: fix critical warnings before Jan. 1st

[Elijah Newren]

On 12/5/05, Kjartan Maraas <[EMAIL PROTECTED]> wrote:
> man, 05,.12.2005 kl. 18.51 -0500, skrev Luis Villa:
> > On 12/5/05, Federico Mena Quintero <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > This is a reminder to fix all critical warnings before January 1st.  On
> > > that day, users of gnome-session HEAD will get G_DEBUG=fatal_criticals
> > > turned on automatically.
> > >
> > > Let's find those bugs and kill them!
> >
> > link to bugzilla query?
> >
> Did we agree on a keyword or some whiteboard magic?

No, partially because I'm not sure if we need one.

>
> I've marked some "critical-warning" (whiteboard) now, but I guess the
> easiest way is to just search for "-CRITICAL" in comments. This gave 231
> hits for me.

Most of which were due to uses of phrases like "non-critical" (e.g.
Owen used that phrase in some of the mass-bug-change thingys).  A
better search would be G_LOG_LEVEL_CRITICAL, which appears in the
stack traces.  Would that be good enough, or are there bugs filed
about critical warnings that come without stack traces or that are
missing this word?

If we can use that, and we can use the fulltext search in
bugzilla-newer (which is waaay faster than searching comments in 
current bugzilla), then this'll be fairly quick.  I only get 6 bugs
with such a query.  Unfortunately, giving you the url right now
wouldn't help a whole lot since (a) it will change soon as
bugzilla-newer is under construction, and (b) bugzilla-newer only has
an old snapshot of the database anyway.  Can you wait a couple weeks
for the link to the bugzilla query?

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

Re: Bugzilla down for software upgrade on Sun 18 Dec 09.00 UTC

[Elijah Newren]

On 12/6/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> This is the thread where we all shout 'we're not worthy' at Olav over
> and over again. Thanks for doing hero's work on this- I've played with
> the -test stuff, and it will be a huge upgrade for all of us. Thanks!

Seconded; watching Olav work has been just amazing.  He's put a ton of
work into this over the last several months (and even got slowed down
when I tried to start helping out a couple weeks ago since he had to
explain lots of stuff to me) and it really shows.

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

Re: minimum panel width and autohide butons

[Elijah Newren]

On 12/7/05, sean d <[EMAIL PROTECTED]> wrote:
> I would like to add an option to the properties of gnome panel to remove the
> buttons on either side of the panel completely.  When they are not used for
> autohide they are essentially wasting space correct?  I also would like to
> decrease the minimum panel width to whatever the size (panel height) is set
> to instead of the arbitrarily large number of 100.  This is easily done as
> everything is defined as constants at the beginning of panel-toplevel.c
>
>  Would these changes be approved?  Should I go ahead and write a patch for
> it so people can see my idea?  Thanks

Thanks for working on Gnome.  Do note that this really doesn't apply
to more than one module, so you might have better success taking it to
the panel maintainers (it's also worth nothing that asking people to
pre-approve unwritten patches is really unlikely to happen).  Asking
on d-d-l just subjects it to the bikeshed effect; for example, my gut
reaction would be to say "Why is this useful at all and why do we need
yet another preference?"  But I'm not the maintainer.  And convincing
me wouldn't do you a bit of good--it'd all be wasted air.

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

Re: Composite use in GNOME causes a strange behavior

[Elijah Newren]

On 12/16/05, Carlos Eduardo Rodrigues Diogenes <[EMAIL PROTECTED]> wrote:
> I was testing some softwares that use composite, while running GNOME,
> like xcompmgr and mouseloupe
> (http://www.inf.ufpr.br/imago/mouseloupe/english/index.html) and I
> percepted that when is asked to redirect all the windows to off-screen
> and when they are composed to be showed to the user the panel lost the
> power to force windows to stay under it, so the windows can be moved
> freely to where you want.
>
> Why this happen? This is why the window manager used by gnome don't
> expect to have a composite manager or other applications that use this
> extension?

I have no clue.  But it's already filed as
http://bugzilla.gnome.org/show_bug.cgi?id=314331 and
https://bugs.freedesktop.org/show_bug.cgi?id=1187 which is probably
the best place to take the discussion. (The freedesktop.org bug does
make it seem that the panel is being mishandled somehow if xprop is
reporting it as withdrawn...)

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

Re: FYI re: new bugzilla and gmail

[Elijah Newren]

On 12/19/05, Davyd Madeley <[EMAIL PROTECTED]> wrote:
> Quoting Luis Villa <[EMAIL PROTECTED]>:
>
> > Enough changed in the headers/etc. since the upgrade that I just
> > discovered that gmail is now marking all my gnome bugzilla mail as
> > spam. Something to look out for if you read bugzilla in gmail.
>
> (h3ck 1t out!!!1! Ne\/\/ fr0m GN0ME.org: Bugal15. B3 en\/y 0f y0uR
> fR13nds wh3n
> sT4y h4rd l0ng3r.

Are you just letting us know the comments you were putting into bugs
that Luis was watching?  Well, I guess we just solved that one.

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

Time to update your products!

[Elijah Newren]

Hi everyone,

I'm sending this email because there are a couple areas where we need
everyone's help getting their product updated with the new bugzilla:
 - list of developers
 - product home page
 - product-specific triage guidelines
 - fixing the product name
Developers should be able to fix most of these by using the 'edit this
product' link on the right side of the product overview page (e.g.
http://bugzilla.gnome.org/browse.cgi?product=control-center)[1].  You
can also check the other items, among other things, with the other
nearby links.

* List of developers *

GNOME Bugzilla users now have the capability to modify key bits of
their own project if they are already marked as a developer of the
project and have the right permissions. So step one for everyone is to
go and see if you can add other developers.  If you can, great,
continue to the next step. If you can't, contact the bugmasters
(there's a link for this on the product overview page too) and we can
add you. We've tried to add several already, but as you know, manual
entry isn't perfect.

It's worth nothing that the developers of a module show up in three
notable places in the interface -- in the editproducts page so that
developers can add other developers, near the bottom of the product
overview page (browse.cgi) so people can figure out who the current
developers of a module are, and in the describeuser.cgi page (you can
click on the lightbulb icon next to any person's name near the comment
they added to any bug to learn more about that user).  It may be used
in additional places in the future.

* Product home page *

The project home page now shows up in the product overview page. Set
it in the editproducts.cgi page.

* Product-specific triage guidelines *

We've brought these up before, and these are on the wiki, but now they
are linked to from the product overview page.  These can be used to
talk about common bug types that appear in your module (and are
somehow more specific to your module) and how to handle them so that
volunteers can assist you better.

* Fixing the product name *

There's a link from the product overview page to viewcvs.  If your cvs
modulename doesn't match your bugzilla product name, the link is
broken.  We consider that a feature.  Having the tarball name be
different from the cvs module name, and having both be different than
the bugzilla module name is a bit of a pain for everyone, but there's
a couple module authors that don't seem to mind.  Anyway, consider
this encouragement to fix things.  ;-)  The fix could be a change of
bugzilla product name, or a cvs module name change.


[1] There will only be a "Show component descriptions" link if you
don't yet have permissions to edit your product.  Either let us know
so we can add you to the list of developers, or, if a developer is
already listed for the module, ask them to add you.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Reminder: fix critical warnings before Jan. 1st

[Elijah Newren]

On 12/5/05, Luis Villa <[EMAIL PROTECTED]> wrote:
> On 12/5/05, Elijah Newren <[EMAIL PROTECTED]> wrote:

> > Can you wait a couple weeks for the link to the bugzilla query?
>
> I can, but then again, I'm not the one who is supposed to be fixing
> things by Jan. 1st :)

Just remembered about this thread...  Critical warning bugs show up in
the product summary page (e.g.
http://bugzilla.gnome.org/browse.cgi?product=evolution, which happens
to have 3), in the "Product Summary" section at the right.  This link
will probably not remain there indefinitely, but should be useful for
now as we try to do the initial weeding out of these bugs.  Those
wanting a query pointing to all such bugs for all products can use the
following link:
  http://bugzilla.gnome.org/buglist.cgi?query=%2bg_log_level_critical
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Time to update your products!

[Elijah Newren]

On 12/20/05, Elijah Newren <[EMAIL PROTECTED]> wrote:

> Developers should be able to fix most of these by using the 'edit this
> product' link on the right side of the product overview page (e.g.
> http://bugzilla.gnome.org/browse.cgi?product=control-center)[1].  You
> can also check the other items, among other things, with the other
> nearby links.

So, I messed up in setting up perms for a handful of people; they
would have been listed as a developer but without perms to edit the
product or add other developers.  Should be fixed now.  If you were
one of those, please try again.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Time to update your products!

[Elijah Newren]

On 12/20/05, Elijah Newren <[EMAIL PROTECTED]> wrote:

> Developers should be able to fix most of these by using the 'edit this
> product' link on the right side of the product overview page (e.g.
> http://bugzilla.gnome.org/browse.cgi?product=control-center)[1].  You
> can also check the other items, among other things, with the other
> nearby links.

So, people appear to have found a couple different bugs, with
permissions not being set correctly (it appears I handled it correctly
for creating new products but not editing existing ones), and with the
admin link showing only infrastructure/bugzilla.gnome.org instead of
the product you actually have rights to edit.  Should be fixed now. 
Let us know if you run into further problems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Another way to solve the Spatial vs. Navigational debate

[Elijah Newren]

On 12/21/05, Luca Ferretti <[EMAIL PROTECTED]> wrote:
> See the attachment :-)

Sweet, let's also have them pick the amount of edge resistance, focus
policy, raising policy, the double-click-on-titlebar-action, whether
they want animations, whether the taskbar lists windows from all
desktops or just the current one, whether the taskbar should group
windows, whether windows clicked on in the taskbar should restore to
the current workspace or the native workspace, the application font,
the desktop font, the window title font, the terminal font, the theme,
the screensaver, and many, many more.

That way we can make sure users get the optimal experience by having
everything configured just the way they want it.

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

Re: Another way to solve the Spatial vs. Navigational debate

[Elijah Newren]

On 12/21/05, Jan de Groot <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-12-21 at 15:27 -0700, Elijah Newren wrote:
> > On 12/21/05, Luca Ferretti <[EMAIL PROTECTED]> wrote:
> > > See the attachment :-)
> >
> > Sweet, let's also have them pick the amount of edge resistance, focus
> > policy, raising policy, the double-click-on-titlebar-action, whether
> > they want animations, whether the taskbar lists windows from all
> > desktops or just the current one, whether the taskbar should group
> > windows, whether windows clicked on in the taskbar should restore to
> > the current workspace or the native workspace, the application font,
> > the desktop font, the window title font, the terminal font, the theme,
> > the screensaver, and many, many more.
> >
> > That way we can make sure users get the optimal experience by having
> > everything configured just the way they want it.
> >
> > :-)
>
> What about something like the personalization wizard that KDE uses? As
> experienced user, I just click skip because I don't want to use KDE,
> only want to test it to see if I didn't break something upgrading
> packages in the distribution. Back those days when GNOME had a 1 as
> first number in the version, I used KDE and the personalization wizard
> was really nice to use the first time starting KDE.

Hmm...looks like I should have added the "" tag after all.  Oh, well.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Time for the annual bugzilla statistics

[Elijah Newren]

Hi,

I thought others might be interested in some bugzilla statistics from
2005.  Detailed information can be found at
http://developer.gnome.org/projects/bugsquad/statistics/2005/, some
highlights from the main page are:


Overall statistics:
  Current open reports: 1 (*)
  Opened in 2005:   37845
  Closed in 2005:   34196
  Of the bugs closed, 8797 were marked as duplicates

  (*): This line excludes reports marked as enhancements

The following people closed more than 750 bugs in 2005:
  2329  Sebastien Bacher
  1183  Matthias Clasen
  1093  Olav Vitters
  1092  Andre Klapper
  939   Kjartan Maraas

The following people reported more than 250 bugs in 2005:
  663   Sebastien Bacher
  500   Poornima
  331   chpe
  251   Kjartan Maraas

A little bit about the above people (please correct the mistakes I've
made in pointing out peoples' roles):

  Sebastien Bacher is "the Debian/Ubuntu build bot" as Olav put
it. Not only does he package software at an insane rate, he also
forwards lots of bugs reports from Debian and Ubuntu and helps us
keep our bugzilla sane.
  Matthias Clasen maintains gtk+, working for Red Hat. Given how much
harder gtk+ bugs tend to be to handle than bugs against normal
apps (in my experience at least), I'm always amazed to see
Matthias get through so many bugs.
  Olav Vitters is our bugzilla master. He's the one responsible for
the super cool new bugzilla upgrade we have.
  Andre Klapper works on Evolution.
  Kjartan Maraas is sort of a jack of all trades for Gnome; he works
on finding and fixing bugs in just about everything. He also has
the highest score in the new points system in bugzilla (27
points), so he's the one everyone needs to try to catch. He ought
to get further bonus points for having a really cool birthday.
  Poornima Nayak, employed at Novell, works on Evolution.
  Christian Persch is the maintainer of Epiphany.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement: Gnome-schedule 1.0.0 is released!

[Elijah Newren]

Hi,

On 1/1/06, Gaute Hope <[EMAIL PROTECTED]> wrote:
> -- New release: gnome-schedule 1.0 --
>
> Hail
>
> Gnome-schedule 1.0 has been released.

Sounds cool.  Congrats.  Please do note for future reference, though,
that product release announcements are off-topic for this list (see
http://mail.gnome.org/mailman/listinfo/desktop-devel-list);
gnome-announce-list should be used for that instead.

Keep up the good work.

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

Re: Announcement: Superswitcher 0.1

[Elijah Newren]

On 1/1/06, Nigel Tao <[EMAIL PROTECTED]> wrote:
> It's mostly an initial announcement, and I've posted to d-d-l to spread
> the word

As per http://mail.gnome.org/mailman/listinfo/desktop-devel-list,
gnome-announce-list is the right place for software announcements
rather than this list.  Sounds cool, though.  Congrats.

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

Re: Debian and the GFDL problem

[Elijah Newren]

On 1/4/06, Jordi Mallach <[EMAIL PROTECTED]> wrote:

> The members of the Debian GNOME team are interested in what the GNOME
> project thinks about this problem. If you think relicensing the manuals
> is a good idea, we'd have to start a hunt of every copyright holder to
> get permission to relicence the manuals. We need to get started sooner
> than later, if we want to be ready by 2.16 (which is our optimistic
> target for GNOME version to distribute with Debian etch).

I personally think it's a good idea as I agree that the GFDL sucks,
but I have virtually 0 influence in this area.  The person you'd need
to talk to is Shaun; as GDPFL and the one working hardest on this
currently he naturally has the most say.  He'd also be the one who'd
have the best idea of who to contact and how much work you'll be in
for.  I'm guessing that if you could get him and Sun to agree to dual
license then you'd have the majority of the documentation covered but
that's just a random guess on my part; he'd be able to tell you
better.

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

Re: GDFL - why is it bad? Debian could do better! (was: Re: Debian and the GFDL problem)

[Elijah Newren]

On 1/8/06, Andy Tai <[EMAIL PROTECTED]> wrote:
> Same for your attacks on the GFDL... "they have nothing
>  to do on a GNOME mailing list. Please bring this on another place or in
>  private mail."

I respectfully disagree.  There are those that feel that the GFDL is a
very poor choice and with what, at least to me, looks like solid
reasoning.  I do not use Debian or its derivatives, but I fully agree
with their sentiment on this issue -- meaning that I too feel that
this is a problem and one which affects everyone.  The easiest
solution appears to be asking copyright holders to dual license their
work.  However, I do agree that the discussion should probably be
moved to gnome-docs-list (or perhaps in contacting individual authors)
instead of continued here.  But it's hard to fault Josselin for trying
to correct misunderstandings (and in fact, I feel Josselin should get
bonus points for doing quite well at responding reasonably to
deliberately inflammatory (and partially off-topic) emails).

Just my $0.02,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: string freeze explanation on the wiki

[Elijah Newren]

On 1/10/06, Thomas Vander Stichele <[EMAIL PROTECTED]> wrote:
> Frustrated by my inability to easily find a string freeze explanation, I
> created http://live.gnome.org/MaintainersCorner_2fStringFreeze based on
> a mail from Christian Rose during the 2.9 cycle.  Feel free to further
> change the page or suggest places in the wiki to link from to this page.

We had linked to Christian's email from
http://live.gnome.org/ReleasePlanning_2fFreezes (under the
Approving/Rejecting Freezes section; seems like it'd be better under
the string section).  Maybe we should move your string freeze page to
go with the other stuff and then link from MaintainersCorner to all
the freeze info?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Trying to reach consensus for the proposed modules

[Elijah Newren]

On 1/11/06, Steve Frécinaux <[EMAIL PROTECTED]> wrote:
>  >  + deskbar-applet: most people were okay, some people thought it was
>  > eating too much memory. I'd say consensus was "accept", but there's the
>  > issue that it depends on gnome-python-extras, which is not in the
>  > bindings. What should be done here?
>
>
> gedit 2.13.x also depends on g-p-e, for the new python plugins (like the
> Snippets Plugin [1]).
> It requires at least the gtksourceview module, and perhaps the
> gnome-print bindings (I'm not sure).

Well, looks like we definitely have a mess to sort out.  (From a quick
glance at gedit's configure.ac, it looks like it can be removed with a
simple switch (though my auto-fu sucks so someone else would need to
verify).  If we don't get this straightened out, the default would
need to change to have it not included by default.)

The previous consensus and agreement was that desktop modules could
depend upon python bindings found in the bindings release set. 
gnome-python-extras isn't part of that set.  As pointed out in
Murray's email, it's not suitable for that set either.  So we need to
determine what we want to do and reach consensus on this point as
well.  A variety of options exist:
  - don't allow desktop modules to depend on gnome-python-extras,
unless they do so optionally (the state of things if we can't reach a
consensus or no one bothers to drive issue to try to get one)
  - agree that gnome-python-extras is okay for desktop modules to
depend on; means one of the following as far as I can tell
(a) propose gnome-python-extras for the desktop release and have it accepted
(b) create an alternate release set, perhaps as a subset of
bindings but which has a different set of rules that's more like the
desktop release set, and have gnome-python-extras proposed and
accepted for it
(c) allow gnome-python-extras to be a blessed external dependency
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list