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-23-2010, 10:33 AM
"Jˇhann B. Gu­mundsson"
 
Default Updates next steps

Is it possible for each SIG/yum group to have full control on it's own
update policy which they can adjust to their target audience instead of
trying to provide a solution that might not fit everybody?

For example

Fedora REL-ENG sets it's policy like this..

base )
---------> Security fixes/stable updates only
core )

[ Gnome SIG ]

Gnome Desktop --> It's own update policy.

Perhaps wants to be more windows like with Service packs like updates..
Bigger updates pushed monthly.

[ KDE SIG]

KDE Desktop --> It's own update policy.

Perhaps it wants to continue on the road as is and have more frequent
updates to it's target users.
Users receive bits as they get fixed as fast as possible..

[ LXDE SIG ]

LXDE Desktop --> It's own update policy

[ XFCE SIG ]

XFCE Desktop --> It's own update policy

etc...

If not I think the best option is to force Security/Stability updates
only on the whole project and if SIG or yum groups want to push feature
enhancements upon users they should head down the path the Virtualzation
group did and have a Preview repo on the side away from the main update
path.

JBG
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 10:45 AM
Matthias Clasen
 
Default Updates next steps

On Fri, 2010-04-23 at 10:33 +0000, "Jˇhann B. Gu­mundsson" wrote:
> Is it possible for each SIG/yum group to have full control on it's own
> update policy which they can adjust to their target audience instead of
> trying to provide a solution that might not fit everybody?
>

These kinds of split setups don't really work, because dependencies will
make a big mess out of it and cause you to get most of the update flood
after a while, even if you only want security updates.

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 11:12 AM
"Jˇhann B. Gu­mundsson"
 
Default Updates next steps

On 04/23/2010 10:45 AM, Matthias Clasen wrote:
> On Fri, 2010-04-23 at 10:33 +0000, "Jˇhann B. Gu­mundsson" wrote:
>
>> Is it possible for each SIG/yum group to have full control on it's own
>> update policy which they can adjust to their target audience instead of
>> trying to provide a solution that might not fit everybody?
>>
>>
> These kinds of split setups don't really work, because dependencies will
> make a big mess out of it and cause you to get most of the update flood
> after a while, even if you only want security updates.
>
>

Then that's a technical problem that needs to be solved first if
consensus is going to be reach within the whole community and this be
discussed on only one SIG mailing list.

If that's not possible then Rel-Eng should sit down with representatives
from all SIG's and QA where the update policy is decide for the whole
community then the result of that or those meetings will be posted and
the community informed that what's going to be put for trial and
adjusted as needed.

JBG
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 12:05 PM
William Jon McCann
 
Default Updates next steps

Hi,

2010/4/23 "J├│hann B. Gu├░mundsson" <johannbg@hi.is>:
> On 04/23/2010 10:45 AM, Matthias Clasen wrote:
>> On Fri, 2010-04-23 at 10:33 +0000, "J├│hann B. Gu├░mundsson" wrote:
>>
>>> Is it possible for each SIG/yum group to have full control on it's own
>>> update policy which they can adjust to their target audience instead of
>>> trying to provide a solution that might not fit everybody?
>>>
>>>
>> These kinds of split setups don't really work, because dependencies will
>> make a big mess out of it and cause you to get most of the update flood
>> after a while, even if you only want security updates.
>>
>>
>
> Then that's a technical problem that needs to be solved first if
> consensus is going to be reach within the whole community and this be
> discussed on only one SIG mailing list.
>
> If that's not possible then Rel-Eng should sit down with representatives
> from all SIG's and QA where the update policy is decide for the whole
> community then the result of that or those meetings will be posted and
> the community informed that what's going to be put for trial and
> adjusted as needed.

Or maybe its just that spins as they are defined now aren't such a
good idea. They don't really have the flexibility to define and
design their own experience. The difference between GNOME and KDE for
example, to the user, is nearly as great as the difference between
Windows and OS X. Spins are each different operating systems with
diverging not converging experiences and goals. We have a development
architecture that forces agreement or artificial commonality between
very different things and it is no surprise that we have a lot of
conflict.

See http://www.christoph-wickert.de/blog/2010/02/20/spins-suck/ :
Chrisoph Wickert "spins suck"
Kevin Kofler "LetÔÇÖs fight together against GNOME-centricism in Fedora!"

