Re: [Desktop 12.10 Topic] Quality, testability for the desktop components

[Rick Spencer]

Sebestien,

Are you looking for discussion on these topics on this list? If so, I would
suggest that Libre Office might be a good candidate for us to offer regular
integration tests. I know that Libre Office has a test suite, it might be
very useful to run these tests daily on Ubuntu (to discover when Ubuntu
breaks LO) and it might be useful to run tests on upstream changes (to
discover when LO breaks Ubuntu).

Thoughts?

Cheers, Rick

On Wed, Apr 18, 2012 at 10:39 AM, Sebastien Bacher wrote:

> Hey,
>
> The Canonical upstream teams did some good progresses on testing and
> quality this cycle, that's a good step for the Ubuntu Desktop quality, we
> still rely on quite some components from other upstreams though that didn't
> engage into a such process yet though (those who looked at
> gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably know
> what I mean there). I would like to see if we can work on our side and with
> upstream to get those automated tested in some ways.
>
> It would be also nice to see regular run and report of the testsuits for
> other components which already have one (i.e glib, gtk) and some testing of
> their rdepends before upload.
>
> Cheers,
> Sebastien Bacher
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.**com 
> https://lists.ubuntu.com/**mailman/listinfo/ubuntu-**desktop
>
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation

[Jo-Erlend Schinstad]

Absolutely. Indeed it should. Not only for different types of users, but
for different "trails" as well. Again I use Unity as example. Suppose
you want to start developing. You've covered the basics of the language,
and now you want make something you can show your friends. So you do to
the docs page > developing > Python > Desktop > Unity. There you find
the Unity Specification 1.0 Documentation, with Indicators, Launcher,
and everything. You learn how to make lenses and scopes, and there's
lots of them to make in your area, so you just keep going and become
really good at it. Then you begin to wonder how it works under the
scene. So you go to the next level, which is the DBus architecture.
You're still on the same trail, mind you. So you lean how the DBus
bindings work in Python and then you move on to the DBus Unity API
itself. That's the exact same document you'd end up with if you'd
started with Vala, because after all, it's the same thing. If you've
followed the Python trail already, you'll just get the "Oh, I know
this!" feeling, which isn't a bad thing.

So the main documentation tree might be grouped in libraries and then
under language, as is the case on dev-u-c now, but to the user, it'll be
presented by their interests, as trails. The documentation isn't just
something that comes with the tools. The documentation itself is its own
product with its own goals. 

Here's an example for you; I recently switched to BtrFS in Precise. I
needed to learn, and I ended up here:
https://help.ubuntu.com/community/btrfs. As far as I can tell, there's
nothing particularly wrong with that information. But then, this stuff
is new to me, so how would I know? It doesn't inspire confidence.
"Ubuntu-specific subvolume layout in 11.04 and later"? I'm using 12.04!
But I'm very familiar with this, so I scrolled down towards the bottom
of the page to see when it was last updated. Just a few days ago. Nice.
And I can see the page history. On my way there I noticed that most of
the information is for 8.10! This is a filesystem we're talking about. I
really need to be confident about this information, and the mere mention
of 8.10 makes me suspicious.

This page was marked out of date nearly four years ago:
https://wiki.ubuntu.com/UbuntuOnMac. Why does it even exist? I assume
it's simply because noone has the overview to systematically make sure
pages like that is either updated or deleted. If noone has an overview,
then it's difficult to attract contributors as well. Specific tasks
makes it much easier. And by update, I don't mean adding new info on
top, leaving older info below. One page per version. Reviewed. Obviously
Valid.

Facts aren't good enough anymore. We need to design documentation for
the user. And that can't just be about deleting old wiki pages. We need
a goal. A new way of thinking about documentation as a whole.

Jo-Erlend Schinstad



-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation

[Bryce Harrington]

