On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard <veill...@redhat.com> wrote:
> On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
>> Hi folks,
>
> Hi David,
>
>> Does libxml2 have a continuous integration system running over it somewhere?
>
> Not that I know of :)
> TBH the rate of changes is fairly slow, i.e. the code is mature (some
> will call it overripe even !) and while there is bugs, compared to the
> size of the system it's relatively small.
>
>> I've recently been exploring continuous integration systems and I used
>> libxml2 as a guinea pig for getting various tools working in
>> combination. Specifically, I've got a GitHub clone [1] of the repo
>> that links in with Travis [2]; once I added a few small local fixes
>> [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
>> UBSAN and coverage [4] runs.
>
> The biggest issue I have is non-linux, I never use Windows or Macs
> and I have zero clue that a change there could break the build or else.
> There are mingw builds of libxml2 done within Red Hat but that's not
> real Windows tests.
The Travis builds do at least add OSX testing, which was fairly
straightforward to set up (I disabled the EBCDIC test file because
the iconv() on OSX doesn't include EBCDIC support).
I imagine a Windows build would a lot more effort to get automated,
if/when Travis add support for it...
>> Looking at recent bugs, it seems like a couple of other people (Hugh
>> Davenport [5], Hanno Boeck [6]) have also been looking at
>> sanitizer-related things.
>
> Yes, I also get Coverity Scan reports about it.
>
>> So I wondered if the master libxml2 repo already has a continuous
>> build pointed at it (the Gnome continuous build system [7], maybe?),
>
> No not that know of
>
>> and, if so, whether it might be a good idea to turn on various
>> analysis tools to help catch future problems.
>>
>> Thoughts?
>
> Sure, the rate of changes is fairly slow though:
> https://git.gnome.org/browse/libxml2/
>
> But getting a report if something breaks on commit there would be appreciated
> as long as there is some logic to avoid pestering the list repeatedly with
> the same issue. That was a very painful experience on the very early versions
> of Coverity for example,
I believe the default Travis behaviour is to send email
- to the commit author and committer
- when a commit arrives for which the build is broken
- and when a commit fixes a previously-broken build.
(http://docs.travis-ci.com/user/notifications/)
As the whole process is commit-triggered, there shouldn't be too many
notifications (given that the rate of changes is low) -- but it does continue
to pester on each commit until a build break gets fixed.
How about I set up (for the time being) a cron job to do the following:
- fetch from the master repo
- merge into my testing branch
- push to GitHub...
- triggering a Travis build.
I *think* that should result in any email notifications from Travis going
to me, because I'll be the committer for the merge commit -- but please
let me know if the process inadvertently spams anyone!
If that goes well and is helpful, we can then talk later about whether/how
to migrate to the master repo.
Sound OK?
Thanks,
David
> Daniel
>
>>
>> Thanks,
>> David
>>
>> [1] https://github.com/daviddrysdale/libxml2
>> [2] https://travis-ci.org/daviddrysdale/libxml2
>> [3] https://github.com/daviddrysdale/libxml2/commits/test
>> [4] https://coveralls.io/github/daviddrysdale/libxml2
>> [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
>> [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
>> [7] http://build.gnome.org/
>> _______________________________________________
>> xml mailing list, project page http://xmlsoft.org/
>> xml@gnome.org
>> https://mail.gnome.org/mailman/listinfo/xml
>
> --
> Daniel Veillard | Open Source and Standards, Red Hat
> veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
> http://veillard.com/ | virtualization library http://libvirt.org/
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
