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 > Redhat > Fedora Desktop

 
 
LinkBack Thread Tools
 
Old 04-22-2010, 01:38 PM
William Jon McCann
 
Default Updates next steps

Hi Christoph,

Your message is pretty offtopic for the fedora desktop list and has an
unnecessarily contentious tone. I'm not sure why. And it isn't cool.

On Thu, Apr 22, 2010 at 5:27 AM, Christoph Wickert
<christoph.wickert@googlemail.com> wrote:
> Am Mittwoch, den 21.04.2010, 20:33 -0400 schrieb William Jon McCann:
>> Hi,
>>
>> So, that's cool. *I take it back - let's not limit pointless updates -
>> it is certainly a silly idea. *
>
> IF they are pointless, they should be limited to 0. If they are just
> optional, there are still users who want the latest and the greatest
> versions. During the whole discussion about the update process we
> learned that this is one of the main reasons why many people prefer
> Fedora over other distributions. If this is pointless, I'm afraid we are
> a pointless distro.

I'm sorry but I am not at all interested in rehashing that
fedora-devel discussion. I am however interested in hearing thoughts
on how we can achieve the two things that I mentioned.

>> Jokes aside, this is what Jesse and ajax told me on IRC that we (the
>> project) had decided. *So I was just repeating it here.
>
> AFAIR "the project" has never decided anything like this. I am not
> saying that I'm against this idea, I'm just a little surprised.
>
>> Most of the time when I say "we" on this list I mean the people who
>> are interested in designing and defining the user experience of this
>> desktop thing.
>
> You mean this GNOME desktop thing, right? Please stop using the word
> "desktop" as a synonym for "GNOME".

Dude, please. You do realize you are sending a mail to the
desktop@lists.fedoraproject.org list? So let's please not have this
level of conversation here.

> As this topic not only affects the (GNOME) desktop bug the whole
> distribution, I really think that it should not be discussed on the
> desktop list.

Ok, well, obviously I did.

>> Some of the time I refer to people who have some
>> expertise or opinions I respect in the area of experience design.
>> Other times I mean "I". *Which one I mean will depend on the
>> situation. *If that is too confusing then just assume I mean "I",
>> think carefully about the matter, and challenge me on it in a
>> constructive way. *(where constructive means "how you'd do it if you
>> had to and your reputation depended on it").
>>
>> We can continue to have discussions about having discussions about
>> making great things or we can just make great things. *Believe it or
>> not given the opportunity and the will - I know we can. *But dithering
>> is death.
>>
>> It is pretty clear that we want to make the user experience around
>> updates better for our users - now we need to do it. *There will be
>> people who don't agree (at least until we demonstrate it is better by
>> actually doing it) but we need to do it anyway.
>
> Sorry, but to me this attitude sounds arrogant. People "just doing
> something" - especially GNOME people - is not how community works and
> often is the source of a very unpleasant update experience.

Dude, I am pretty familiar with how this community works, thanks.
Design is a pretty arrogant thing - it is also a very difficult thing.
And extraordinarily hard to do in the open. But we do it. And we
have to make very difficult and risky choices every day with everyone
in the world potentially a critic. And we have discussions and
debates and we listen to everyone. But at the end of the day we need
to make choices. Those choices should get made by someone with
experience in the matter and willing to put their reputation on the
line for the choice. And should be informed by and consistent with
the rest of the experience around the product. That's that whole
meritocracy word we throw around. And yes that is how our community
works.

> Think of the recent hal update that broke every desktop but GNOME in
> F13. It was not announced (at least not for F13) and it was pushed after
> the beta freeze only for the GNOME people to finish their hal removal
> feature. Is this your idea of just doing "great things"?

I am only talking about stable release updates here. So, this isn't relevant.

> What is great for GNOME or for you as a maintainer is not necessarily
> great for others. This is why there needs to be a discussion instead of
> "just doing it".

One of the weighty responsibilities of a designer is to know a bit
about what makes things great for others. That is really hard. But
very important. If that is done poorly repeatedly then the reputation
of the designer suffers. So, there is a selfish motivation for this
kind of empathy. It's sort of wonderful if you think about it.

There has been plenty of discussion. Now, we just need to do it. In
my opinion these issues are the number one (or two - maybe after the
installer) problem we have right now. So, does my opinion matter more
than yours or Kevin's? I don't know. If we aren't able to solve the
problems that I'm trying to discuss here then probably not.

