Feature Freeze approaching

Wed Aug 26 09:28:19 UTC 2009

On Wed, Aug 26, 2009 at 5:00 AM, Steve Dodier <sidnioulz at gmail.com> wrote:

> 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:
>>
> <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).
>

Great. I'll seed ristretto in place of gpicview.

>
>>> *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).
>

Sounds good to me.

>  *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.
>

Okay. We'll continue to monitor this and take action as necessary. I'm happy
to hear that you've found Ali (aka upstream) is responsive and easy to work
with.

*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 !

Right-o. Thanks for bringing this up. We'll need to fix gnome-screensaver to
not rely on gnome-session for detecting when we're idle.

*Network Browsing
*
 Not currently a specification for karmic but I'd like to bring this up
because samba browsing is one of the most requested features even though we
shipped gigolo in Jaunty to provide this functionality. I'd like to apply
the Thunar samba patch created by a Xubuntu community member (DanielM). It
works well, has been around for awhile, and once Thunar is released with GIO
support we'll no longer need it and can drop it. I think it would be nice to
try this out - we can always revert if it doesn't work out. If no one
objects, I'll see about doing this and uploading to a PPA.

Cheers,

-- 
Cody A.W. Somerville
Software Systems Release Engineer
Foundations Team
Custom Engineering Solutions Group
Canonical OEM Services
Phone: +1-781-850-2087
Cell: +1-506-471-8402
Email: cody.somerville at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/xubuntu-devel/attachments/20090826/f16128ec/attachment.html>