On Thu, Apr 19, 2012 at 03:51:02AM +0200, Jo-Erlend Schinstad wrote:
> Den 19. april 2012 03:11, skrev Jeremy Bicha:
> > Your topic mixes developer docs, entry-level user docs, and "power
> > user" docs. Each of those needs a different approach and I think it's
> > simpler to tackle them as three mostly separate things. Also, if
> > you're going to discuss documentation, you should probably include the
> > docs team (CC'd now) as that's where people interested in that read. 
> 
> The point is the exact opposite. We shouldn't split documentation up
> into completely unrelated pieces. That is the problem. We should
> consider it a whole. One single tree of knowledge. Before a release, we
> should be able to walk the entire tree and make sure all documents are
> Obviously Valid. You don't have to specialize in a single topic in order
> to do that. It just requires effort, and for that, it must be obvious
> what to do.
> 
> With different docs being at different places, organized in different
> ways, maintained by "unrelated" teams and mixing versions, it's very
> difficult to do any kind of quality assurance or to do anything in a
> systematic way – as a whole.

Well, both of you make valid points.

Can the documentation be *maintained* in a single tree, yet split out by
user type (one set for my mom, one for me)?

Bryce

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation

[Jo-Erlend Schinstad]

Den 19. april 2012 03:11, skrev Jeremy Bicha:
> Your topic mixes developer docs, entry-level user docs, and "power
> user" docs. Each of those needs a different approach and I think it's
> simpler to tackle them as three mostly separate things. Also, if
> you're going to discuss documentation, you should probably include the
> docs team (CC'd now) as that's where people interested in that read. 

The point is the exact opposite. We shouldn't split documentation up
into completely unrelated pieces. That is the problem. We should
consider it a whole. One single tree of knowledge. Before a release, we
should be able to walk the entire tree and make sure all documents are
Obviously Valid. You don't have to specialize in a single topic in order
to do that. It just requires effort, and for that, it must be obvious
what to do.

With different docs being at different places, organized in different
ways, maintained by "unrelated" teams and mixing versions, it's very
difficult to do any kind of quality assurance or to do anything in a
systematic way – as a whole.

But for documentation to be seen as a whole, related software must
sometimes also be seen as connected. That's why I replied here, since
Unity is my main example. It's not simply about documentation. For
instance, if I want to learn how to write a Python application for
Unity, I have to read this:

Unity-5.0
AppIndicator3-0.1
Indicate-0.7
...

They are obviously connected, but it's not at all obvious in versioning
or documentation. I'd like to see something more like Unity
Specification 1.0 Documentation, which would include those technologies.
I'd like to see a Vala/GTK implementation of the Dash, for instance. And
it'll have completely different versions than those listed above.

This means that we can't just adapt documentation to software, but also
adapt software to be more documentable in a way. I don't think this has
to be very difficult, but it requires discussions and decisions. Seeing
the bigger picture.

The desktop is the most visible, most important aspect in this regard.

Jo-Erlend Schinstad

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation

[Jeremy Bicha]

On 18 April 2012 20:39, Jo-Erlend Schinstad
 wrote:
> I think it's necessary for Ubuntu to take documentation to another level.
>
> When I first started with Ubuntu, I really wanted to learn how it all
> fit together. I have used computers most of my life so I'm accustomed to
> reading documentation and I was perfectly willing to dive right in. But
> it just wasn't that easy, not necessarily because of the information
> itself, but because of how it was organized and presented. There were no
> clear starting point and no trails to follow. There were broken links on
> wikis, and outdated information lying around. Much of the documentation
> would only use version numbers, and have no easy way to see when it was
> last updated, or if it had been superseeded. Confusion reduces peoples
> ability to learn.
>
> To me, this is The Issue with Ubuntu. If we're really going to succeed
> in taking Ubuntu «across the chasm», then we must make it easy for the
> curious to become users and for the enthusiasts to become power-users.
> For this to happen, we need to do something drastic about the way
> documentation is presented. I think Ubuntu Documentation must:
>
> * Have an obvious starting point
> * Lead to the next step
> * Be instantly recognizable as valid or invalid
> * Be grouped when applicable
> * Primarily focused on LTS
> * Reviewed for each release (hence the point above)
> * Easy to contribute to by reporting issues
> * Be not only API docs, but contain readable text.
>
> developer.u-c and help.u-c has improved a lot in this regard, but not
> enough. Look at this page first:
> http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader,
> I can come across issues that I'm not able to read, but will help
> improve the documentation. I should have a very easy way to report it.
> There's no way at all on that site, though at the very bottom, I can
> submit a tutorial.
>
> Another example, look at this page:
> http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html.
> Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still
> valid? There's no way to know. We shouldn't rely on people to trust that
> if not stated otherwise, it is valid. This is the web. There are
> millions of old and unmaintained documents out there. It must be obvious
> that it is valid. This also helps anyone recognize invalid
> documentation, enabling them to report it or fix it.
>
> And what if my primary focus is developing an application for LXDE and I
> want to use only an indicator? In this specific case, I'd use a separate
> version for the API docs and call it Unity Specification 1.0 for 12.04.
> Then if there are any changes between now and 14.04, I'd call that 2.0.
> For versions in between I'd add 1, 2 or 3. So, if there are API changes
> i 13.04, I'd expect to find a Unity Specification 1.2 and that it would
> clearly show the differences between 1.2 and 1.0, considering the newest
> LTS the
>
> In the case of Unity-5.0 for Python above, I'm not sure I'd call that
> Documentation. That is the convention, but I'm not sure that's what
> people expects. I'd call that document a Specification. For
> Documentation, I would expect more readable text, explaining what it's
> for and how it is used.
>
> Enum: Unity.FilterRenderer
> CHECK_OPTIONS_COMPACT 4
>
> Right. How do I use it? .)
>
> Jo-Erlend Schinstad

Your topic mixes developer docs, entry-level user docs, and "power
user" docs. Each of those needs a different approach and I think it's
simpler to tackle them as three mostly separate things. Also, if
you're going to discuss documentation, you should probably include the
docs team (CC'd now) as that's where people interested in that read.

Thanks,
Jeremy Bicha

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

{Desktop 12.10 Topic] Holistic approach to Ubuntu documentation

[Jo-Erlend Schinstad]

I think it's necessary for Ubuntu to take documentation to another level.

When I first started with Ubuntu, I really wanted to learn how it all
fit together. I have used computers most of my life so I'm accustomed to
reading documentation and I was perfectly willing to dive right in. But
it just wasn't that easy, not necessarily because of the information
itself, but because of how it was organized and presented. There were no
clear starting point and no trails to follow. There were broken links on
wikis, and outdated information lying around. Much of the documentation
would only use version numbers, and have no easy way to see when it was
last updated, or if it had been superseeded. Confusion reduces peoples
ability to learn.

To me, this is The Issue with Ubuntu. If we're really going to succeed
in taking Ubuntu «across the chasm», then we must make it easy for the
curious to become users and for the enthusiasts to become power-users.
For this to happen, we need to do something drastic about the way
documentation is presented. I think Ubuntu Documentation must:

* Have an obvious starting point
* Lead to the next step
* Be instantly recognizable as valid or invalid
* Be grouped when applicable
* Primarily focused on LTS
* Reviewed for each release (hence the point above)
* Easy to contribute to by reporting issues
* Be not only API docs, but contain readable text.

developer.u-c and help.u-c has improved a lot in this regard, but not
enough. Look at this page first:
http://developer.ubuntu.com/resources/platform/api/12-04/. As a reader,
I can come across issues that I'm not able to read, but will help
improve the documentation. I should have a very easy way to report it.
There's no way at all on that site, though at the very bottom, I can
submit a tutorial.

Another example, look at this page:
http://developer.ubuntu.com/api/ubuntu-12.04/python/Unity-5.0.html.
Right, but that's Ubuntu 5.0. I was looking for 5.10. Is this still
valid? There's no way to know. We shouldn't rely on people to trust that
if not stated otherwise, it is valid. This is the web. There are
millions of old and unmaintained documents out there. It must be obvious
that it is valid. This also helps anyone recognize invalid
documentation, enabling them to report it or fix it.

And what if my primary focus is developing an application for LXDE and I
want to use only an indicator? In this specific case, I'd use a separate
version for the API docs and call it Unity Specification 1.0 for 12.04.
Then if there are any changes between now and 14.04, I'd call that 2.0.
For versions in between I'd add 1, 2 or 3. So, if there are API changes
i 13.04, I'd expect to find a Unity Specification 1.2 and that it would
clearly show the differences between 1.2 and 1.0, considering the newest
LTS the 

In the case of Unity-5.0 for Python above, I'm not sure I'd call that
Documentation. That is the convention, but I'm not sure that's what
people expects. I'd call that document a Specification. For
Documentation, I would expect more readable text, explaining what it's
for and how it is used.

Enum: Unity.FilterRenderer
CHECK_OPTIONS_COMPACT 4

Right. How do I use it? .)

Jo-Erlend Schinstad











-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.10 Topic] Quality,testability for the desktop components

