Feature Freeze approaching

Wed Aug 26 09:00:01 UTC 2009

2009/8/26 Cody A.W. Somerville <cody-somerville at ubuntu.com>

> Hello,
>
> On Sun, Aug 16, 2009 at 9:25 AM, Steve Dodier <sidnioulz at gmail.com> wrote:
>
>> Hello folks,
>> Feature freeze is going to occur in 11 days from now, which leaves little
>> time to take decisions about the applications and features we want in
>> Xubuntu Karmic. Several specs have been written, about default applications,
>> but unfortunately two of them have not been followed by any action/decision
>> so far (image viewer / mail client).
>>
>
> Feature Freeze is fast approaching, this is true. Luckily, this freeze is
> not as "solid" as it is for say Ubuntu because of our smaller contributor
> base. One of the main benefits of the freeze is to help start locking down
> and ensuring proper coordination between developers to ensure a consistent
> and well thought out release. Our smaller contributor base allows us to do
> this much easier allowing us to make larger, well thought out exceptions to
> the freeze that would be difficult to do in the scale Ubuntu operates. As
> per an earlier e-mail to this list today, both Lionel and myself have the
> ability to approve freeze exceptions.
>
> This being said, please do not get the impression that we're not heading
> into feature freeze - as we most certainly are. So kudos to Steve for taking
> the time to write this e-mail to get the ball rolling in time.
>
> <snip>
>
>
>>
>> *Default Image Viewer*
>>
>> https://wiki.ubuntu.com/Xubuntu/Specifications/Karmic/DefaultImageViewer
>>
>> As we know, Stephan (developer of Ristretto) is re-designing Ristretto's
>> features prior to writing it's next release, so we can consider the current
>> upstream release as the final one for Karmic (unless we spot critical bugs /
>> unwanted behaviour and take upon ourselves to write a patch for it). Maybe
>> Stephan can tell us more about what is expected for Ristretto in the
>> following weeks. Ristretto is slightly heavier than Gpicvieww, but it does
>> have more features, and if we change, we can also bring a bigger userbase to
>> Ristretto, thus helping finding (and fixing) bugs. On a purely distro point
>> of view, this would allow us to provide our users with a more stable and
>> feature rich image viewer for our next LTS.
>>
>
> In my opinion, Ristretto has come a long way and Stephan, the maintainer,
> has proven to be hugely responsive. Since there is little risk to switching
> back to our current image viewer if ristretto doesn't work out, I'd be happy
> to switch to ristretto if we're going to be using the version he was
> demonstrating at UDS to help get it some wider testing and to help determine
> if its suitable to include in the release. If the version he was
> demonstrating at UDS won't be available in time for Karmic, I'd strongly
> recommend sticking with gpicview as the new 0.2 release seems to address a
> number of the usability issues found in 0.1
>

The release we saw at the UDS is already out, and it looks like it's the
version that is already uploaded in Karmic. The faster we switch the more we
have a chance to spot annoying things during the A6/Beta and to have time to
write a debian patch to fix them (and to file a bug in xfce's bugzilla, of
course, but it's likely that Stephan will not release any version soon, so I
think any fix should come in the form of a debian patch till we have a new
version to upload).

>
>
>> *Default Mail Client*
>>
>> https://wiki.ubuntu.com/Xubuntu/Specifications/Karmic/DefaultMailClient
>>
>> I'm not using mail clients at all, so I don't have an opinion about this,
>> but it would be good to make a choice about the mail client. All I can say
>> is that I don't think we will be able to do anything else than providing
>> these applications "as-is" for this release. I'm not even confident about
>> possible libindicate support, since the upstream libindicate developers
>> still didn't separate libindicate from indicator-applet (which depends on
>> GNOME). This also means we probably won't be able to get
>> indicator-applet-xfce in Karmic. The next release being an LTS, I think
>> Karmic could be a release of choice for introducing such changes and for
>> getting user feedback, though.
>>
>
> Switching to clawsmail has been a frequent request and I think this
> wikipage does a good job at comparing it to Thunderbird. . It may very well
> be desirable for us to do so but I think its too late in the cycle for this
> sort of change. I would have had liked to have made this change and had it
> included in an alpha before feature freeze to feel comfortable. What do
> others think?
>

I agree with that, I think it's too late to change now for such a big
application (which is quite a shame).

