FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Desktop

 
 
LinkBack Thread Tools
 
Old 10-15-2012, 07:43 AM
Didier Roche
 
Default Discussing PS-related product processes

Hey everyone,



as you probably know already, PS is our upstream for a lot of
desktop components nowadays (Unity, compiz, webapps, indicators,
multi touch stack…).

The past cycle has been a real ride in term of features, which spawn
the release team, translation team and documentation team with
FFe/UIFe. We need to discuss a way to ease the process in both ways
with all involved parts.



Seeing the importance of those components on our stack today, I
think for instance that having a standing FF/UIF exception as we
have for GNOME components in ubuntu will make sense. However, the
counter-part will be that PS will work on getting things landing
only when they are ready, to avoid further and further refinements
(and additional documentation changes) as we had in the past just to
"match the date gate". So this one can clearly be a win-win
situation.



Also, I want to discuss about what can land in a SRU. Little (few
pixel move) change, not really impacting the documentation may want
to be considered. We currently have 2 examples we can discuss in the
session:



- https://bugs.launchpad.net/unity/+bug/1043808
(Dash:

Preview activation doesn't have instant feedback). Design worked on
a spinner to partially address this one. This is a behavior change
in some way, for a transient state, however it can be completely
acceptable in a SRU as it will make the quantal experience better
and don't change doc/add new strings, and so on.



- Another one is the ribbon on the application lens for
software-center content. This one is giving (due to pixelized images
with the magazines) a lot of headaches to design and they would want
to remove it. This specific case is an UI change, but doesn't seem
it would impact the understanding of the lens.



We can base the UDS discussion on those examples to see how we can
get the process smoother and more reliable for everyone in the next
cycle and going on.



Cheers,

Didier



--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 10-15-2012, 08:21 AM
Omer Akram
 
Default Discussing PS-related product processes

In case anyone does not know what PS stands for (which I am sure many don't). Its Product Strategy previously called DX-team.

On Mon, Oct 15, 2012 at 12:43 PM, Didier Roche <didrocks@ubuntu.com> wrote:







Hey everyone,



as you probably know already, PS is our upstream for a lot of
desktop components nowadays (Unity, compiz, webapps, indicators,
multi touch stack…).

The past cycle has been a real ride in term of features, which spawn
the release team, translation team and documentation team with
FFe/UIFe. We need to discuss a way to ease the process in both ways
with all involved parts.



Seeing the importance of those components on our stack today, I
think for instance that having a standing FF/UIF exception as we
have for GNOME components in ubuntu will make sense. However, the
counter-part will be that PS will work on getting things landing
only when they are ready, to avoid further and further refinements
(and additional documentation changes) as we had in the past just to
"match the date gate". So this one can clearly be a win-win
situation.



Also, I want to discuss about what can land in a SRU. Little (few
pixel move) change, not really impacting the documentation may want
to be considered. We currently have 2 examples we can discuss in the
session:



- https://bugs.launchpad.net/unity/+bug/1043808
(Dash:

Preview activation doesn't have instant feedback). Design worked on
a spinner to partially address this one. This is a behavior change
in some way, for a transient state, however it can be completely
acceptable in a SRU as it will make the quantal experience better
and don't change doc/add new strings, and so on.



- Another one is the ribbon on the application lens for
software-center content. This one is giving (due to pixelized images
with the magazines) a lot of headaches to design and they would want
to remove it. This specific case is an UI change, but doesn't seem
it would impact the understanding of the lens.



We can base the UDS discussion on those examples to see how we can
get the process smoother and more reliable for everyone in the next
cycle and going on.



Cheers,

Didier




--

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
 
Old 10-15-2012, 03:20 PM
Micah Gersten
 
Default Discussing PS-related product processes

On 10/15/2012 02:43 AM, Didier Roche
wrote:




Hey everyone,



as you probably know already, PS is our upstream for a lot of
desktop components nowadays (Unity, compiz, webapps, indicators,
multi touch stack…).

The past cycle has been a real ride in term of features, which
spawn the release team, translation team and documentation team
with FFe/UIFe. We need to discuss a way to ease the process in
both ways with all involved parts.



Seeing the importance of those components on our stack today, I
think for instance that having a standing FF/UIF exception as we
have for GNOME components in ubuntu will make sense. However, the
counter-part will be that PS will work on getting things landing
only when they are ready, to avoid further and further refinements
(and additional documentation changes) as we had in the past just
to "match the date gate". So this one can clearly be a win-win
situation.




AIUI, GNOME only has a MicroRelease exception, not a standing FF/UIF
exception.* If Feature Freeze were targeted for Features, then there
are about 2 months left in the cycle to clean up any bugs.* Also,
the time between Feature Freezes is about 6 months, so if their
schedule were adjusted to focus on Feature Freeze instead of the
release date, you'd still get about 6 months of feature work into
the release (it also means you get 2 months of polish as well).*
Obviously, if something slips, there's still the exception process,
but that should be the exception, not the rule.



Thanks,

Micah



--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 10-15-2012, 03:45 PM
Jeremy Bicha
 
Default Discussing PS-related product processes

Adding ubuntu-doc to the CC list as this seems more a FF/UIFE
discussion than a -desktop discussion.

On 15 October 2012 03:43, Didier Roche <didrocks@ubuntu.com> wrote:
> Hey everyone,
>
> as you probably know already, PS is our upstream for a lot of desktop
> components nowadays (Unity, compiz, webapps, indicators, multi touch
> stack…).
> The past cycle has been a real ride in term of features, which spawn the
> release team, translation team and documentation team with FFe/UIFe. We need
> to discuss a way to ease the process in both ways with all involved parts.
>
> Seeing the importance of those components on our stack today, I think for
> instance that having a standing FF/UIF exception as we have for GNOME
> components in ubuntu will make sense. However, the counter-part will be that
> PS will work on getting things landing only when they are ready, to avoid
> further and further refinements (and additional documentation changes) as we
> had in the past just to "match the date gate". So this one can clearly be a
> win-win situation.

I believe standing feature freeze exceptions need a history of "doing
the right thing", which is not how I would describe what happened for
quantal. Otherwise, it seems to me that giving the developers and
designers more official permission to break the freezes they are
already breaking would make the problems worse.

Or to put it another way, PS really really needs to land these
features closer to the beginning of a cycle in the regular archives
(not a PPA) to get near-real-world testing so that there is time for
polishing. I wonder if the emphasis on keeping Ubuntu+1 working has
gone too far and if we are actually pushing Ubuntu developers to land
new features late.

> Also, I want to discuss about what can land in a SRU. Little (few pixel
> move) change, not really impacting the documentation may want to be
> considered. We currently have 2 examples we can discuss in the session:
>
> - https://bugs.launchpad.net/unity/+bug/1043808 (Dash: Preview activation
> doesn't have instant feedback). Design worked on a spinner to partially
> address this one. This is a behavior change in some way, for a transient
> state, however it can be completely acceptable in a SRU as it will make the
> quantal experience better and don't change doc/add new strings, and so on.

Adding a "busy" spinner seems harmless enough and wouldn't impact docs
or translations. I don't think it would make much of a difference for
video reviews. On the other hand, I wouldn't want to see animations
change near Final Freeze or after.

> - Another one is the ribbon on the application lens for software-center
> content. This one is giving (due to pixelized images with the magazines) a
> lot of headaches to design and they would want to remove it. This specific
> case is an UI change, but doesn't seem it would impact the understanding of
> the lens.

I need more information about that issue.

> We can base the UDS discussion on those examples to see how we can get the
> process smoother and more reliable for everyone in the next cycle and going
> on.
>
> Cheers,
> Didier

Thanks,
Jeremy

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

Thread Tools




All times are GMT. The time now is 12:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org