Hey,
On Mon, Oct 22, 2012 at 11:18 AM, Brian Cameron
<brian.came...@oracle.com> wrote:
> Most readers would likely need
> to review the code to understand what specific power features are
> actually being described here or why they might need logind. Most
> rows in the table are like this, so this matrix is only a very
> useful guide if the reader has many hours to invest to understand
> how the information applies to them. To me, the matrix looks more
> like a draft of an outline to a guide, but it is a start.
You are talking about shipping a *complete* and *free* (libre *and*
gratis) graphical desktop environment and you're complaining that you
have to spend a couple of hours *reviewing* the code and/or turning
off the features that you *did not* participate in developing because
you choose to use a different OS than the people who actually *did*
spend time working on the feature? I don't think that's fair at all -
and I really have to constrain myself to not use stronger language
here.
Instead, may I suggest getting involved early and voicing your concern
*during development* so we can either add an abstractions (such as
e.g. GVolumeMonitor, GDrive, GVolume, GMount) or ifdefs or whatever
[1] and avoid situations like this? Surely, the way it needs to work
in GNOME is that if distributors show up and do portability-work (and
it's good enough) [2] it will get merged. But it involves actually
showing up and doing the work and not just sending e-mail. But please
don't expect others to port GNOME to run on your OS.
David
[1] : Abstractions can happen at several levels: D-Bus interfaces,
Library APIs, #ifdef etc. I think it's up to the maintainer of the
module in question to decide how to handle portability.
[2] : FWIW, GVolumeMonitor and related APIs is a *great* example of
how to handle portability. We've kept the same application-level API
since the beginning and have managed to just swap the implementation
out (hal, udisks1 and now udisks2) without disrupting any application.
And we've made sure it worked on old-skool Unix and the BSDs by having
a 'unix' (e.g. fstab/mtab based) backend as well. But as any GIO/GVfs
developer will tell you, the price is pretty high but in terms of code
complexity and also there's a hit in runtime/login performance because
of its distributed nature.
There's another important lesson to be learned here: portability and
abstractions on the GNOME-side is not only about OS portability - it
also makes it easier to revamp some of the underlying subsystems ...
e.g. I could never have done the hal->udisks1->udisks2 move without
something like GVolumeMonitor so, in retrospect, it turned out to be a
good idea that such abstractions were around. But they come at a cost.
_______________________________________________
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.
