[lsb-discuss] Reducing set of distributions in AppChecker and Navigator

[Denis Silakov]

On 01/19/2012 01:36 AM, Wichmann, Mats D wrote:
>
>     It's not easy to teach Navigator to show such data, but I can
>     generate some approximations by myself :)
>
>     Here is comparison of versions of components interesting in the
>     context of LSB (5 tables - sles10, rhel4/5 and debian5/6):
>     http://dsilakov.ru/distr_comps.html
>
>     Hopefully highlighting is almost self-explaining - green is good,
>     red is not:) The only really significant change (that did affect
>     LSB development) is Qt update in SLES 10 SP2. It is likely that we
>     want to store this info in the db.
>
>
>
> This is neat info.  The first-last of a series seems sane, and except 
> for the case you cite of SLES, the changes have been ones we don't 
> need to keep. If we do a one-time trim now, I guess the question 
> becomes one of moving forward: if we have a release series like RHEL 
> which now uses major.minor, and we prune so we store X.0 and X.Y, then 
> X.Y+1 comes out... do we immediately prune out X.Y after importing 
> X.Y+1?  Or do we then hit the case where somebody is still working on 
> porting to X.Y and they get irritated that specific information vanished?
Good question. Maybe for the current major branch we could keep all 
minor updates and drop intermediate ones only when the major update occurs?

In case of micro updates it doesn't seem to make much sense to store 
intermediate versions. E.g., Debian 6.0.x -> 6.0.(x+1) is really a 
'micro' update not only because it only changes micro version, but 
because there are almost no changes in versions of components, not 
speaking about libraries/binary symbols.

-- 
Regards,
Denis.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120120/5ac315ba/attachment.html>