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