Nabble - Gnome - Hackers

Re: GLib 2.23.1 released

2009-12-21T13:15:45Z

On Mon, Dec 21, 2009 at 2:32 PM, William Lovaton <walovaton@...> wrote:
> Hi Matthias, interesting performance work. Is there any numbers about these improvements? what kind of workload gets improved with this?

Most of the performance work was aimed at improving performance in
multi-threaded scenarios by reducing lock overhead. If you look
through the bugs that I've listed, some of them have measurements.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: GLib 2.23.1 released

2009-12-21T11:32:22Z

Hi Matthias, interesting performance work. Is there any numbers about these improvements? what kind of workload gets improved with this?

Keep up the good work.

Regards,

-William

--- El lun 21-dic-09, Matthias Clasen <mclasen@...> escribió:

De:: Matthias Clasen <mclasen@...>
Asunto: GLib 2.23.1 released
A: gnome-announce-list@..., gtk-devel-list@..., gtk-app-devel-list@..., gtk-list@...
Fecha: lunes 21 de diciembre de 2009, 11:02

Overview of Changes from GLib 2.23.0 to GLib 2.23.1
===================================================

* GObject performance work has landed:
- Construction of simple objects is much faster
- Interface lookup is lock-free and constant-time now
- Reduced locking overhead when dealing with types

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Call for Talks - FOSDEM 2010 (GNOME devroom)

2009-12-13T10:20:34Z

Hi everyone,

As for the last few years, we'll have a GNOME devroom next year at FOSDEM (6/7
feb in Brussels), and as always, we want *YOU* to give a talk about
the cool project you are hacking on in this devroom

During this week-end, we'll have half a day dedicated to GNOME specific talks,
and on Sunday, we'll share the devroom with people hacking on other
desktop environments and have talks about crossdesktop topics or talks
about some GNOME specific topics, but which can be of interest to the
other communities.

Devroom talks are 30/35 minute long talks presenting one aspect of the
GNOME community you care about. This can be a technical talk about a
library you're hacking on, but you can also give a talk about how to
market GNOME at big events, or about how to get involved in the
translation project, ... In short, you can talk about whatever you
want as long as it's about GNOME!

Like last year, you'll find all the information about the even
on http://live.gnome.org/Brussels2010. However,if you want to
give a talk, please don't add yourself to the schedule. Send me an
email instead describing your talk and the slot(s) you'd like to have,
and add that information to the "Presenters and their presentation" on
the wiki.

If you aren't giving a talk but are coming, please let us now at
http://live.gnome.org/Brussels2010/Attendees ! This is helpful in case
we print shirts or name tags.

Please send your talk proposals before Friday 8th January. With the end of year
holidays, this deadline will come *really* quickly, so the sooner you send a proposal,
the better (before the holidays is great ;).

Hope to see you all in Brussels, enjoy the last days of 2009,

Christophe
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

GtjComboBox question

2009-12-01T00:15:40Z

Hi, ALL,
Is there a function to show a list box of a combo box?

It looks like gtk_combo_box_popup() is what I'm looking for,
but the documentation says that it should be used with an
accessibility pack.

Thank you.

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gmime 2.4.9

2009-09-06T04:17:29Z

Jeffrey,

Just want to confirm with you that this new version is for Gnome
2.27.x/2.28 or 2.30?

Thanks
Dave
Jeffrey Stedfast wrote:

> Module: gmime
> Version: 2.4.9
> Uploaded by: Jeffrey Stedfast
>
> http://download.gnome.org/sources/gmime/2.4/gmime-2.4.9.tar.gz
> sha256sum: aeb089d3fa7c517c9a25cb398698da0f603882eb13fab132ded7181e604de4c0
> size: 1.1M
>
> http://download.gnome.org/sources/gmime/2.4/gmime-2.4.9.tar.bz2
> sha256sum: 74ace088c6892da131fcc57f1ed4b5b802ac8f279aea1fed264b7f026af3b255
> size: 824K
>
> ChangeLog
> ---------
>
> 2009-09-03 Jeffrey Stedfast <fejj@...>
>
> * README: Bumped version
>
> * configure.in: Bumped version to 2.4.9
>
> * build/vs2008/gmime.vcproj: Bumped version.
>
> * mono/gmime-sharp.dll.config.in: Fixed the target library
> version, thanks to MATSUURA Takanori <t.matsuu@...>.
>
>

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:53:27Z

On Wed, 2009-07-22 at 23:29 +0100, Bastien Nocera wrote:

> On Wed, 2009-07-22 at 18:17 -0400, David Zeuthen wrote:
> >
> > For Bluetooth, another Linux only thing for now, the answer is the
> > same;
> > we probably don't need Bluetooth specific APIs - mostly because we
> > already abstract the useful Bluetooth stuff in GVfs and PulseAudio.
>
> Actually, not quite. The BlueZ D-Bus API is already an abstraction of
> the Bluetooth specs. You could implement that same API in another daemon
> for use on other Bluetooth stacks.

Yeah. But right now it is Linux only und so weiter... If someone ports
Bluez to other platforms, or reimplements, then, hey, great, they can
take advantage of all the cool Bluez integration you have written. That
alone should be reason enough for them to do it. But things like this
just don't happen over night. It took 2+ years for a Solaris backend for
HAL to surface and another year or so for the FreeBSD backend.

My main point really is that we need to stop thinking of GNOME as a
whole desktop environment that will run everywhere and solve every
problem known to man. We need to stop bickering about really OS-specific
things such as volume controls. We need to make a distinction between
applications (the thing people actually use) and OS-specific conduits
(audio volume control, formatting a disk).

We need to focus hard on providing a set of rich, but lean and tightly
controlled (e.g. solid maintainers needed), introspectable libraries so
people can write useful _applications_ in their favorite language. And,
ideally, for any target. And, more ideally, so apps are relocatable (cf.
the recent thread on gtk-devel-list).

Further, we need to design these APIs so they are extendable. We want to
provide baseline functionality for the X11/target (GUnixVolumeMonitor)
while at the same time take advantage of the latest and greatest
OS-specific software (DeviceKit-disks monitor).