Good times!

Look, creating a compelling operating is real fucking hard. No,
seriously, really really super fucking really hard. If we devote all
of our energy and time into creating one operating system we probably
can't even pull it off. But we certainly can't pull it off if we have
4 different operating systems stepping on each other toes, getting in
each other grill, sucker punching, and begrudging. No way. Honestly,
even if we manage to widen our community (remember Fedora is just one
small part of the larger open source community, folks) to include
other projects with similar goals and all work on one thing we'll have
a really difficult struggle on our hands. But the good kind of
struggle - creative struggle - not the destructive struggle we
currently have in Fedora. Like Kevin, I want to fight too. But
unlike Kevin, I want to fight to create something monumental - a
tribute to open source. Something that can demonstrate to the world
that we can. The other kind of fighting - is mud. And the rest of
the world understandably walks right past it.

But this is all way off topic for this thread.

Jon
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 04:15 PM
Bill Nottingham
 
Default Updates next steps

Adam Williamson (awilliam@redhat.com) said:
> 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.

A slight clarification; it's not (AFAIK) that FESCo chose to not move
that way, it's that they didn't choose any particular way to move. We
may still move that way.

What would be required would be some sort of actionable proposal to
implement, which is what I would think this discussion could come up
with.

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

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 hate being the "stuff is hard" guy, but I just remembered another
issue with this. Our update classifications have to be carried forward.
That is to say, for a given package foo:

foo-1 is shipped in F13.
foo-2 is an update after F13 went out, and it is a trivial or
non-critical fix.
foo-3 is an update that is a critical fix
foo-4 is a trivial fix
foo-5 is a new upstream release

The problem is that for people installing f13 after foo-5 was released,
but want the critical fix for foo, they have to consume foo-5, which
means consuming all the non-critical changes that happened along the
way. The same thing happens with security updates. Basically for any
given package, all the update types for that package become inclusive,
rather than exclusive. So as the release goes on and a given package
gets multiple updates, a later update may very well be Critial, Trivial,
Bugfix, Security, and Enhancement all in one.

--
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:31 PM
William Jon McCann
 
Default Updates next steps

Hey Bill,

On Fri, Apr 23, 2010 at 12:15 PM, Bill Nottingham <notting@redhat.com> wrote:
> Adam Williamson (awilliam@redhat.com) said:
>> 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.
>
> A slight clarification; it's not (AFAIK) that FESCo chose to not move
> that way, it's that they didn't choose any particular way to move. We
> may still move that way.
>
> What would be required would be some sort of actionable proposal to
> implement, which is what I would think this discussion could come up
> with.

Yeah my hope exactly.
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 05:34 PM
Owen Taylor
 
Default Updates next steps

On Fri, 2010-04-23 at 09:29 -0700, Jesse Keating 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 hate being the "stuff is hard" guy, but I just remembered another
> issue with this. Our update classifications have to be carried forward.
> That is to say, for a given package foo:
>
> foo-1 is shipped in F13.
> foo-2 is an update after F13 went out, and it is a trivial or
> non-critical fix.
> foo-3 is an update that is a critical fix
> foo-4 is a trivial fix
> foo-5 is a new upstream release
>
> The problem is that for people installing f13 after foo-5 was released,
> but want the critical fix for foo, they have to consume foo-5, which
> means consuming all the non-critical changes that happened along the
> way. The same thing happens with security updates. Basically for any
> given package, all the update types for that package become inclusive,
> rather than exclusive. So as the release goes on and a given package
> gets multiple updates, a later update may very well be Critial, Trivial,
> Bugfix, Security, and Enhancement all in one.

A feature where you can "subscribe to critical updates only" isn't
necessary here to make a big improvement.

A strawman might be:

* We have a set of criteria for what is critical (say security updates
or fixes breakage in the critical path)
* When you file an update in Bodhi, there's a checkbox for "critical"
* Stuff marked as critical follows the current process
* Stuff not marked as critical is only pushed from updates-testing
to updates on Mondays and goes out on Tuesday morning.

I don't know the details of the push process, but that seems like it
should be a pretty trivial change to what we do currently.

- Owen


--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 05:40 PM
Seth Vidal
 
Default Updates next steps

