Re: [xml] Continuous integration for libxml2?

2015-10-29 Thread David Drysdale 
On Wed, Oct 21, 2015 at 7:31 PM, Nick Wellnhofer 
wrote:

> On 21/10/2015 09:11, David Drysdale wrote:
>
>> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard 
>> wrote:
>>
>>>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...
>>
>
> The Windows build could be tested with Appveyor. They offer free CI
> services for open-source projects. Setup is similar to Travis.
>

Thanks for the pointer -- I've added an AppVeyor build to my clone of the
repo:
https://ci.appveyor.com/project/daviddrysdale/libxml2


> Nick
>
>
> ___
> xml mailing list, project page  http://xmlsoft.org/
> xml@gnome.org
> https://mail.gnome.org/mailman/listinfo/xml
>
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] Continuous integration for libxml2?

2015-10-21 Thread David Drysdale 
On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard  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

Re: [xml] Continuous integration for libxml2?

2015-10-21 Thread Daniel Veillard 
On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard  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/

> 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

Re: [xml] Continuous integration for libxml2?

2015-10-21 Thread David Drysdale 
On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard  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  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

Re: [xml] Continuous integration for libxml2?

2015-10-16 Thread Daniel Veillard 
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.

> 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,

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

[xml] Continuous integration for libxml2?

2015-10-16 Thread David Drysdale 
Hi folks,

Does libxml2 have a continuous integration system running over it somewhere?

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.

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.

So I wondered if the master libxml2 repo already has a continuous
build pointed at it (the Gnome continuous build system [7], maybe?),
and, if so, whether it might be a good idea to turn on various
analysis tools to help catch future problems.

Thoughts?

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