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).http://avalon.dragonflybsd.org/reports/x86_64/bleeding-edge/20120224.0420/glib2-2.30.2nb2/build.logWould 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 committed?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.
John