drago01 drago01 at
Wed Sep 22 10:48:05 UTC 2010

On Wed, Sep 22, 2010 at 12:35 PM, Tomas Mraz <tmraz at> wrote:
> On Tue, 2010-09-21 at 15:47 -0600, Kevin Fenzi wrote:
>> Greetings.
>> I'd like to ask for feedback and helping cleaning up an updates policy
>> draft page:
>> How can we clarify the language or the layout of the page to be more
>> clear? Are there places that it could be more like the existing package
>> update howto page? Could we be more detailed about what bodhi enforces
>> and whats just good practice?
>> Are there other exceptions cases that could be covered that you can
>> think of?
>> NOTE that this is a draft. I'd like constructive feedback.
>> If we can get something that looks ok by next week, FESCo would like to
>> approve this and put it in place.
>> Please do try and keep technical and constructive in replies, pretty
>> please? With a cherry on top?
> - Avoid changing the user experence if at all possible. - this is too
> strong condition. In some cases fixing a bug might inevitable change the
> user experience and in some cases for example the user experience might
> be just severally improved with the new release. So IMO this should be
> reworded with much less strong wording such as 'Avoid major changes and
> worsening the user experience if at all possible.'

Define "worsening" being different by itself is "worsening" for a lot of people.

> This example is IMO wrong:
> - WebKit requires an update to solve a security problem. This requires
> updating Midori to a version with some minor menu layout changes. This
> would be a judgement call based on how intrusive the changes are
> (removing the File menu would be rude, but moving the plugin
> configuration menu item would be acceptable).
> In this case even major changes in user experience are justified -
> knowingly insecure web browser just should not be used.

That isn't any different than the firefox example on the page i.e
already covered.

More information about the devel mailing list