(And, for those of you still reading, GIO/GVfs is an _excellent_ example
of how to do this. Alex really got this right.)

That set of APIs will provide a good foundation so people can innovate
in areas like GNOME Shell, Sugar, whatever without having to worry about
a lot of things.

(Of course we still need to care about system integration, e.g. the
whole DeviceKit-{disks,power}, PackageKit, Pulseaudio, Bluez story. But
it really shouldn't be anything that affects the G stack except that it
might optionally use parts of it in certain place. And we might use it
in apps that are not pure G apps - e.g. Bluez desktop integration,
Volume Control, Palimpsest and so on.)

David

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:50:22Z

Hi David,

> You know, maybe if the non-Linux platforms actually participated in
> _designing_ and _developing_ the core plumbing bits, threads like this
> wouldn't have to happen.
<snip>
> It would be a lot better if non-Linux platforms, like Solaris is in this
> respect, actually started participating much earlier. You still have
> time for the DeviceKit-disks and DeviceKit-power stuff for example.
>
> Anyway, if SUN started changing this behavior then maybe it would be a
> lot easier to not feel incredibly insulted by statements like "it
> behooves them as professional open source software engineers to respect
> the requirements". Because right now it's the pot calling the kettle
> black.

[Standard boilerplate, speaking for myself, not my employer.]

I did the initial HAL port to Solaris (but long since moved to other
stuff), you might remember me. With respect to benefits of early
participation, I agree with you completely - I learned the hard way and
have been trying to convince folks here not to repeat that mistake with
PolicyKit, ConsoleKit and DeviceKit - as you can witness, with little
success.

There is no single reason or person to be blamed: there's organizational
fragmentation and inertia; lack of funding; differences in engineering
culture; etc. I am getting a positive vibe from engineers slowly warming
up to the agile, iterative development style, so hopefully things are
moving in the right direction.

I wouldn't get too offended with what Calum said, I think it's the right
idea, though perhaps the proposed implementation isn't optimal in that
the testing cost distribution is lopsided. To give a simplified example,
what we had during HAL development sometimes, say, 0.x.y was released
based on Linux exclusively and we had to follow that up with a 0.x.y.1
release to fix FreeBSD/Solaris issues. With an established N-way
commitment from all interested platforms, I believe such issues could be
resolved upfront, leading to higher quality releases (less iterations)
and a more even cost distribution, with little effect on schedule.

So from a bystander's point of view, maintaining GNOME's platform
neutrality requires effort from both sides: from the ideological
leaders, maintaining portability as a core requirement, built in not
screwed on; and from interested platforms, continuous participation and
timely response.

-Artem

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:40:20Z

On 22 Jul 2009, at 19:30, David Zeuthen wrote:

> You know, maybe if the non-Linux platforms actually participated in
> _designing_ and _developing_ the core plumbing bits, threads like this
> wouldn't have to happen.

<snip>

> Anyway, if SUN started changing this behavior then maybe it would be a
> lot easier to not feel incredibly insulted by statements like "it
> behooves them as professional open source software engineers to
> respect
> the requirements". Because right now it's the pot calling the kettle
> black.

Oh, there's no doubt Sun and our ilk have to do much better as well--
no argument at all there (although obviously Sun has indeed made
significant contributions to various core plumbing bits in the past,
and is still doing so in some areas).

But even still, Sun engineers working on GNOME for OpenSolaris can't
really avoid the fact that whatever they do contribute upstream has to
work on Linux first and foremost, so those contributions have usually
seen at least some cursory Linux testing before they get that far.
Whereas IMHO it's considerably easier for other contributors to
overlook the fact, usually quite innocently, that they could increase
the value of their contributions just by ensuring that they work with
minimal effort on the other platforms that GNOME embraces.

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:31:33Z

On Wed, Jul 22, 2009 at 01:40:51PM -0500, Jason D. Clinton wrote:
> pardon me for pointing out the pink elephant in the room: why doesn't Sun
> just admit that (Open)Solaris is a dead-end?

<moderator hat on>
Everyone: Please refrain from posting to any replies to this email or
anything which followed up on this email. Thanks.
</moderator hat on>

--
Regards,
Olav
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:29:53Z

On Wed, 2009-07-22 at 18:17 -0400, David Zeuthen wrote:
>
> For Bluetooth, another Linux only thing for now, the answer is the
> same;
> we probably don't need Bluetooth specific APIs - mostly because we
> already abstract the useful Bluetooth stuff in GVfs and PulseAudio.

Actually, not quite. The BlueZ D-Bus API is already an abstraction of
the Bluetooth specs. You could implement that same API in another daemon
for use on other Bluetooth stacks.

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:17:45Z

On Wed, 2009-07-22 at 17:36 -0400, Colin Walters wrote:

> On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<david@...> wrote:
>
> I agree with a lot of what you say, except:
>
> > b. Everything in the core platform _needs_ to work on all three major
> > platforms:
> > - POSIX/X11
>
> This isn't a platform really. Which is really the entire debate here.
> They're enough, along with maybe a file monitoring API, to write the
> classic "shared Unix server desktop, complete with file manager,
> clock, and panel". But beyond that - enterprise (let alone consumer)
> laptops in particular, no way.

No, but it's a starting point. Just like GUnixVolumeMonitor is a
starting point. And the same way GFileMonitor has a FAM backend (that
FreeBSD is still using as far as I can tell). People can fill in the
blanks with better implementations.

> If you guys working on DeviceKit-* are willing to have different
> backends, then that sounds fine. It's not a complete answer, but it
> fills in the massive gap that removing HAL left. If not, then we have
> to think about the story GNOME is going to tell here.

We might but it's a lot of work. It is probably worth it.

> Maybe it just
> ends up being gnome-power-manager isn't even added to the session if
> there's no DK-power, and vendors have to fill in that gap on their
> own, i.e. it'd be renamed gnome-dk-power-manager, and someone else
> could come by and add a different daemon.