>
>
>
>> *Default Power Manager*
>>
>>
>> There is no spec for this one so far, but are we able to tell what we want
>> to do on Xfce4-power-manager in order to use it for Karmic ? Cody's been
>> working on RAM usage, what else is lacking ? I'll try to find time for
>> improving battery notifications to something such as lp #399492. We're also
>> lacking PolicyKit support, as far as I understand. I don't think this is a
>> realistic goal for Karmic, but is someone willing to work on it for Karmic+1
>> ?
>>
>
> I was really hoping we could include xfce4-power-manager for karmic and it
> may still be a realistic goal. Unfortunately, I've noticed some weirdness
> like my laptop running out of battery because xfce4-power-manager failed to
> notify me I was low on battery plus it is unnecessarily heavy on memory not
> to mention currently crashes on logout (fix hopefully being uploaded soon).
>
> I think we might want to switch back to gnome-power-manager for karmic and
> look to have xfce4-power-manager ready for karmic+1 as Steve suggests.
>
>
I think you misunderstood me :p I think xfce4-power-manager may be already
suitable for Karmic, even if it's not as shiny as g-p-m for stuff such as
PolicyKit. At the moment, indeed xfce4-power-manager has some unknown bugs,
but since g-p-m just switched to DeviceKit, it has quite a lot of sweet bugs
too, currently (which I had the time to notice when I was running karmic's
g-p-m). Now, if we wait for Karmic +1 to switch, it means the userbase of
xf-p-m will be slightly slower, and thus less bugs will likely have been
discovered and fixed in xf-p-m, which means it'll be less bugfree in
Karmic+1, which is a LTS.

My proposal is to use xf-p-m now, "at our own risk", as the default in
Karmic, and to make sure to fix any bugs and to bring PolicyKit for Karmic
+1. As for memory usage, I talked to Ali (the upstream dev) about it and he
said that he was looking into it. I also suggested some UI improvements that
he seems to be agreeing with, so xf-p-m's GUI should be more user-friendly,
the backend shouldn't be more buggy than g-p-m's, and we're likely to be
able to help Ali make it better before Debian stable's freeze and the next
LTS Xubuntu.

>
>> *GDM, gnome-screensaver*
>>
>>
>> What are we doing about these ? I don't believe we want to depend on
>> gnome-session, but it is really time to decide about what to use as a
>> replacement for these two applications (and whether we can use something
>> unsecure / ugly and fix the security flaws / GUI).
>>
>
> I'm going to upload gdm-2.20 tomorrow and have us use that for karmic.
>

Cool :)

>
>
>
>> *NotifyOsd*
>>
>> *https://wiki.ubuntu.com/Xubuntu/Specifications/Karmic/NotifyOsd*
>> *This is mostly done; I have working code for xfconf support, and for
>> text size / bubble colour customization. It will only be lacking a GUI,
>> because I just don't have the time for it, but I believe this should be
>> feasible in Karmic+1. By the meanwhile, I will take the time to write a wiki
>> page about how to customize NotifyOsd's appearence, and commands to turn the
>> white on black to some tooltip-like look and feel. I am very sorry, Charlie,
>> for not being able to write a GUI for it right now. I didn't expect to not
>> code at all for two weeks because of personal life agitation.*
>>
>
> I'll have to look into the status of this specification further before
> commenting. However, I don't think feature freeze will be a blocker to
> moving forward on this if all is good.
>
>
>> **
>> *I may have forgotten stuff about what needs to be addressed for feature
>> freeze, feel free to add it to the conversation.*
>>
>
> *Slim down the Xubuntu Session*
>
> https://blueprints.launchpad.net/xubuntu-desktop/+spec/xubuntu-karmic-session-slim-down
>
> I had hoped to have much more done on this by now but work has been
> horribly hectic. I intend to take some more vacation time in September to
> have a half a week or so to devote to Xubuntu. I have, however, been able to
> do quite a bit of research on this and have a list of ideas/things to try
> which I'll try and get documented on a wikipage soon.
>
> Unfortunately, I think that the wonderful ease of us that Xubuntu offers
> over say Debian with Xfce (a great distro none the less in its own respects)
> comes with a cost.
>
> Cheers,
>
> --
> Cody A.W. Somerville
>

*Screensaver*
I'd also like to add a word about the screensaver. I've been using
Xscreensaver alongside XFPM lately and I'm quite satisfied with it apart
from it's not-sexy-at-all unlock dialog. The good news is that we could
customize it to an extent where it would look decent with the default
Xubuntu theme. The bad news is that a11y-wise it would still completely
suck.

The author of Xscreensaver has written a document about how to use another
toolkit with Xscreensaver, in a secure maneer (he considers kscreensaver and
gnome-screensaver to be two big security holes - and both are forks from his
app). It requires A LOT of work, and Xorg knowledge that I don't have. Maybe
it's time to get in touch with other XFCE distro devs and to try to find
someone who has this X.org knowledge. Anyway, gnome-screensaver now depends
gnome-session, and I don't wanna wait to see what it'll depend on in
Karmic+1.

We can clearly not fix a11y issues of Xscreensaver for Karmic, but i'm still
interested in seeing what can be done about it in 2010 !

And finally, a word about Exaile. Those of you who used it recently will
have noticed that the 0.3.0 release is not bugfree at all. We plan a big
bugfix release in september, that will fix all the most annoying bugs, and
that should also improve ressource usage and fix most of those damn memory
leaks. I expect this bugfix release to make Exaile better than Banshee & RB
for performances. So, please don't panic ! :P

-- 
Steve Dodier
OpenPGP : 1B6B1670
IRC : SiDi on irc.freenode.net
Jabber : sidi at im.apinc.org
steve.dodier at gmail.com
https://launchpad.net/~sidi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/xubuntu-devel/attachments/20090826/6415f01c/attachment.html>