On Fri, 23 Apr 2010, Owen Taylor wrote:

> On Fri, 2010-04-23 at 09:29 -0700, Jesse Keating 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 hate being the "stuff is hard" guy, but I just remembered another
>> issue with this. Our update classifications have to be carried forward.
>> That is to say, for a given package foo:
>>
>> foo-1 is shipped in F13.
>> foo-2 is an update after F13 went out, and it is a trivial or
>> non-critical fix.
>> foo-3 is an update that is a critical fix
>> foo-4 is a trivial fix
>> foo-5 is a new upstream release
>>
>> The problem is that for people installing f13 after foo-5 was released,
>> but want the critical fix for foo, they have to consume foo-5, which
>> means consuming all the non-critical changes that happened along the
>> way. The same thing happens with security updates. Basically for any
>> given package, all the update types for that package become inclusive,
>> rather than exclusive. So as the release goes on and a given package
>> gets multiple updates, a later update may very well be Critial, Trivial,
>> Bugfix, Security, and Enhancement all in one.
>
> A feature where you can "subscribe to critical updates only" isn't
> necessary here to make a big improvement.
>
> A strawman might be:
>
> * We have a set of criteria for what is critical (say security updates
> or fixes breakage in the critical path)
> * When you file an update in Bodhi, there's a checkbox for "critical"
> * Stuff marked as critical follows the current process
> * Stuff not marked as critical is only pushed from updates-testing
> to updates on Mondays and goes out on Tuesday morning.
>
> I don't know the details of the push process, but that seems like it
> should be a pretty trivial change to what we do currently.

I build an update for foo and bar.

foo is a critical update
bar is not a critical update

bar requires that version of foo.


-sv




--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 04-23-2010, 05:51 PM
Owen Taylor
 
Default Updates next steps

On Fri, 2010-04-23 at 13:40 -0400, Seth Vidal wrote:
>
> On Fri, 23 Apr 2010, Owen Taylor wrote:
>
> > On Fri, 2010-04-23 at 09:29 -0700, Jesse Keating 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 hate being the "stuff is hard" guy, but I just remembered another
> >> issue with this. Our update classifications have to be carried forward.
> >> That is to say, for a given package foo:
> >>
> >> foo-1 is shipped in F13.
> >> foo-2 is an update after F13 went out, and it is a trivial or
> >> non-critical fix.
> >> foo-3 is an update that is a critical fix
> >> foo-4 is a trivial fix
> >> foo-5 is a new upstream release
> >>
> >> The problem is that for people installing f13 after foo-5 was released,
> >> but want the critical fix for foo, they have to consume foo-5, which
> >> means consuming all the non-critical changes that happened along the
> >> way. The same thing happens with security updates. Basically for any
> >> given package, all the update types for that package become inclusive,
> >> rather than exclusive. So as the release goes on and a given package
> >> gets multiple updates, a later update may very well be Critial, Trivial,
> >> Bugfix, Security, and Enhancement all in one.
> >
> > A feature where you can "subscribe to critical updates only" isn't
> > necessary here to make a big improvement.
> >
> > A strawman might be:
> >
> > * We have a set of criteria for what is critical (say security updates
> > or fixes breakage in the critical path)
> > * When you file an update in Bodhi, there's a checkbox for "critical"
> > * Stuff marked as critical follows the current process
> > * Stuff not marked as critical is only pushed from updates-testing
> > to updates on Mondays and goes out on Tuesday morning.
> >
> > I don't know the details of the push process, but that seems like it
> > should be a pretty trivial change to what we do currently.
>
> I build an update for foo and bar.
>
> foo is a critical update
> bar is not a critical update
>
> bar requires that version of foo.

That doesn't seem to be a problem - foo will go out, and bar will wait
until Tuesday. But if you meant the reverse - a critical update that
depends on a non-critical update, then, in my understanding we *already*
have this problem.

If foo and bar are submitted as independent updates, and only bar gets
sufficient karma, or foo is "critical path" and needs releng approval
and bar isn't, then we push bar out and not foo and we have a broken
updates push.

The answer I've heard on this is that foo and bar should have been
submitted as one update. Obviously it would be better if our tooling
could detect this problem and manage it sensibly.

- Owen


--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 

Thread Tools




All times are GMT. The time now is 10:55 AM.

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