It's important to make a clear distinction between apps and the G stack.
For something like storage handling, every app needs it for the file
chooser. And for things being able to implement a file manager. So we
implement just enough of it in the G stack so it is useful.

For example, Nautilus basically (that's a big basically, but...) only
depends on GLib and GTK+ right now. But we don't offer enough API in the
G stack to write e.g. Palimpsest Disk Utility - e.g. if you want to
write a formatting tool, partitioning utility, whatever you need to
depend on something outside the platform. It just means that ISVs can
only write file managers and not advanced disk utilities. And that's
fine.

For power management, maybe we only offer basic API in the G stack to do
what apps need: E.g. inhibit system suspend / inhibit screensaver. And,
again, that's completely fine. We don't expect ISVs to be able to
implement complete desktop environments.

For Bluetooth, another Linux only thing for now, the answer is the same;
we probably don't need Bluetooth specific APIs - mostly because we
already abstract the useful Bluetooth stuff in GVfs and PulseAudio.

For Audio, it is basically the same. Apps don't really *need* to care
about whether it's Pulse/OSSv4 or whatever. They are supposed to be
using GStreamer *anyway*. So we probably don't need to provide any API
in the G stack except for things things like libcanberra which is
already portable to whatever.

Anyway, my main point is this: the POSIX/X11 target isn't so much about
making "GNOME, the desktop" run on POSIX/X11. It's about making apps
*built* for "GNOME, the desktop", e.g. apps using only the G stack (e.g.
GLib / GTK+ / GStreamer / Clutter / Webkit / whatever) run on any random
POSIX/X11 system. Or any random Win32 or OS X system.

In *addition* we could require that the basic desktop shell (core apps
such as Nautilus, gnome-panel - gnome-shell in the future) needs to be
pure apps - e.g. only rely on the G stack. We'd probably want that even
if it means the basic desktop shell would run in degraded mode (e.g.
missing functionality).

This would of course also means that some apps that people think of as
"core GNOME apps", such as gnome-power-manager wouldn't really be pure
apps (only using the G stack) insofar they would have strong deps on
things outside the G stack (e.g. devkit-power). Again, that's completely
fine.

It's all about how we *frame* it

- G Stack (runs on any target)
- gtk+/glib/gstreamer/clutter/webkit/whatever
- G apps (can only depend on the G stack)
- panel, file manager, desktop shell
- Value add apps (may be OS specific)
- disk utility / formatting / etc.
- power manager
- volume control (highly OS specific)

In my view this is very close to how things actually work. If we made
something like this official we wouldn't have to waste time arguing
whether the volume control is depending on PulseAudio or not.... of
course it would leave vendors not shipping PulseAudio in the cold, but
then again, these vendors can just work on their own volume control (or
take the GStreamer one) and do whatever they want. That's completely
fine.

So all in all, this is basically proposing shifting more responsibility
to the OS vendor. e.g. it would make it more difficult to get GNOME
working out of the box unless you are willing to ship the latest bits.
I, for one, think that is a *good* thing. Either you swim or you sink.

David

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T15:13:45Z

On 22 Jul 2009, at 20:10, Colin Walters wrote:

>
> This is really the *only* one I can think of. TSOL vs SELinux isn't
> really relevant here since GNOME core doesn't really do much with
> SELinux currently.

(It does enough that we've had to patch bits out of the Nautilus file
properties GUI, in the past... don't know if that's currently the
case, though.)

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T14:36:58Z

On Wed, Jul 22, 2009 at 5:07 PM, David Zeuthen<david@...> wrote:

I agree with a lot of what you say, except:

> b. Everything in the core platform _needs_ to work on all three major
> platforms:
> - POSIX/X11

This isn't a platform really. Which is really the entire debate here.
They're enough, along with maybe a file monitoring API, to write the
classic "shared Unix server desktop, complete with file manager,
clock, and panel". But beyond that - enterprise (let alone consumer)
laptops in particular, no way.

If you guys working on DeviceKit-* are willing to have different
backends, then that sounds fine. It's not a complete answer, but it
fills in the massive gap that removing HAL left. If not, then we have
to think about the story GNOME is going to tell here. Maybe it just
ends up being gnome-power-manager isn't even added to the session if
there's no DK-power, and vendors have to fill in that gap on their
own, i.e. it'd be renamed gnome-dk-power-manager, and someone else
could come by and add a different daemon.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T14:07:09Z

On Wed, 2009-07-22 at 15:50 -0400, Colin Walters wrote:

> On Wed, Jul 22, 2009 at 3:10 PM, Colin Walters<walters@...> wrote:
> >
> > I think it makes sense to continue to have GNOME work in the basic
> > "POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
> > devicekit-power isn't running. But beyond that is hard.
>
> I should add that despite it being hard, the different interests here
> should try to have a constructive conversation about it.
>
> Some of this is more easily divisible than others; nothing directly
> depends on nm-applet, and most projects using say
> org.freedesktop.NetworkManager already have it conditional, and it's
> not hard to do. For other things like detecting a webcam device and
> using it...well...hard.

Exactly.

FWIW, I've been advocating for a while that, for example, GStreamer
should aim to provide everything an application needs - ie. a complete
framework. This came up when Cheese was being ported from HAL to use
libgudev for device discovery. Now, the actual device interaction
already happened in GStreamer, e.g. you use the v4l source and pass it a
device file. But device detection etc. was missing. Having all that in
GStreamer will make Cheese easily portable to Solaris, Windows, OS X and
so on (and AFAICT these changes are happening in GStreamer so kudos to
these guys).

On a more general note, the way I'd like our platform story to end up is
that GLib, GTK+ and GStreamer are the three only (sets of) libraries
that people end up using. We're there already for storage/io devices
(GVolumeMonitor) and networking (the networking/resolving bits that
recently landed in GIO).

The way it works for storage/io is through GIO extension points:

- The interface library (GIO) provides default implementations
(GUnixVolumeMonitor, GWin32DirectoryMonitor for example)

- Modern desktop operating systems can be replace implementations
with in 3rd party packages. We do this in GVfs - there's a HAL
based volume monitor that works on Linux, FreeBSD and Solaris.

In fact, thanks to this separation it was relatively straightforward to
just make GIO use DeviceKit-disks instead of HAL. And Solaris and
FreeBSD can keep using the HAL monitor while modern Linux distros switch
to the DeviceKit-disks based on.

(In fact, if the Solaris folks don't want to go through the effort of
porting DeviceKit-disks (it's *hard* to port right now, something I as
the maintainer will need to be involved in fixing), they can simply just
write their own GVolumeMonitor implementation.)

Another benefit of this separation is that we are less dependent on
changes in one particular operating system. This is doubly-plus
important in Linux where our current code depends on certain kernel
API / details that are not stable. A concrete example is the proposed
libata transition from the SCSI layer to the block layer. If each and
every app had to look at sysfs themselves, we'd be in porting hell.

To sum up, I guess I'm trying to say a couple of things here

1. We need to make our core libraries genuinely useful - e.g. we
can't have them only do half of what apps need (e.g. Cheese)

2. We need to actually have some documentation telling app developers
_what_ the core platform is. We have some of this already but,
at least in my eyes, there's still too many libraries of varying
quality.

For 2., my view is very simple.

a. Our platform is GLib, GTK+ and GStreamer (and probably cool things
like Clutter when it's 1.0)

b. Everything in the core platform _needs_ to work on all three major
platforms:
- POSIX/X11
- Windows
- OS X

c. Additional desktop integration is welcome (e.g. DeviceKit-disks
based volume monitor) but things need to work without it

Now, GLib, GTK+ and GStreamer aren't yet complete enough to do a
complete desktop. But if you look at what's going on the past few years
we are definitely going in this direction:

- GIO landed
- GNIO landed
- Discussion/concrete code for GConf replacement (GSettings in GLib)
- Discussion/concrete code for G-ish D-Bus library in GLib
- Some people want power management interfaces in GTK+ - again,
this can already be done with extension points
- (e.g. the POSIX/X11 would ENOTSUP, Linux would use devkit-power,
Win32 would use the Win32 API, OS X would use the OS X API)

and so on. Oh, and there are some loose ends here like authorization,
keyring and so on - we'd need to figure out what to do with them. And
someone probably would want a HTML/JS stack too (maybe add WebKit to the
stack, I don't know).

So this is the vision: GLib/GTK+/GStreamer (and Clutter) is the proposed
stack. And the proposal is that this stack runs on at least POSIX/X11,
Win32, OS X. And that the stack is easily extensible so it works well
under Linux, Solaris providing someone writes implementations of
well-defined interfaces.

Again, all this is not really a radical _new_ idea - I mean, most of
this is already happening. But I think it would be good to have a very
clear and simple document saying this is where we are going. That is, if
people agree with this vision (points a. through c. above).

Anyway, my couple of hundred cents on this.

David

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T12:54:15Z

On 07/22/2009 02:21 PM, Tristan Van Berkom wrote:
> On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
> Schaller<uraeus@...> wrote:
>> So I would like to ask the GNOME release team to please come forward
>> and clearly state that the future of GNOME is to be a linux desktop
>> system as opposed to a desktop system for any Unix-like system.
>
> I dont think anyone wants to do that

I do.

> I wonder how much effort it would cost us to instate
> a team responsible for tracking system specific bugs and then publishing
> these on a wiki page, pretty much the same way we have translation
> teams (a system could possibly only be "supported" when its blockers
> are closed ?, while work is done "supporting" that system ?)

I think l10n in GNOME is a great model for how portability (p9y?) could
work. Module maintainers are responsible for making their apps
translatable, but are not responsible for actually translating them.
Likewise, we could say that module maintainers are expected to make
their modules "portable" (eg, isolating Linux-specific bits behind
#ifdefs or abstractions or external dependencies), but would not be
responsible for any actual *porting*--that would be the responsibility
of the "porting team" for a given platform. And if a module didn't get
ported to a given platform in time for a given release, that would not
be the module maintainer's fault, and it wouldn't delay the release.

-- Dan
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T12:50:02Z

On Wed, Jul 22, 2009 at 3:10 PM, Colin Walters<walters@...> wrote:
>
> I think it makes sense to continue to have GNOME work in the basic
> "POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
> devicekit-power isn't running. But beyond that is hard.

I should add that despite it being hard, the different interests here
should try to have a constructive conversation about it.

Some of this is more easily divisible than others; nothing directly
depends on nm-applet, and most projects using say
org.freedesktop.NetworkManager already have it conditional, and it's
not hard to do. For other things like detecting a webcam device and
using it...well...hard.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T12:10:13Z

On Wed, Jul 22, 2009 at 10:31 AM, Calum Benson<Calum.Benson@...> wrote:
>
> It goes without saying that I'd be disappointed if GNOME were to take any
> official Linux-only stance. Sun has contributed a great deal to GNOME both
> technically and financially over the years.

Definitely, Sun's contributions have been awesome.

> That said, many of the Sun team do seem to spend more time than they ought
> to just to keep GNOME running on OpenSolaris on the various Sun platforms
> these days. They often have to deal with various Linux-isms at a code or
> conceptual level, or with technologies that are coming late to Linux and are
> implemented completely differently from the equivalent used by Sun (e.g.
> RBAC v PolicyKit)

This is really the *only* one I can think of. TSOL vs SELinux isn't
really relevant here since GNOME core doesn't really do much with
SELinux currently.

> Anyway, if anything, I guess I'd argue that it's time to actually reinforce
> the notion that the GNOME desktop is intended for use on any Unix-like
> system,

Here's the fundamental problem as I see it - GNOME filled the "Unix
like system desktop" checkbox over 10 years ago, on top of POSIX, X11,
and some random bits. A lot of what we've been doing since is filling
in the stuff for a *complete operating system*, because POSIX and X
cover so little. Stuff like having USB devices work, power management,
and networking are hard problems that cross every layer from the
kernel to the desktop UI. It's hard to build this kind of stuff upon
what I think of as "towers of turtles" i.e. abstractions.

I think it makes sense to continue to have GNOME work in the basic
"POSIX+X11" mode, i.e. gnome-power-manager just calls exit(0) if
devicekit-power isn't running. But beyond that is hard.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T11:40:51Z

On Wed, Jul 22, 2009 at 10:27 AM, Calum Benson <Calum.Benson@...> wrote:

On 22 Jul 2009, at 15:56, Johannes Schmid wrote:

OK, I can install all those in a virtual machine but just the amount of
work I had to put in for basic testing cannot be really done in my free
time.

That's certainly true for many individual contributors, which is why I also said we ought to "to figure out how to better distribute the development and QA workload to make that happen".

However, for people who make their living developing GNOME software, IMHO it behooves them as professional open source software engineers to respect the requirements of the other people who will be using the code they write, insofar as those requirements are known up front. And right now, every professional GNOME developer knows up front that GNOME isn't confined to running on Linux, so that should figure fairly strongly into their design work.

I am extremely grateful for all that Sun has done to move GNOME forward over the years--indeed much of that has benefited everyone including Linux. But, pardon me for pointing out the pink elephant in the room: why doesn't Sun just admit that (Open)Solaris is a dead-end?

I mean, we all understood that Solaris was proprietary until recently. But now that Sun has admitted that wasn't going to work, why not just go the next logical step? ZFS is nice and all but you *do* hold the copyright. If the right managerial decision were to be made--say tomorrow--we wouldn't be having this conversation and Sun wouldn't even be out any business.

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T11:30:16Z

On Wed, 2009-07-22 at 16:27 +0100, Calum Benson wrote:

> On 22 Jul 2009, at 15:56, Johannes Schmid wrote:
>
> > OK, I can install all those in a virtual machine but just the amount
> > of
> > work I had to put in for basic testing cannot be really done in my
> > free
> > time.
>
> That's certainly true for many individual contributors, which is why I
> also said we ought to "to figure out how to better distribute the
> development and QA workload to make that happen".
>
> However, for people who make their living developing GNOME software,
> IMHO it behooves them as professional open source software engineers
> to respect the requirements of the other people who will be using the
> code they write, insofar as those requirements are known up front.
> And right now, every professional GNOME developer knows up front that
> GNOME isn't confined to running on Linux, so that should figure fairly
> strongly into their design work.

You know, maybe if the non-Linux platforms actually participated in
_designing_ and _developing_ the core plumbing bits, threads like this
wouldn't have to happen.

My experiences from GIO, GVfs and HAL and other things pretty much sums
up to this.

1. We find out we need some new plumbing bits to enable some kind
of new exciting feature in GNOME.

2. Someone starts working on a Linux implementation of this. The
interface is usually designed to be portable, but, hey, who
knows.

3. GNOME is ported to using this new plumbing bit. After a while the
plumbing bit matures and the new feature is being ironed out.
Much rejoicing.

4. Someone from SUN finds out that the latest version of some GNOME
doesn't compile on Solaris or work as advertised. Interesting bugs
are filed.

5. Some manager at SUN decides Solaris needs this feature too

6. The "porting" effort is out-sourced to some group in SUN
with people that are not really familiar with either a) the
plumbing bits in question; b) desktop development or GNOME
development in general

This may be harsh but it's pretty much how I feel it works.

It would be a lot better if non-Linux platforms, like Solaris is in this
respect, actually started participating much earlier. You still have
time for the DeviceKit-disks and DeviceKit-power stuff for example.

Anyway, if SUN started changing this behavior then maybe it would be a
lot easier to not feel incredibly insulted by statements like "it
behooves them as professional open source software engineers to respect
the requirements". Because right now it's the pot calling the kettle
black.

David

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T11:21:48Z

On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
Schaller<uraeus@...> wrote:
> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.

I dont think anyone wants to do that, as Matthias says we need to
pave the way for a better future, and of course you cant do that without
breaking a few eggs.

On the other hand, its possible we could do better tracking this stuff,
is there a l.g.o. page that I can visit that shows me what are the blocker
bugs in the platform for any given supported system ?

Considering that many people test out the GNOME platform on various
systems already, I wonder how much effort it would cost us to instate
a team responsible for tracking system specific bugs and then publishing
these on a wiki page, pretty much the same way we have translation
teams (a system could possibly only be "supported" when its blockers
are closed ?, while work is done "supporting" that system ?)

Cheers,
-Tristan
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T09:55:40Z

On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
Schaller<uraeus@...> wrote:

> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.
>

Why would we do that ? This is not a question about exclusion, it is a
question about moving the platform forward that our desktop is
standing on.

A desktop that is based on a stagnant, costly abstraction layer may be
easier to get running on a large number of minority unixoid platforms,
but the cost of that approach is that we are not going to be able to
compete with other desktops that make the changes in the lower layers
which are necessary to provide desktop features of 2010, rather than
2000.

Matthias
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T08:27:26Z

On 22 Jul 2009, at 15:56, Johannes Schmid wrote:

> OK, I can install all those in a virtual machine but just the amount
> of
> work I had to put in for basic testing cannot be really done in my
> free
> time.

That's certainly true for many individual contributors, which is why I
also said we ought to "to figure out how to better distribute the
development and QA workload to make that happen".

However, for people who make their living developing GNOME software,
IMHO it behooves them as professional open source software engineers
to respect the requirements of the other people who will be using the
code they write, insofar as those requirements are known up front.
And right now, every professional GNOME developer knows up front that
GNOME isn't confined to running on Linux, so that should figure fairly
strongly into their design work.

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T07:56:51Z

Hi!

> Now, there's no denying that until fairly recently, it was hard for
> most non-Sun contributors to even test their stuff on Solaris, so you
> could argue we're reaping what we sowed to some extent on that front.
> Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox
> or in a dual-boot scenario pretty much as well as any Linux distro.
> So it shouldn't be all that hard to at least check once in a while
> that whatever you're working on is at least going to build, preferably
> run, and ideally function in an OpenSolaris environment[2].

That's not in anyway Sun- or (insert-your-os-here)-specific. Say, I want
to test my module against the most used os/platform, I would at least
have to test (in no particular order):

* Ubuntu (ok, I tend to use that for work)
* Fedora
* OpenSuSE
* Gentoo
* FreeBSD
* OpenBSD
* NetBSD
* OpenSolaris
(to be continued)

OK, I can install all those in a virtual machine but just the amount of
work I had to put in for basic testing cannot be really done in my free
time.

I think downstream contributers simply have to test our alpha and beta
versions and at least file bugs if they don't work. I am sure most
maintainers will happily fix them or apply patches.

In addition, we should start some discussion before introducing a new
technologie with at least *Linux, *BSD and *Solaris if this technologie
works for them or can be made work.

But this shouldn't stop us on the other hand to deliver the user the
latest and best features for her desktop because she simply doesn't care
about the technologies used.

Regards,
Johannes

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

signature.asc (204 bytes) Download Attachment

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

2009-07-22T07:37:29Z

From a user perspective, and I know this is a very tiny sample, but out of the 230 responses to the Friends of GNOME survey of those who gave money, 30% indicated that they use GNOME applications on multiple platforms. That's a significant percent of those who responded to they survey - just something to think about.

Paul

On Wed, Jul 22, 2009 at 9:31 AM, Calum Benson <Calum.Benson@...> wrote:

On 22 Jul 2009, at 12:50, Christian Fredrik Kalager Schaller wrote:

So I would like to ask the GNOME release team to please come forward
and clearly state that the future of GNOME is to be a linux desktop
system as opposed to a desktop system for any Unix-like system.

This is by no means an "official Sun response" to this proposal, just the thoughts of somebody who's worked on GNOME at Sun for the past 9 years or so...

It goes without saying that I'd be disappointed if GNOME were to take any official Linux-only stance. Sun has contributed a great deal to GNOME both technically and financially over the years, and although there aren't nearly as many familiar Sun faces on the GNOME mailing lists and IRC channels as there used to be (or, indeed, as I'd like), there's still a good-sized team of GNOME development and QA folks working here and contributing upstream as and when we can. (FWIW, in addition to sponsoring the event again this year, a dozen or so of us made the trip to Gran Canaria this month, which, bar a couple of exceptions, is about the same or more as we've sent to every previous GUADEC.)

That said, many of the Sun team do seem to spend more time than they ought to just to keep GNOME running on OpenSolaris on the various Sun platforms these days. They often have to deal with various Linux-isms at a code or conceptual level, or with technologies that are coming late to Linux and are implemented completely differently from the equivalent used by Sun (e.g. RBAC v PolicyKit, Trusted OpenSolaris v SELinux), or with performance or scalability issues that don't affect the average Linux desktop or enterprise user, but that would make GNOME unusable on the hundreds of thousands[1] of Sun Ray thin clients out there.

All that tends to leave us less time to make the larger-scale contributions that we used to make to GNOME and its related projects. Historically, that included things like implementing multi-head support for gtk, designing and implementing the original accessibility framework, writing and reviewing large chunks of user documentation, collaborating on regular HIG updates, performing UI reviews and usability studies, etc. All these things would probably have been gotten around to eventually, but at the very least, I think it's fair to say these sorts of contributions from the non-Linux side of the fence got GNOME to where it is today a good deal quicker than would otherwise have been the case.

Now, there's no denying that until fairly recently, it was hard for most non-Sun contributors to even test their stuff on Solaris, so you could argue we're reaping what we sowed to some extent on that front. Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox or in a dual-boot scenario pretty much as well as any Linux distro. So it shouldn't be all that hard to at least check once in a while that whatever you're working on is at least going to build, preferably run, and ideally function in an OpenSolaris environment[2].

Anyway, if anything, I guess I'd argue that it's time to actually reinforce the notion that the GNOME desktop is intended for use on any Unix-like system, and to figure out how to better distribute the development and QA workload to make that happen, so that non-Linux contributors have more chance to make significant contributions upstream again instead of spending most of their time treading downstream water.

Cheeri,
Calum.

[1] Okay, I don't actually have any idea how many Sun Ray clients are out there, but I'm guessing the order of magnitude is roughly correct. If anything, it's probably an underestimate.

[2] Or indeed any other non-Linux environments that you might wish to explore to expand your technological horizons in your copious free time :)

--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

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

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T07:31:07Z

On 22 Jul 2009, at 12:50, Christian Fredrik Kalager Schaller wrote:

> So I would like to ask the GNOME release team to please come forward
> and clearly state that the future of GNOME is to be a linux desktop
> system as opposed to a desktop system for any Unix-like system.

This is by no means an "official Sun response" to this proposal, just
the thoughts of somebody who's worked on GNOME at Sun for the past 9
years or so...

It goes without saying that I'd be disappointed if GNOME were to take
any official Linux-only stance. Sun has contributed a great deal to
GNOME both technically and financially over the years, and although
there aren't nearly as many familiar Sun faces on the GNOME mailing
lists and IRC channels as there used to be (or, indeed, as I'd like),
there's still a good-sized team of GNOME development and QA folks
working here and contributing upstream as and when we can. (FWIW, in
addition to sponsoring the event again this year, a dozen or so of us
made the trip to Gran Canaria this month, which, bar a couple of
exceptions, is about the same or more as we've sent to every previous
GUADEC.)

That said, many of the Sun team do seem to spend more time than they
ought to just to keep GNOME running on OpenSolaris on the various Sun
platforms these days. They often have to deal with various Linux-isms
at a code or conceptual level, or with technologies that are coming
late to Linux and are implemented completely differently from the
equivalent used by Sun (e.g. RBAC v PolicyKit, Trusted OpenSolaris v
SELinux), or with performance or scalability issues that don't affect
the average Linux desktop or enterprise user, but that would make
GNOME unusable on the hundreds of thousands[1] of Sun Ray thin clients
out there.

All that tends to leave us less time to make the larger-scale
contributions that we used to make to GNOME and its related projects.
Historically, that included things like implementing multi-head
support for gtk, designing and implementing the original accessibility
framework, writing and reviewing large chunks of user documentation,
collaborating on regular HIG updates, performing UI reviews and
usability studies, etc. All these things would probably have been
gotten around to eventually, but at the very least, I think it's fair
to say these sorts of contributions from the non-Linux side of the
fence got GNOME to where it is today a good deal quicker than would
otherwise have been the case.

Now, there's no denying that until fairly recently, it was hard for
most non-Sun contributors to even test their stuff on Solaris, so you
could argue we're reaping what we sowed to some extent on that front.
Nowadays, though, OpenSolaris comes on a LiveCD and runs in VirtualBox
or in a dual-boot scenario pretty much as well as any Linux distro.
So it shouldn't be all that hard to at least check once in a while
that whatever you're working on is at least going to build, preferably
run, and ideally function in an OpenSolaris environment[2].

Anyway, if anything, I guess I'd argue that it's time to actually
reinforce the notion that the GNOME desktop is intended for use on any
Unix-like system, and to figure out how to better distribute the
development and QA workload to make that happen, so that non-Linux
contributors have more chance to make significant contributions
upstream again instead of spending most of their time treading
downstream water.

Cheeri,
Calum.

[1] Okay, I don't actually have any idea how many Sun Ray clients are
out there, but I'm guessing the order of magnitude is roughly
correct. If anything, it's probably an underestimate.

[2] Or indeed any other non-Linux environments that you might wish to
explore to expand your technological horizons in your copious free
time :)

--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum.benson@... OpenSolaris Desktop Team
http://blogs.sun.com/calum +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

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

2009-07-22T04:50:12Z

A topic that was discussed in the hallways in Gran Canaria is the fact
that GNOME has gone from not letting non-linux platforms hold back
development of features (ie. introduction of HAL) to making choices that
basically means we are abandoning any attempts of allowing GNOME to run
on non-linux platforms.

The switch from HAL to udev is maybe the clearest one, but the push
towards PulseAudio for a lot of things have the same effect, as I think
Lennart has said multiple times that none of the non-linux systems like
Solaris or FreeBSD got a sound system capable of supporting PulseAudio.

Personally I don't necessarily object to this choice, as giving 95% of
our userbase a better and more competitive experience critical for
future growth, and trying to come up with lowest common denominator
abstractions might be a hindrance for that, but I do object to the fact
that we are making this choice without actually having made it.

So I would like to ask the GNOME release team to please come forward
and clearly state that the future of GNOME is to be a linux desktop
system as opposed to a desktop system for any Unix-like system.

Christian

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: GTK+ 2.16.4 released (Action Required)

2009-07-02T11:58:30Z

On Wed, Jul 01, 2009 at 04:00:09PM -0700, postmaster@... wrote:
> This message serves as notification that you will not receive any more courtesy notices
> from our members for two days. Messages you have sent will remain in a lower
> priority queue for our member to review at their leisure.

Don't enable such broken crap if you want to stay subscribed on any
GNOME mailing list.

I've unsubscribed you from gtk-app-devel-list. Please resubscribe after
disabling above.

[ cc'ing gnome-hackers so others understand ]

--
Regards,
Olav
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: GTK+ 2.16.4 released (Action Required)

2009-07-01T16:00:09Z

Hello Matthias Clasen,

This message serves as notification that you will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority queue for our member to review at their leisure.

Future messages will be more likely to be viewed if you are on our member's priority Guest List.

Thank you,
alviskoon@...

About this Notice
This courtesy notice is part of a free service to make email more reliable and useful. Boxbe (www.boxbe.com) uses your existing social network and that of your friends to keep your inbox clean and make sure you receive email from people who matter to you.

Say Goodbye to Email Overload
www.boxbe.com

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

attachment0 (311 bytes) Download Attachment

problem with $HOME/.dmrc permissions

2009-07-01T14:56:27Z

Hi All,

       I was playing about with the permissions of my $home folder the other day, and accidently I created a problem which occurs each time I log in.

--- Warning Window ---

"User's $HOME/.dmrc file is being ignored. The prevents the default session and language from being saved. File should be owned by user and have 644 permissions. User's $HOME directory must be owned by user and not writable by other users."

[OK]

       What steps do I need to correct this problem?!? I've checked and yes, there is indeed a file named ".dmrc" in my $HOME folder. See attached 1KB file.

       My OS is Linux Mint 5 with a menu named "Elyssa". I'm still only a newbie at this -- so I'd appreciate step-by-step instructions.

Fond Regards,
Peter Eric (aka 'pew') WILLIAMS
from Hobart, Tasmania, Australia -- phone (03) 6236-9675

My free website is: http://pewtas.googlepages.com (or) http://tinyurl.com/yuyejs

(please visit my free website and let me know what you think about it.)

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

.dmrc (40 bytes) Download Attachment

RELEASE: MOAP 0.2.7 'MMM...'

2009-06-24T13:33:10Z

This is MOAP 0.2.7, "MMM...".

Coverage in 0.2.7: 1424 / 1899 (74 %), 109 python tests, 2 bash tests

Features added since 0.2.6:
- Added moap vcs backup, a command to backup a checkout to a tarball that
can be used later to reconstruct the checkout. Implemented for svn.
- Fixes for git-svn, git, svn and darcs.
- Fixes for Python 2.3 and Python 2.6

Bugs fixed since 0.2.6:
- 263: broken changelog unit test
- 267: a man page
- 270: cl find completely busted
- 275: cl prepare --ctags failure with exuberant ctags 5.7
- 257: ImportError: No module named moap.util
- 258: git-svn support
- 259: bzr diff patch
- 266: svn:ignore property not well parsed
- 273: DEP: RDF, Fedora release 7 (Moonshine)
- 277: "changelog prepare" doesn't list changed functions in C++ files.
- 281: changelog prepare -c crashes with "not a ctags line"
- 282: make install fails
- 284: not full change detected on svn move file
- 286: [svn] propedit on externals is not recognized as a change
- 239: warn if ChangeLog has not been saved
- 260: Add changelog grep command
- 261: Option to make 'changelog diff' include differences in ChangeLog file
- 262: changelog find: fix for multiple search terms
- 264: Make changelog find case insensitive by default
- 265: git diff should show staged changes
- 271: trailing spaces in date/name/address line for entry break parsing

Contributors to this release:
- Arek Korbik
- Jelmer Vernooij
- Jonny Lamb
- Rob Cakebread
- Thomas Vander Stichele

WHAT IT IS
----------
MOAP is a swiss army knife for project maintainers and developers.
It aims to help in keeping you in the flow of maintaining, developing and
releasing, automating whatever tasks can be automated.

It allows you to parse DOAP files and submit releases, send release mails,
create iCal files and RSS feeds, maintain version control ignore lists,
check in based on the latest ChangeLog entry, and more.

For more information, see http://thomas.apestaart.org/moap/trac/

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gnome-hackers moderation

2009-05-18T14:50:26Z

On Mon, 2009-05-18 at 22:01 +0200, Michael Schumacher wrote:

> Christian Rose wrote:
> > Someone recently asked why his subscription request to the
> > gnome-hackers list was still pending.
> >
> > I answered that besides his request, there are currently 24 other
> > pending subscription requests to the gnome-hackers list.
> >
> > I know of no list policy for subscriptions to the gnome-hackers list,
> > other than the fact that the gnome-hackers list is not an open list
> > and the list subscription is moderated.
>
> Now that is funny. I do not recall to ever having been subscribed to
> this list, but I do receive messages from it.
>
> Could it be that the list of subscribers is not actually moderated, but
> edited manually by someone who wants to maintain an inner circle of
> GNOME developers? And why did I end up on this list then?

Same thing here, always been curious who subscribed me :-)

--
Ruben Vermeersch (rubenv)
http://www.savanne.be/

_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gnome-hackers moderation

2009-05-18T13:01:01Z

Christian Rose wrote:
> Someone recently asked why his subscription request to the
> gnome-hackers list was still pending.
>
> I answered that besides his request, there are currently 24 other
> pending subscription requests to the gnome-hackers list.
>
> I know of no list policy for subscriptions to the gnome-hackers list,
> other than the fact that the gnome-hackers list is not an open list
> and the list subscription is moderated.

Now that is funny. I do not recall to ever having been subscribed to
this list, but I do receive messages from it.

Could it be that the list of subscribers is not actually moderated, but
edited manually by someone who wants to maintain an inner circle of
GNOME developers? And why did I end up on this list then?

Regards,
Michael

--
GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp
Wiki > http://wiki.gimp.org | .de: http://gimpforum.de
Plug-ins > http://registry.gimp.org |
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gnome-hackers moderation

2009-05-17T05:33:35Z

Le jeudi 14 mai 2009, à 21:40 -0400, Gregory Leblanc a écrit :
> What is the plan for handing security type messages that currently
> show up to a private mirror of the gnome-hackers subscribers list?
> Err, I guess if you're unfamiliar with how it works, that might not
> make sense. Should I post a refresher explanation here, for the folks
> who may have forgotten?

FWIW, I still think that security-type messages should go to some
security@... alias, where people would forward the issue to the
relevant maintainers -- this was already discussed in the past.

And you get a nice bonus that this new alias (or private mailing list,
if you prefer) has an explicit name that outsiders can easily find.

Vincent

--
Les gens heureux ne sont pas pressés.
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gnome-hackers moderation

2009-05-16T12:19:46Z

On 05/14/2009 09:40 PM, Gregory Leblanc wrote:
>
> What is the plan for handing security type messages that currently
> show up to a private mirror of the gnome-hackers subscribers list?
> Err, I guess if you're unfamiliar with how it works, that might not
> make sense. Should I post a refresher explanation here, for the folks
> who may have forgotten?

Count me one. By the main question is: has this mechanism been of any use
recently?

behdad

> Greg
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers

Re: gnome-hackers moderation

2009-05-14T18:40:13Z

On Thu, May 14, 2009 at 5:47 PM, Behdad Esfahbod <behdad@...> wrote:

> On 05/14/2009 05:42 PM, Rodrigo Moya wrote:
>>
>> On Thu, 2009-05-14 at 17:59 +0200, Christian Rose wrote:
>>>
>>> Someone recently asked why his subscription request to the
>>> gnome-hackers list was still pending.
>>>
>>> I answered that besides his request, there are currently 24 other
>>> pending subscription requests to the gnome-hackers list.
>>>
>>> I know of no list policy for subscriptions to the gnome-hackers list,
>>> other than the fact that the gnome-hackers list is not an open list
>>> and the list subscription is moderated. But nowhere does it, to the
>>> best of my knowledge, say *how* subscription requests should be
>>> moderated and treated. This is why I leave the gnome-hackers list
>>> subscription request moderation for others to decide, in contrast to
>>> message moderation to the list. There are two other list admins who
>>> perhaps know more than me about the gnome-hackers subscription
>>> moderation policy.
>>>
>> gnome-hackers has always been this way, since it was the private forum
>> for hackers when it was created. Not sure if that still applies, since
>> it is not used that much lately, so not sure what we should do.
>
> Hi everyone,
>
> We talked about it during the board meeting today. We feel that the best
> action at this point is to shut down gnome-hackers and tell everyone to
> subscribe to the open desktop-devel-list instead. Shout if you object, or
> we'll go forward with this plan next week.

What is the plan for handing security type messages that currently
show up to a private mirror of the gnome-hackers subscribers list?
Err, I guess if you're unfamiliar with how it works, that might not
make sense. Should I post a refresher explanation here, for the folks
who may have forgotten?
Greg
_______________________________________________
gnome-hackers mailing list
gnome-hackers@...
http://mail.gnome.org/mailman/listinfo/gnome-hackers