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 02-28-2010, 11:17 PM
Josh Boyer
 
Default FESCo wants a more sane updates policy (feedback requested)

On Mon, Mar 01, 2010 at 12:25:01AM +0100, Kevin Kofler wrote:
>drago01 wrote:
>> There has been a draft a while ago which did not result into much
>> discussion ..
>>
>> http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience
>>
>> Which looks pretty sane to me.
>
>It looks very insane to me:
>* only critical bugfixes, security fixes and hardware enablement for an
>arbitrary class of "system" packages which isn't defined anywhere. Not even
>general bugfixes! IMHO that's not at all what Fedora is or should be about.
>* only weekly pushes. We should target daily pushes. Our current pushes are
>too rare, not too frequent. People who only want to update once a week

We do target daily pushes. There are a lot of mitigating factors that sometimes
prevent a push getting done in 24 hours, but that is what I try to do. Things
like large package sets/large packages (e.g. OO.org, KDE) can make a compose
for a single updates repo take on the order of 8 hours. We have 5 repos we
have to compose per push. Also, the older a repo is, the more overall packages
there are in it, the longer it takes to mash. Also deltarpm creation is
really really slow. You can extrapolate on the math from there.

With NFR, we're also trying to get at least 2 F-13 pushes done per day so as
to hold it up as little as possible. This is more doable since the repo is
small, and we're doing targeted pushes for at least one of them.

I've highlighted the issues with updates pushes and times and frequency many
times in the past. We don't have an magic here, nor do I see any coming any
time soon.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 12:25 AM
Kevin Kofler
 
Default FESCo wants a more sane updates policy (feedback requested)

Mail Lists wrote:
> Kernel should follow mainline stable - as reasonably soon after
> release and our testing as possible.
>
> Core daemons - ditto.

But that's quite different from what that proposed policy mandates.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 12:29 AM
Kevin Kofler
 
Default FESCo wants a more sane updates policy (feedback requested)

Josh Boyer wrote:
> We do target daily pushes.

Then that's a good thing, and shouldn't be changed as that old proposed
policy would be trying to do. ;-)

> There are a lot of mitigating factors that sometimes prevent a push
> getting done in 24 hours, [etc.]

OK, got that. I'm not really complaining about the technical restrictions,
but about proposed arbitrary ones such as the "only weekly pushes on
Tuesday" in that old proposed policy (which didn't get anywhere for a
reason).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 08:52 AM
drago01
 
Default FESCo wants a more sane updates policy (feedback requested)

On Mon, Mar 1, 2010 at 2:25 AM, Kevin Kofler <kevin.kofler@chello.at> wrote:
> Mail Lists wrote:
>> * Kernel should follow mainline stable - as reasonably soon after
>> release and our testing as possible.
>>
>> * Core daemons - ditto.
>
> But that's quite different from what that proposed policy mandates.

No it isn't ... Jon added the "enable hardware enablement" bit after
he agreed that kernel rebases make sense.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 09:20 AM
Richard Hughes
 
Default FESCo wants a more sane updates policy (feedback requested)

On 28 February 2010 18:39, James Antill <james@fedoraproject.org> wrote:
> *I can't think of any reason why you'd need, or want, to have
> updates-testing checks block any other GUI operation.

To show the list of newest updates to the user...

>> If we could speed up the dep checking and downloading, I agree it
>> would be better for usability, and the exposure of updates-testing
>> generally.
>
> *Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300
> packages here and lsuT is like 2.5 seconds. I guess maybe that's worth
> caring about if you block everything else behind it, but...

Sure, and 2.5 seconds _extra_ is a long time.

> *As to the downloads, if you know of a way to speed up a users internet
> connection ... feel free to spread your wisdom.

Here's three:

* Download from multiple mirrors simultaneously
* Do the transaction in parallel so that you're downloading the next
depsolved set of updates as you're installing the first
* Have better control of the cache format so you don't need to keep
three files in sync just to update the primary and then depsolve.

Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 12:16 PM
Rudolf Kastl
 
Default FESCo wants a more sane updates policy (feedback requested)

2010/3/1 Richard Hughes <hughsient@gmail.com>:
> On 28 February 2010 18:39, James Antill <james@fedoraproject.org> wrote:
>> *I can't think of any reason why you'd need, or want, to have
>> updates-testing checks block any other GUI operation.
>
> To show the list of newest updates to the user...
>
>>> If we could speed up the dep checking and downloading, I agree it
>>> would be better for usability, and the exposure of updates-testing
>>> generally.
>>
>> *Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300
>> packages here and lsuT is like 2.5 seconds. I guess maybe that's worth
>> caring about if you block everything else behind it, but...
>
> Sure, and 2.5 seconds _extra_ is a long time.
>
>> *As to the downloads, if you know of a way to speed up a users internet
>> connection ... feel free to spread your wisdom.
>
> Here's three:
>
> * Download from multiple mirrors simultaneously
> * Do the transaction in parallel so that you're downloading the next
> depsolved set of updates as you're installing the first
> * Have better control of the cache format so you don't need to keep
> three files in sync just to update the primary and then depsolve.
>
> Richard.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

that practically just doesent work (updates-testing) since
updates-testing packages do not get built against updates-testing
packages and therefor if you have 2 soname bumps it falls over and you
end up resolving deps manually by try and error with the packagekit
frontend.

kind regards,
Rudolf Kastl
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 05:04 PM
Kamil Paral
 
Default FESCo wants a more sane updates policy (feedback requested)

Hello,

I have seen the long thread about Updates Policy. I just wish
to inform you that I (as part of the QA team) have been working
on a draft of exactly such a policy. I suppose I will be able
to make it public during this week. I will post a link here,
so all the people will have some basis what to discuss.

The timing of this discussion is quite interesting, because
otherwise the whole discussion would be around my proposal
about a week later. But we can always start a second
flamewar Just kidding, I hope people will have at least
a clearer ideas now, after so many posts sent.

That's all from me know, I just wanted to let you know that
a draft is coming.

Thanks,
Kamil Páral
QA team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 05:32 PM
Naheem Zaffar
 
Default FESCo wants a more sane updates policy (feedback requested)

Thankyou for starting all this hard work with the certainty that it *will* be blamed by some people.

As an end User I extremely like that Fedora does not ban newer packages from Stable releases.

At the same time I can see how direct pushes can sometimes create unforseen bugs.


I however do not see both scenarios as mutually exclusive - even a tool issue may fix things - have an option to set have a default push to stable (offset) date and then packagers can fire away their packages, do their testing and forget about taking any other actions unless there is a need to fix some more bugs (or a security issue to force the date closer).


Good luck.

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

Thread Tools




All times are GMT. The time now is 11:46 PM.

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