Re: Moving Deskbar's beagle handler to beagle itsself


On 8/20/07, Sebastian Pölsterl <marduk k-d-w org> wrote:
> You're right, it isn't guaranteed that each beagle user uses deskbar as
> well, but he has at least the option. Because Deskbar is part of gnome
> it should be installed by default in most distros. Therefore, I think it
> makes more sense to ship the plugin with beagle because it's useless
> without it.

Is there a technical reason why shipping with Beagle is preferable?
Ie, loss of performance if Beagle isn't running?

> How often you change/release the beagle-live handler is your decision,
> of course. Obviously, you have better knownledge when something changes
> in beagle that affects the deskbar handler. We on the other hand, come
> to know the changes if someone files a bug report.
> What we want to achieve is to decrease the amount of time we spend on
> fixing bugs in handlers. I know that your time is rare, too, but that's
> why I'm asking kindly.

My general inclination is that it's better for the handler to stay in
deskbar, for a couple of reasons:

(1) The brutal honesty is that we don't want to be maintaining any
more code than we have to.  We don't really have any deskbar
expertise; we're already maintaining things like Firefox, Thunderbird,
and Epiphany extensions, and not especially well.  (Although I am
hoping that our awesome SoC students will stick around after the
summer is over and help solve this.)  We also have to deal with all
kinds of external programs and libraries, and that makes this a
particularly challenging module to maintain.

(2) Beagle is supposed to be providing APIs for external applications
to use, and other software like Nautilus and Yelp use these APIs.  The
*theory* is that it would be easier for deskbar folks to maintain the
Beagle backend themselves (using a published API) rather than for us
to learn the internals of deskbar.  If we're finding that the deskbar
backend is rotting, then there are probably one of two sub-problems:

  (a) We (Beagle) are doing a bad job of announcing decisions and
  changes we are making.  I absolutely know that this is true; for
  instance, today dBera made a checkin which pretty radically changes
  the way snippets are dealt with on the client-side -- for the
  better: no more dealing with HTML -- but it was unknown even to me.
  We need to improve our communication with the community, and
  especially to the consumers of our APIs.

  (b) There isn't interest in maintaining the deskbar backend.  This
  sucks, but is understandable.  For larger changes like we've made
  recently, we should take the lead on fixing outside apps.  But I'm
  not sure it's any more likely that the handler will get any more love
  if it's included in Beagle.

In the end, you guys (the deskbar maintainers) will ultimately make
the decision as to whether or not to continue including it in your
package.  My feeling is that it's no better suited here than there.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]