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