On Tue, Jan 28, 2014 at 01:10:56PM +0100, Martin Baehr wrote: > it's also hard to know at which stage we should build a new group for > the repo. if we want to mirror the possible upgrade history it would > mean a new group after every package is added, or every hour or... > no choice here sounds right really.
Yes, it's a bit of a rathole. When there is a source of errata data to group them, you can order by errata release timestamp and package version and mostly get it right. Before phantom packages, it would have been potentially useful to import packages that never made it into groups, just to be able to represent them. But not needing them is better. > in the long run we maybe even want to update only for releases and > manually update only fixes that we want in between so we can concentrate > on the actual foresight work and not just be busy with fedora updating > all the time. We want to process updates into f:20 on an ongoing basis, for both bug fixes and security updates. It's easier to just fire off mirrorball to process updates automatically than to make manual decisions. Now, inasmuch as fl:3 is based on f:20, fl:3 can choose when to update its upstream platform to a new version of the f:20 groups to limit churn. > once issues are ironed out, one interesting feature would be the ability > to bisect the update history to figure out which package update caused > to break something. like we had it at one point for gnome devel. for > such a feature it would be useful to have every package version. but i > don't think this is a good goal for us. (and personally i am more > interested in a future source rebuild than this anyways) Yes. That's one of the values of more group versions, which is another reason to keep mirrorball running once we get it going. Presumably any fl:3 work against f:20 would not start until after we got the initial batch of updates imported, so the gap between initial update and first update batch would not be important from a bisection point of view. Doing f:20 now means that we'll have the infrastructure and knowledge in place to do f:21 and CentOS 7 etc. more quickly after they are released. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
