Re: Release Plan

[Patrik Dufresne]

Hello

Regarding our release plan. Had a chat with someone on #debian-mentors
regarding the packaging of rdiff-backup for Debian. I'm not sure of all the
step required to make this happen, could we get more details about what
should be done, what is missing, what are the step to make this happen.

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