[Sebastien Bacher]

Hey,

The Canonical upstream teams did some good progresses on testing and 
quality this cycle, that's a good step for the Ubuntu Desktop quality, 
we still rely on quite some components from other upstreams though that 
didn't engage into a such process yet though (those who looked at 
gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably 
know what I mean there). I would like to see if we can work on our side 
and with upstream to get those automated tested in some ways.


It would be also nice to see regular run and report of the testsuits for 
other components which already have one (i.e glib, gtk) and some testing 
of their rdepends before upload.


Cheers,
Sebastien Bacher

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

Re: [Desktop 12.10 Topic] Deprecate language-selector

[Martin Pitt]

Sebastien Bacher [2012-04-18 10:12 +0200]:
> That's a leftover from precise but it would be good to use the
> upstream "region" panel code and deprecate language-selector next
> cycle (better to have capplets integrated in system settings that
> those "launchers" for standalone apps there).

+1. The main missing bit here is integrating the ibus module chooser.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.10 Topic] Login speed improvements

[Sebastien Bacher]

Hey,

Yet another leftover from precise, not much to discuss as well, rather a 
"just do it". We did a bit of work this cycle but didn't go far, there 
is still room for improvement especially with nautilus, compiz.


Cheers,
Sebastien Bacher

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.10 Topic] Old libraries cleaning

