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-01-2010, 05:42 PM
Bruno Wolff III
 
Default Thrashing between updates-testing and updates

Currently I am following F13 and I have been noticing a lot of packages
disappearing from updates-testing before showing up in the branched release
(but similar things happen with normal updates, just less often).

When things disappear from updates-testing it isn't immediately obvious
if this is because the updates are bad or because the update has been pushed
to stable.

Since I have a local mirror and the packages disappear between syncs, I end
up downloading them twice. When stuff ends up having the same key regardless
of testing status, this is especially wasteful.

What I'd like to see is stuff stay in updates-testing for a while so that
the hard link feature of rsync can be used to avoid downloading the data
twice. And so that I don't get false alarms for stuff that may need to get
downgraded.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-01-2010, 09:33 PM
Jesse Keating
 
Default Thrashing between updates-testing and updates

On Mon, 2010-03-01 at 12:42 -0600, Bruno Wolff III wrote:
> Currently I am following F13 and I have been noticing a lot of packages
> disappearing from updates-testing before showing up in the branched release
> (but similar things happen with normal updates, just less often).
>
> When things disappear from updates-testing it isn't immediately obvious
> if this is because the updates are bad or because the update has been pushed
> to stable.
>
> Since I have a local mirror and the packages disappear between syncs, I end
> up downloading them twice. When stuff ends up having the same key regardless
> of testing status, this is especially wasteful.
>
> What I'd like to see is stuff stay in updates-testing for a while so that
> the hard link feature of rsync can be used to avoid downloading the data
> twice. And so that I don't get false alarms for stuff that may need to get
> downgraded.

That's going to be pretty difficult to do with the way our push and sync
scripts work.

At most an update that is going from testing to stable should disappear
for only a few hours, that would be between the updates-testing push of
the day an the subsequent branched compose each night.

--
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-02-2010, 10:26 AM
Kevin Kofler
 
Default Thrashing between updates-testing and updates

Jesse Keating wrote:
> That's going to be pretty difficult to do with the way our push and sync
> scripts work.
>
> At most an update that is going from testing to stable should disappear
> for only a few hours, that would be between the updates-testing push of
> the day an the subsequent branched compose each night.

I guess the branched release really needs a separate updates repo to prevent
that issue.

We could have the branched compose compose from dist-f13 + dist-f13-updates
and move everything which was part of its compose from dist-f13-updates to
dist-f13 on completion. That way dist-f13-updates would only contain the
stuff that was just pushed and didn't make the daily compose yet, which
could be offered as an updates repository.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 11:59 AM
Bruno Wolff III
 
Default Thrashing between updates-testing and updates

On Tue, Mar 02, 2010 at 12:26:35 +0100,
Kevin Kofler <kevin.kofler@chello.at> wrote:
>
> We could have the branched compose compose from dist-f13 + dist-f13-updates
> and move everything which was part of its compose from dist-f13-updates to
> dist-f13 on completion. That way dist-f13-updates would only contain the
> stuff that was just pushed and didn't make the daily compose yet, which
> could be offered as an updates repository.

The problems I am seeing is that the branched repo gets built several hours
apart from the testing repo and I don't get consistent views of package
status. Particularly since the branched repo seems to become available
in my afternoons, I seem to get a version of testing in the morning with
updates dropped from testing that will show up later in the afternoon.
It's really just a minor annoyance for me, so if it's hard to fix it
may not be worth doing. The mirrors that pick stuff up pretty often (for
example the kernel mirrors update several times a day as best as I can
tell) probably could save some churn if the packages were signed with the
same key. (I am not sure if that is true yet; though my understanding is
that there will eventually be one key used to sign any official builds
coming out of koji.)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-02-2010, 04:13 PM
Jesse Keating
 
Default Thrashing between updates-testing and updates

On Tue, 2010-03-02 at 06:59 -0600, Bruno Wolff III wrote:
> probably could save some churn if the packages were signed with the
> same key. (I am not sure if that is true yet; though my understanding is
> that there will eventually be one key used to sign any official builds
> coming out of koji.)

There is only one F13 key, so the sig doesn't change when it moves from
updates-testing to the branched repo.

--
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
 

Thread Tools




All times are GMT. The time now is 04:27 PM.

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