I want to make sure we are covered
--
Patrik Dufresne Service Logiciel inc.
http://www.patrikdufresne.com <http://patrikdufresne.com/>/
514-971-6442
130 rue Doris
St-Colomban, QC J5K 1T9
On Tue, Nov 19, 2019 at 3:10 PM EricZolf <address@hidden
<mailto:address@hidden>> wrote:
Hi Patrik,
On 19/11/2019 20:54, Patrik Dufresne wrote:
> Yep, sorry. About that, I intend to get appveyor working, but then I
> found out the current travis build for linux was not working well.
> Submitted a PR to fix the scm_version and did not complete it.
If you could just do a rebase on this one, that would be great, I could
merge it.
> Long story short, I did not take time to complete the work. But I
don't
> have alot of free time to spent and I really want to jump in, but
I'm
> struggling just to follow all your changes Eric :P
The trick is to learn looking TV and doing coding at the same time ;-)
> Regarding the Windows build, it might also be interesting to
leverage
> the travis windows build instead of appveyor. Would allow us to
have a
> unique CICD pipeline instead of two.
Whatever works for Arrigo or you, I'm open! At the end the result
counts. Limiting the number of technologies sounds like a good
strategy,
so I'm all for Travis, but if AppVeyor is easier/better for any reason,
also fine.
Thanks, Eric
>
> --
> Patrik Dufresne Service Logiciel inc.
> http://www.patrikdufresne.com <http://patrikdufresne.com/>/
> 514-971-6442
> 130 rue Doris
> St-Colomban, QC J5K 1T9
>
>
> On Tue, Nov 19, 2019 at 2:47 PM <address@hidden
<mailto:address@hidden>
> <mailto:address@hidden
<mailto:address@hidden>>> wrote:
>
> Hi Arrigo,
>
> any help is welcome. Patrick started to work on an Appveyor setup
> but he
> seems to be busy, so if you want to take over the
issue/branch [1] and
> finish the work, drop a note in the issue to give Patrick a
chance to
> react, but from my point of view, you're welcome!
>
> Also under `tools/windows` there is a build setup based on a
Vagrant VM
> and Ansible, so feel free to take the best of all worlds
(even if you
> don't "speak" Ansible, the approach should be obvious from
reading
> through the yaml files and the documentation).
>
> Thanks, Eric
>
> [1] https://github.com/rdiff-backup/rdiff-backup/issues/105
>
>
>
> On 19/11/2019 10:54, Arrigo Marchiori wrote:
> > Hello,
> >
> > On Sun, Nov 17, 2019 at 09:29:10PM +0000, EricZolf wrote:
> >
> >> Hi,
> >> good question, let me try to summarize the current state:
> >>
> >> - migration to Python 3 is finished, there are no known
> regressions.
> >> - we've fixed a fair amount of smaller bugs and cleaned
the repo
> structure
> >> - testing on Linux is done automatically and regularly so
that
> I'm quite confident about the quality of the code on this
platform
> >> - testing on Windows would need more love - anybody is
welcome
> to test who can compile rdiff-backup
> >
> > I developed a small build system:
> > https://github.com/ardovm/rdiff-backup-build
> > that makes an self-contained EXE file (as did previous stable
> > releases) starting from the sources of librsync and
rdiff-backup.
> >
> > It can also make self-contained binaries for Linux, and
possibly
> other
> > Unix-based systems (to be tested).
> >
> > Contributions, comments etc. are of course welcome.
> >
> > [...]
> >> Writing these lines, I realise that I should try to
generate a
> beta release (even if only manually) so that people can more
easily
> test, without the trouble of compiling the code.
> >
> > I was also expecting this. IMHO it is better to have a
release tag,
> > alpha- or beta- is ok, but it must have a name, that we
will be able
> > to refer to in bug reports etc.
> >
> > Once we have the tag, I could help generating the
binaries, if you
> > think it would be useful.
> >
> > Best regards,
> >
>