tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Maybe it's time to adopt extra testing for certain packages with high number of dependencies

On 2/27/2012 12:02 AM, Julio Merino wrote:
On 2/26/12 5:46 PM, John Marino wrote:
I understand that it's not considered possible (or at least practical)
to test all package upgrades on all platforms. However, certain packages
have a large number of dependencies. Take glib2 for example. Likely as a
result of an upgrade from 2.28.8 to 2.30.2 on 29 Jan 2012, it now
doesn't build on DragonFly resulting in 1849 breakages (1760 directly).

Would it be a good idea to identify packages like this one that have a
large number of direct dependencies (say > 100) and require that any
version upgrade be tested on a standard set of platforms before getting

Sounds reasonable to me, but how do you perform this testing? Would developers have access to build boxes to try their packages before submitting them? Or would this be automated somehow?

Automation would imply some kind of build farm. That would be ideal, but it would take a while to setup and costs money of course. That leaves manually, and I'd see 2-3 possibilities:

1) The maintainer has modern versions of these standard set of OS (multiboot box, virtualbox, vmware etc) and tests them himself 2) He sends the changes to the OS point of contact and waits a reasonable amount of time to hear if it builds okay on their platform 3) As you suggest, he's got access to a standard account on a box supplied by the OS project in order to test it himself.

Obviously this adds a layer of complexity and adds significant time, but probably justified for those packages with such a high impact.


Home | Main Index | Thread Index | Old Index