Jon
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-22-2010, 03:38 PM
Will Woods
 
Default Updates next steps

On Wed, 2010-04-21 at 17:35 -0400, Matthias Clasen wrote:
> On Wed, 2010-04-21 at 09:43 -0700, Jesse Keating wrote:
> > On Wed, 2010-04-21 at 12:02 -0400, William Jon McCann wrote:
> > >
> > > 1. Limit the frequency of non-critical updates to once per week in
> > > stable releases
> > >
> > >
> >
> > This gets pretty difficult to manage if we want to insert any testing of
> > the proposed update set to be pushed out. It increases the number of
> > potential push sets, per release, which increases the complexity quite a
> > bit in the depchecking routines.
> >
> > I'm not saying it's something we shouldn't do, I'm just saying that it's
> > going to make something significantly more complex to manage.
>
> I don't understand this, tbh. If anything, doing more testing for each
> set of updates would seem to benefit from pushing updates less
> frequently, since it gives us more time to actually test them. Is that
> not the case ?

I think (correct me if I'm wrong, Jesse) the piece you're missing is
that the 'push' operation is actually fairly tricky for the rel-eng
team: it's time-consuming, error-prone, and doesn't recover from faults
well. It requires a careful shepherd, so to speak.

So I think the problem Jesse was alluding to is this: Any proposal that
includes dividing updates into different types - and having different
push schedules for different types - means:

1) More reasons to push, which could lead to more pushes, and
2) More subsets of the existing package set(s), which could have a
multiplicative effect on the combinations that need to be tested

These aren't reasons *not* to do it, and these problems are not
insurmountable. But they're significant technical challenges and thus
important to keep in mind.

-w

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-22-2010, 07:00 PM
Jesse Keating
 
Default Updates next steps

On Thu, 2010-04-22 at 11:38 -0400, Will Woods wrote:
> On Wed, 2010-04-21 at 17:35 -0400, Matthias Clasen wrote:
> > On Wed, 2010-04-21 at 09:43 -0700, Jesse Keating wrote:
> > > On Wed, 2010-04-21 at 12:02 -0400, William Jon McCann wrote:
> > > >
> > > > 1. Limit the frequency of non-critical updates to once per week in
> > > > stable releases
> > > >
> > > >
> > >
> > > This gets pretty difficult to manage if we want to insert any testing of
> > > the proposed update set to be pushed out. It increases the number of
> > > potential push sets, per release, which increases the complexity quite a
> > > bit in the depchecking routines.
> > >
> > > I'm not saying it's something we shouldn't do, I'm just saying that it's
> > > going to make something significantly more complex to manage.
> >
> > I don't understand this, tbh. If anything, doing more testing for each
> > set of updates would seem to benefit from pushing updates less
> > frequently, since it gives us more time to actually test them. Is that
> > not the case ?
>
> I think (correct me if I'm wrong, Jesse) the piece you're missing is
> that the 'push' operation is actually fairly tricky for the rel-eng
> team: it's time-consuming, error-prone, and doesn't recover from faults
> well. It requires a careful shepherd, so to speak.
>
> So I think the problem Jesse was alluding to is this: Any proposal that
> includes dividing updates into different types - and having different
> push schedules for different types - means:
>
> 1) More reasons to push, which could lead to more pushes, and
> 2) More subsets of the existing package set(s), which could have a
> multiplicative effect on the combinations that need to be tested
>
> These aren't reasons *not* to do it, and these problems are not
> insurmountable. But they're significant technical challenges and thus
> important to keep in mind.
>
> -w
>

I believe you've hit it Will. Currently there are two sets of potential
update pushes for each release, that's

A) things going into -testing and
B) things going into stable

We already see numerous occasions of A requiring something that is going
into B, and if you push A without pushing B, you create a broken A.
This can't be fixed by grouping updates either, as they can be
completely unrelated, but still have a requirement relationship. So
things are already complex. Now we're talking about even more potential
complexity.

A) crit things going into -testing
Aa) non-crit things going into -testing
B) crit things going into stable
Bb) non-crit things going into stable

Now we have potential for all sorts of dep issues, where A needs
something from Aa or vice versa, or Aa needing a Bb thing, or A needing
Bb, or.... This is where the increased complexity in solving out the
right set of things to push out.