[Sebastien Bacher]

Hey,

Not so much a discussion topic that a just do it, but I think we might 
get close of dropping pygtk, gtk2 and gconf from the CD so maybe let's 
see how much progress we can do this cycle with that?


Cheers,
Sebastien Bacher

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.10 Topic] Deprecate language-selector

[Sebastien Bacher]

Hey,

That's a leftover from precise but it would be good to use the upstream 
"region" panel code and deprecate language-selector next cycle (better 
to have capplets integrated in system settings that those "launchers" 
for standalone apps there).


We will maybe need some design input on the ui and to finish the coding 
part started this cycle.


Cheers,
Sebastien Bacher



--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

[Desktop 12.10 Topic] The future of third-party driver installation

[Martin Pitt]

Hello Desktop fans,

We have had Jockey for quite a while now to perform the installation
of proprietary (e. g. NVidia), alternative (e. g. fglrx vs.
fglrx-updates), third-party (e. g. from openprinting.org) drivers.

However, I feel that this needs some refreshing:

 * The code base of Jockey is quite complex, it was meant for a lot
   more stuff than we are actually using it for. We also came up with
   simpler ways of mapping hardware to packages, mostly with
   additional tags in the apt package lists. We also have a more
   upstream friendly API in PackageKit/aptdaemon now to do this kind
   of thing.

   We can simplify the jockey code base and backend logic a lot (up
   to the extend of completely dropping it) by making full use of
   above new technologies and dropping the extra features we don't
   use. The exception is the openprinting.org detection, but that
   could go into system-config-printer or python-cups directly.

 * We install some drivers (like Broadcom wifi) straight from Ubiquity
   now, which certainly makes sense for devices where there is no free
   alternative. For the others (e. g. NVidia) we pop up a notification
   and offer to install them. I'd like to walk through the current UI
   and discuss how this could be made more steamlined and less
   confusing (e. g. for NVidia it can potentially offer 6 different
   drivers for you!)

 * We might consider merging the jockey UI functionality, which is
   mostly a shallow GUI around "install that package" now) into
   software-center, control-center, or something similar to the codec
   installer. I'd again appreciate if someone from the design team
   could participate in that (hello Matthew!).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
-- 
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop