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 Development

 
 
LinkBack Thread Tools
 
Old 03-03-2010, 04:05 AM
Seth Vidal
 
Default Refining the update queues/process

On Tue, 2 Mar 2010, Toshio Kuratomi wrote:

>> the suggestion I had made at fudcon went something like this:
>>
>> 1. all packages being put in as updates would need to be marked as per
>> the type of update. the default is 'trivial'. Options might include: new
>> pkg, trivial, feature, bugfix, security
>>
>> 2. We would issue security updates whenever they happened. Issue bugfix
>> updates once every 2 weeks. Everything else once a month.
>>
>> it would curtail this sort of thing, it seems to me and let us control our
>> updates AND testing cycle.
>>
>> I've been thinking about the obvious problems of how we make it so you can
>> build those properly and I think we would need more targets to build
>> against, but I think that's do-able.
>>
> FWIW, +1 to this general outline.

Right now I'm thinking that a packager should generally know if an update
is a bugfix/security/etc update when they are building it.

The issue right now appears to be the same as when we have a critical
security or bugfix that has to be fast-tracked and we have LOTS of pkgs
in updates-testing.

I think we just need to formalize and have queues for that process.

I wonder if I can organize a post-f13 FAD to implement this...
Anyone interested?
-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 04:41 AM
Jesse Keating
 
Default Refining the update queues/process

On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
> The issue right now appears to be the same as when we have a critical
> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
> in updates-testing.

I don't know if this will help. Once a release has gotten a number of
updates, mashing that release will take a long time, regardless of how
many new updates are going in. This is particularly bad of say
11-updates or 12-updates, but -testing generally goes much faster as
there are less things in there (if bodhi obsoletes are doing the right
thing).

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 04:56 AM
Seth Vidal
 
Default Refining the update queues/process

On Tue, 2 Mar 2010, Jesse Keating wrote:

> On Wed, 2010-03-03 at 00:05 -0500, Seth Vidal wrote:
>> The issue right now appears to be the same as when we have a critical
>> security or bugfix that has to be fast-tracked and we have LOTS of pkgs
>> in updates-testing.
>
> I don't know if this will help. Once a release has gotten a number of
> updates, mashing that release will take a long time, regardless of how
> many new updates are going in. This is particularly bad of say
> 11-updates or 12-updates, but -testing generally goes much faster as
> there are less things in there (if bodhi obsoletes are doing the right
> thing).
>

At the risk of complicating the world would it make any sense for us to
have (in increasing order of importance)

updates-testing
updates
updates-important

packages that are security or critical go from updates-testing to
updates-important - and that happens as necessary

all other updates go from updates-testing to updates once a month.

-sv


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 05:17 AM
Kevin Kofler
 
Default Refining the update queues/process

Seth Vidal wrote:
> At the risk of complicating the world would it make any sense for us to
> have (in increasing order of importance)
>
> updates-testing
> updates
> updates-important
>
> packages that are security or critical go from updates-testing to
> updates-important - and that happens as necessary
>
> all other updates go from updates-testing to updates once a month.

And what problem would that solve? All I see is it causes problems for those
people who need the updates you don't judge "important".

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 05:28 AM
Seth Vidal
 
Default Refining the update queues/process

On Wed, 3 Mar 2010, Kevin Kofler wrote:

> Seth Vidal wrote:
>> At the risk of complicating the world would it make any sense for us to
>> have (in increasing order of importance)
>>
>> updates-testing
>> updates
>> updates-important
>>
>> packages that are security or critical go from updates-testing to
>> updates-important - and that happens as necessary
>>
>> all other updates go from updates-testing to updates once a month.
>
> And what problem would that solve? All I see is it causes problems for those
> people who need the updates you don't judge "important".

And stages non-critical/important updates so our QA team can test and
check them over more thoroughly and align testing goals and days to help
foster and create a more active and involved testing infrastructure.

This is what we HAVE to do.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 06:02 AM
Kevin Kofler
 
Default Refining the update queues/process

Seth Vidal wrote:
> And stages non-critical/important updates so our QA team can test and
> check them over more thoroughly and align testing goals and days to help
> foster and create a more active and involved testing infrastructure.

Congratulations for that sentence full of technical jargon designed to hide
its true meaning.

* Who decides what updates are or are not "critical" or "important"? The
criteria you brought up earlier in this thread (only security as critical)
are way too restrictive, what about a fix for a regression?
* Why would the QA team be better off having to test everything at the same
time for the same deadline than the current flow of testing updates?
* Why would we want to "align" our "testing goals and days"? It makes more
sense to spread them so people can test one thing at a time!
* So would this really "create a more active and involved testing
infrastructure"? IMHO it'd just create more painful deadlines, as if the
releases weren't enough of a painpoint already.
* And most importantly, even if we were to accept that it could lead to
better QA (which I doubt), would it really be worth making users wait a FULL
MONTH for their updates and forcing them to pull a HUGE update in one single
transaction rather than spread over time? IMHO, HELL NO!