Again this isn't reason not to do this, just an insight into what
troubles will be there if we do.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-22-2010, 07:09 PM
Jesse Keating
 
Default Updates next steps

On Wed, 2010-04-21 at 17:35 -0400, Matthias Clasen wrote:
>
> I don't understand this, tbh. If anything, doing more testing for each
> set of updates would seem to benefit from pushing updates less
> frequently, since it gives us more time to actually test them. Is that
> not the case ?
>
>

That might be the case if it also slowed down the /submission/ of
updates. Those don't slow down for anything it seems, and adding any
artificial delay in responding to those submissions will just cause
pileups and larger and larger sets of things to fix, as well as exposing
more issues of multiple submissions for the same package just different
versions of it.

But here again I'm going down the "no" path, which is not productive.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-22-2010, 07:15 PM
Jesse Keating
 
Default Updates next steps

On Wed, 2010-04-21 at 12:02 -0400, William Jon McCann wrote:
>
> 2. Establish norms or rules that limit the types of changes in stable
> releases to ensure the releases remain stable
>
>

I had started on a proposal that addresses this, or at least attempts to
classify the types of updates we do, so that some rules could be layered
on top of those types.

https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal

I did not get an opportunity to work on this more, as F13 Beta tasks
ramped up. However I'll happily turn this wiki page over to anybody who
wishes to continue to work on it, or use it as a place to gather
consensus among the desktop group as to how they wish the update
experience to be.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 02:55 AM
Adam Williamson
 
Default Updates next steps

On Wed, 2010-04-21 at 20:33 -0400, William Jon McCann wrote:
> Hi,
>
> On Wed, Apr 21, 2010 at 5:29 PM, Adam Williamson <awilliam@redhat.com> wrote:
> > On Wed, 2010-04-21 at 23:15 +0200, Christoph Wickert wrote:
> >> Am Mittwoch, den 21.04.2010, 12:02 -0400 schrieb William Jon McCann:
> >> > Hey folks,
> >> >
> >> > We discussed this a bit on IRC yesterday but I wanted to bring it up
> >> > on the list too.
> >> >
> >> > Now that we have rough consensus that we should try to limit the
> >> > volume of "pointless" updates, what is next?
> >>
> >> I wonder who is "we" and why this is discussed on the desktop list and
> >> not in f-d-l.
> >
> > Indeed. I believe FESCo has approved a policy on enhanced *testing* of
> > candidate updates, but that's all. I don't believe there is a consensus
> > on restricting updates by type, or grouping them.
>
> So, that's cool. I take it back - let's not limit pointless updates -
> it is certainly a silly idea.
>
> Jokes aside, this is what Jesse and ajax told me on IRC that we (the
> project) had decided. So I was just repeating it here.

I don't think that's actually correct. I haven't followed the latest
FESCo meetings closely, but if I recall it correctly, back when FESCo
first asked Bill Nottingham to take his proposal on enhanced updates
testing further, at the same meeting FESCo explicitly chose *not* to
move in the direction of trying to restrict updates by type or group
them. If I'm remembering wrong or FESCo has changed tack on this
recently, sorry.

> Most of the time when I say "we" on this list I mean the people who
> are interested in designing and defining the user experience of this
> desktop thing.

However, this plan would not affect only 'this desktop thing'. It would
affect the entire distribution. The desktop mailing list really is not
the appropriate venue for this discussion. If you're only posting it to
desktop list to try and hide it from people who would disagree with the
plan, that's a really bad idea.

There is nothing in this proposal that is specific to 'the desktop' or
to GNOME, hence it does not belong on this list.

'Just going ahead and doing stuff' is often a good thing, I agree, but
not _always_, and not on a topic where the issue isn't just people
bikeshedding about the best way to do things, but a pretty fundamental
disagreement about whether it's actually desirable to do the thing _at
all_. It seems to me that it's wrong for someone to just go ahead and do
it anyway in this kind of case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 03:18 AM
Jesse Keating
 
Default Updates next steps

On Fri, 2010-04-23 at 03:55 +0100, Adam Williamson wrote:
> However, this plan would not affect only 'this desktop thing'. It would
> affect the entire distribution. The desktop mailing list really is not
> the appropriate venue for this discussion. If you're only posting it to
> desktop list to try and hide it from people who would disagree with the
> plan, that's a really bad idea.

