On Jul 20, 2010, at 8:38 AM, Karanbir Singh wrote:
Hi,
On 07/20/2010 10:31 AM, Andrey Ponomarenko wrote:
The examples of integration are: http://packages.debian.org/experimental/apt http://rpm5.org/ http://linuxtesting.org/upstream-tracker/
looks good.
Now our team is working on the integration of the tools to the OBS (openSUSE Build Service) at the packages (RPM) building stage.
That sounds interesting and is exactly what I had mentioned in my previous email that I'd like to be able to consider for the centos buildsystem as well. It would quite nicely add a test for changeset-between-updates sanity testing ( in as much as what sanity means to the CentOS userbase => things haven't changed ).
Adding to CentOS post-build tests isn't the right usage case for upstream-tracker imho.
The information in the upstream tracker is based on "upstream". There are any number of downstream modifications, such as ECC crypto being ripped out everywhere @redhat.com and the fact that there are no "reproducible builds" as long as AutoFu exists.
(aside) But there's no reason why additional interfaces cannot be analyzed during rpmbuild, or post-build for the RPM upgrade challenged (its really no harder than invoking an additional script at end of %install).
We don't do any testing of that nature at the moment, we rely on upstream having done such heavy lifting and we just aim to make sure we are as close to their builds as possible.
You should be careful to point out that "upstream" for CentOS is @redhat.com. That's a different meaning than commonly used for software distribution.
What I like about upgrade tracker is the deep vertical history. Its quite difficult to assess portability and determine "minimal necessary version" as a developer. One ends up getting blasted back to ancient releases with poorly understood de facto mixtures of "stuff". The information in upstream-tracker ie easily examined, and reasonable (from personal experience maintaining 2 of the projects being tracked upstream-tracker is identifying issues reliably. Sure there are both faux postives/negatives, can't be helped.)
The equivalent developer decision for distros is choosing when to, say, upgrade to openssl-1.0.0, and itemize a check-list of known issues that need to be fixed moving forward. ATM, distro decisions are largely ad hoc, where the old version is moved to compat-foo (which largely guarantees no ABI breakage), but the issues moving to a newer version of a package (and ensuring that all pther packages have been updated) are largely implicit rawhide-model processes which the details in the vertical history in update-tracker can help identify.
73 de Jeff