Fedora is not RHEL, introducing an RHEL-style point release system is
bizarre and IMHO quite silly.

> This is what we HAVE to do.

Why? Because you say so? We aren't doing that stuff now and things are
working just fine, thank you very much! We don't HAVE to change anything at
all!

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 06:05 AM
Jesse Keating
 
Default Refining the update queues/process

On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> Why? Because you say so? We aren't doing that stuff now and things are
> working just fine, thank you very much! We don't HAVE to change anything at
> all!
>

This I believe to be the crux of the problem. When multiple updates go
out that break large or important segments of our user base, many of us
see a problem. You however seem to think it's "just fine". Many of us
would rather put out a better operating system, and to do that, we need
change. Your "just fine" isn't good enough.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 06:20 AM
Ralf Corsepius
 
Default Refining the update queues/process

On 03/03/2010 07:28 AM, Seth Vidal wrote:
>
>
> On Wed, 3 Mar 2010, Kevin Kofler wrote:
>
>> Seth Vidal wrote:
>>> At the risk of complicating the world would it make any sense for us to
>>> have (in increasing order of importance)
>>>
>>> updates-testing
>>> updates
>>> updates-important
>>>
>>> packages that are security or critical go from updates-testing to
>>> updates-important - and that happens as necessary
>>>
>>> all other updates go from updates-testing to updates once a month.
All this would do is causing further bureaucracy and delays in fixing
"non-security and non-critical" bug fixes and add further complexity to
repo-deps.

>> And what problem would that solve? All I see is it causes problems for those
>> people who need the updates you don't judge "important".

> And stages non-critical/important updates so our QA team can test and
> check
Please elaborate how the "QA team" is testing perl modules.

So far, I haven't seen any indication of such a team being in existance
(c.f. dnssec-conf, kernel) nor am I aware of any means for testing such
perl-modules (perl-modules typically are equipped with a testsuite).

The real testing is performed by Fedora users, them providing feedback
and maintainers letting user feedback flow back into packages ASAP.

> them over more thoroughly and align testing goals and days to help
> foster and create a more active and involved testing infrastructure.

> This is what we HAVE to do.
Feel free to think so, however can not disagree more.

Instead, we need
* to fix the bugs Fedora packages currently suffers from.
One step into this direction would be FESCO to ban "FIXED
UPSTREAM/RAWHIDE", such that maintainers can not resort to it.

* people to stop infecting Fedora with premature, immature and
dysfunctional packages. These packages are the #1 nuissances when
upgrading between different versions of Fedora.

* automatisms to prevent broken package deps.
These are the nuissances users are facing when coping with updates.

* Fix PackageKit/Fedora's infrastructure (or whereever the cause may be)
such that PackageKit doesn't demand unnecessary reboots (It currently
does so).
That said, if you want to delay and bundle package updates: Bundle those
which require rebooting.

* Encourage users on low bandwidth to use presto - AFAICT, presto repos
don't get the attention they would need.

* rolling DVD images (say weekly) such that installation-DVD gets more
frequent testing ...

Or differently: The key to QA would not be bug-fixing, but to prevent
bugs from entering Fedora - This is where Fedora has deficits.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 06:50 AM
Kevin Kofler
 
Default Refining the update queues/process

Jesse Keating wrote:
> This I believe to be the crux of the problem. When multiple updates go
> out that break large or important segments of our user base, many of us
> see a problem. You however seem to think it's "just fine". Many of us
> would rather put out a better operating system, and to do that, we need
> change. Your "just fine" isn't good enough.

Those various changes being proposed would make things worse, not better.
They wouldn't solve any of those problems, just create new ones.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-03-2010, 07:45 AM
Till Maas
 
Default Refining the update queues/process

On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote:
> On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote:
> > Why? Because you say so? We aren't doing that stuff now and things are
> > working just fine, thank you very much! We don't HAVE to change anything at
> > all!
> >
>
> This I believe to be the crux of the problem. When multiple updates go
> out that break large or important segments of our user base, many of us
> see a problem. You however seem to think it's "just fine". Many of us
> would rather put out a better operating system, and to do that, we need
> change. Your "just fine" isn't good enough.

Are there even any metrics about how many bad updates happened? For me
bug that can be fixed issuing an update are a lot more than regressions
with updates or new bugs introduced with updates. If updates are slowed
down, this will get even worse. Especially because the proposal is to
use time instead of test coverage as the criterion to push an update to
stable.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:55 PM.

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