I see this as a discussion in the open of how the desktop team would
like to see the updates experience, so that the desktop team can work on
a proposal for a wider audience. It's no different than discussing it
in a cube, or in an IRC meeting, or on a bus, or whatever. While the
proposal may effect many people, the discussion of creating the proposal
from the Desktop point of view does not need to be shouted from the roof
tops and held in a venue where we have 4K mixed opinions and endless
argument.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 04:42 AM
charles zeitler
 
Default Updates next steps

Do what thou wilt
shall be the whole of the Law.

thanks to the dedicated work of many teams at the Project,
i have enjoyed many years of the latest & greatest software.

of course there have been (relatively minor, in my case)
problems, but that is not totally avoidable, and overall
it has been a happy adventure.

stability has simply not been an issue.

now we have proposal after proposal, trying to produce
a "stable release" and insisting on imposing such a level
of "stability" into Fedora's releases, that i fear the result
would seriously interfere with the original goals of this fine
distribution.

charles zeitler

Love is the law, love under will.
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 05:13 AM
Jesse Keating
 
Default Updates next steps

On Thu, 2010-04-22 at 23:42 -0500, charles zeitler wrote:
>
> now we have proposal after proposal, trying to produce
> a "stable release" and insisting on imposing such a level
> of "stability" into Fedora's releases, that i fear the result
> would seriously interfere with the original goals of this fine
> distribution.

I believe your conflating a couple of our deliverables. There is
Rawhide, which is our development stream. All kinds of fun stuff
happens here, and this is where the new stuff lands to be tested out and
experimented with. If you build it, it'll show up here.

From that we have our Branched deliverable. This is a more conservative
tree that makes use of updates-testing as a buffer before it lands in
the public tree. We create this when we're ready to stop adding new
features to a release and instead polish the ones that made it in, and
focus on the bugfixes for the release. This is where things start to
get stable, and we start to expect that things won't break from one day
to the next.

Lastly we have our Stable Releases. These are the things we publish
every 6 months with much fanfare and hooplah. These also make use of
updates-testing as a buffer before updates, and even more stability is
expected here. We expect that our users will consume these stable
releases and use them day after day, and that things won't regress or
break or change behavior from one update to the next. People who wish
to live in the edge have the choice of using rawhide, or updating every
6 months or so to the next Branched tree. Those folks who want an
operating system that includes new technology (at the time) and remains
stable throughout the life of the release while still getting security
updates and bugfixes should be able to find that with the Fedora
releases.

The recent talk and proposals regarding adding stability is on that last
deliverable, the actual releases. Increasing stability there and
limiting updates to the bugfix and security issue type should not have
an impact on Fedora's ability to innovate. In fact it should free up
more resources to innovate within rawhide between releases. It will not
interfere with the original goals, it will in fact make those original
goals more attainable, as the original goals included having a usable
OS.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 07:32 AM
charles zeitler
 
Default Updates next steps

Do what thou wilt
shall be the whole of the Law.


On 4/23/10, Jesse Keating <jkeating@redhat.com> wrote:
>
> I believe your conflating a couple of our deliverables. There is
> Rawhide, which is our development stream. All kinds of fun stuff
> happens here, and this is where the new stuff lands to be tested out and
> experimented with. If you build it, it'll show up here.

i don't know if i'm _that_ adventurous.

"many changes are not heavily tested (or tested at all) "
"packages in Rawhide can and do break without warning"

> People who wish
> to live in the edge have the choice of using rawhide, or updating every
> 6 months or so to the next Branched tree.

actually, i have been receiving updates to newer versions, as well as bug &
security fixes, in a very timely fashion.
(and, i'm very satisfied with the quality of those updates)
but let's say Fedora goes this route:

waiting those months might mean missing too many updates,
but: rawhide will become Fedora N+1.

so- would some steps be taken to ensure that software
being worked on for Fedora 14 will work on Fedora 13?
>
> limiting updates to the bugfix and security issue type should not have
> an impact on Fedora's ability to innovate.
>
>
i'm not so sure. those other updates allow new software to reach
more people, with less delay, and "providing" (at least for upstream
partners) "a much larger audience and more feedback"
> --
> Jesse Keating
> Fedora -- Freedom˛ is a feature!
> identi.ca: http://identi.ca/jkeating
>



charles zeitler

--





Love is the law, love under will.
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 

Thread Tools




All times are GMT. The time now is 05:06 PM.

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