Re: Release Team meeting at the beginning of January
- From: "Elijah Newren" <newren gmail com>
- To: "Andre Klapper" <ak-47 gmx net>
- Cc: release-team gnome org, Lucas Rocha <lucasr gnome org>
- Subject: Re: Release Team meeting at the beginning of January
- Date: Sat, 5 Jan 2008 23:15:43 -0700
On Jan 2, 2008 7:03 AM, Andre Klapper <ak-47 gmx net> wrote:
> > > > > i propose sunday 6th, 1900 UTC.
> > So Sunday 6th?
> seems like guenther, olav, fcrozat, vuntz and /me have time, that's a
> 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
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
- 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
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
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.
? 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.
? 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.
- 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.
? 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
+ Matthias and Bastien were strongly in favor. I saw no one vote
+ 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
- Uses launchpad instead of gnome or freedesktop hosting services; this is
+ 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?
+ This has been sorely needed for a long time
+ Has been discussed extensively on gtk-devel-list with lots of input on
+ 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
- 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
- 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.
* Module proposal was retracted since no hard dependency is yet
needed/wanted. Moot point.
? 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
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
bump hal to 0.5.10 (needed by gvfs)
- 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.
] [Thread Prev