On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard <veill...@redhat.com> wrote:
> On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
>> 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).
>
> Okay
>
>> I imagine a Windows build would a lot more effort to get automated,
>> if/when Travis add support for it...
>
> as suggested you could tru to build with mingw, but for the actual
> regression testing, that's another story indeed
>
>> >> 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!
>
> may be I should get the SPAM. I wonder if there is a fedmsg backend for
> travis
> as getting those message over IRC might be a nice solution rather than mail
>
> http://www.fedmsg.com/en/latest/
Simpler than that, it looks like Travis have direct IRC integration:
http://docs.travis-ci.com/user/notifications/#IRC-notification
>> If that goes well and is helpful, we can then talk later about whether/how
>> to migrate to the master repo.
>>
>> Sound OK?
>
>
> yes,
>
> thanks !
>
> Daniel
>
>> 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/
>
> --
> 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
