Re: Release Team meeting at the beginning of January

["Elijah Newren" <newren gmail com>]

Hi,

On Jan 2, 2008 7:03 AM, Andre Klapper <ak-47 gmx net> wrote:
> ahoj,
>
> > > > >                   i propose sunday 6th, 1900 UTC.
> > So Sunday 6th?
>
> Yes.
>
> seems like guenther, olav, fcrozat, vuntz and /me have time, that's a
> majority.
> let's hope that the date also works fine for J5, elijah and kmaraas.

Oh, crap, I've got a conflict.  However, it's a conflict that ends at
1900 UTC (if I've done the time translation correctly), so with travel
I should be able to still attend the meeting; just 30-45 minutes
late...

Since I'll be late, I'll attach my personal notes about new modules
decisions to this email (I hope they make sense).

I've also got an additional item for the agenda: I've asked Lucas
Rocha if he'd be willing to take my spot on the release team after
2.22 is out, assuming the release team votes in favor of letting Lucas
on the team.  It's been a while since anyone has proposed a
non-immediate replacement (I think I was the most recent new member of
the team to be such a case), but I think it'd allow me to handle the
releases I volunteered for and help Lucas and our other relatively new
members transition to their new roles.  We could handle it different
ways, though:
  - Have Lucas replace me only once 2.22 is out, but let him attend meetings and
    subscribe to r-t to help him get the feel of things now.  (In
other words, let him have
    a transition period like I had, rather than the sudden jump into
the fray that most
    team members have received.)
  - Expand the team temporarily to 9 members; let Lucas vote in the
meeting tomorrow
    and be coaxed into volunteering for all the hard tasks.  I remain
on the team and
    finish out the stuff I volunteered for, then leave after 2.22 is out.
  - Have me leave the team now and have Lucas take my place immediately.  Use it
    as an experiment in trying to distribute the release team work to
the community
    better, by having me be a community member doing the couple
releases I already
    volunteered for.  (Or maybe have Lucas try to handle one or two of them.)
I'm fine with any of these options; there may be others as well.  I'd
also be willing to help the release team out with an occasional point
release in the future as a normal community member, if you want to
experiment with distributing that work.

Thanks,
Elijah

Cheese
  ? I can't try it out because it requires a webcam
  - Jaap voted against it (and is one of the developers!)
  - Doc work is underwhelming
  - Seems to be a bit short on releases; are they up to following the schedule?
  + Daniel Siegel and Patryk are in favor (note surprising -- module developers)
  * I vote no based on Jaap's vote, though I think it could probably
    be included in 2.24.  That's not a strong no, though; others could
    probably convince me to change.

Anjuta
  ? Surprising lack of comments from the community
  - fewer releases than I'd like; not yet following GNOME schedule,
    but it looks like they're not too far away at all.
  * Note sure how to vote; I should really try out a recent release.  I'm
    leaning towards yes.

Gimmie
  - Worries about maintainer resources (note Alex's blog about what to
    do about two independent forks; I'd rather have issues like that
    sorted out before including it)
  - I think we have too much mono in the desktop already (Tomboy), and
    we should have removed it after the Microsoft/Novell deal.
  - Releases are very spotty; only one since the middle of last year.
    I don't see how they're up to keeping with the GNOME schedule at
    this point in time.
  * I vote no.

swfdec-gnome
  ? We need to make sure the gstreamer vs. ffmpeg/libmad dependency
    issue is sorted; it's a huge problem point if a gstreamer backend
    didn't come through as expected.
  ? General positive feeling, *unless* ffmpeg/libmad is required.
  - They're a little bit short on releases, but probably aren't too far from
    being able to keep pace with the GNOME schedule.
  * I vote yes if gstreamer backend came through, no if it means depending
    on ffmpeg/libmad.

vinagre
  + Matthias and Bastien were strongly in favor.  I saw no one vote
    against it.
  + gtk-vnc (the new dep) is already needed by other things already
    (vit-manager) so bug fixes and improvements will be shared.
  + nice complement to vino; much nicer than e.g. tsclient.
  - Only one release?  That's worrying.
  * I vote yes, but I'm worried about releases and think they need to be
    thwacked.

mousetweaks
  - Uses launchpad instead of gnome or freedesktop hosting services; this is
    a blocker.
  + many people liked the functionality ideas, particularly a11y folk
  - strong push for integrating into control center instead
  + much of the preferences have been integrated into the control center already
  - It appears that integrating the m-t daemon and g-s-d is a hard nut to crack
  * I vote no based on the hosting; if that were fixed, I'd be unsure how to
    vote: try to push people to spend more effort on combining the daemons
    somehow and then allow it in a later release if this simply can't be done?

gvfs:
  + This has been sorely needed for a long time
  + Has been discussed extensively on gtk-devel-list with lots of input on
    the module
  + nautilus and eel have already been ported.
  (Note: gio is part of glib 2.15.x)
  - Not quite keeping up with the GNOME schedule release-wise yet, but
    it's not too far, Alex has a good track record in this area, and
    nautilus/eel already depend on it.
  * I vote yes

empathy:
  - Multiple people expressing concerns with security (Sven, Gustavo), and
    which apparently could be fixed by just using gnome-keyring.
  - Some votes against based on too many things being in "not ready yet" status
  - licensing issues have not and possibly cannot be resolved (uses gossip code,
    which is GPL; see particularly
    http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00566.html
    and
    http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00571.html
    )
  - Various concerns about duplicating existing functionality
    elsewhere (particularly ekiga)
  - Some concerns about documentation
  + May be the best module release-wise; they get releases out.
  + Many people really like the direction and new feature that empathy
    and related modules can bring
  * I vote no; the module looks really cool, but I don't see how it
    makes sense to move forward including it until the licensing issue
    is completely fixed.  So far, it has only been partially
    addressed.  I'm guessing the other negatives could mostly be addressed
    during the time it takes to fix the licensing issue, and then it'd be
    ready for proposal again.

external deps:
  PolicyKit/PolicyKit-gnome:
    * Module proposal was retracted since no hard dependency is yet
      needed/wanted.  Moot point.
  ndesk-dbus, ndesk-dbus-glib:
    ? As a side note, it is interesting to note that mono is missing from the
      list of external dependencies, as is python.  They should probably both be
      added.  However, mono should be added in a separate section on that page
      (perhaps named "only for modules with an explicitly approved
      mono dependency"?), given the special rules that apply with it
      (see
      http://mail.gnome.org/archives/devel-announce-list/2006-August/msg00000.html
      for a refresher.)
    + Looks like it'd be positive from a security perspective and mono modules
      would like to use it.
    - We have too much mono in the desktop and explicit dependencies already.
    ? It really makes no sense as a standard external dependency given
      the special case that mono is in; it'd need to go in the special
      section mentioned above for mono.
    * I think we should just rip Tomboy out of the desktop and change
      the rule about mono dependencies to not allow any; I've felt
      that way ever since the Microsoft/Novell deal.  If we don't go
      that route, I guess it'd be better to have the security
      enhancements that come by avoiding copy-paste of code and thus I
      could see adding this to the special section of the external
      dependencies.
  bump hal to 0.5.10 (needed by gvfs)
  totem-pl-parser
    - don't understand this one.  Or was it meant to go in the desktop?
      Whatever; it seems like just a splitting of the totem module, I'm fine
      with adding it.