Release Plan

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Release Plan

Frank Crawford
Eric,

Are you still looking at doing a release before the end of the year?

If so, what items do you still need to complete, and can we help you
out with it?

Regards
Frank
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

ewl+rdiffbackup
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
- cross-platform testing is also a topic where we need testers
- if nobody takes care of MacOS, it'll get dropped as an officially supported platform (we won't remove code, but it'll be by chance that it'll work)
- the remaining enhancements we need for this release (mainly around CI/CD) are mostly addressed via on-going PRs, here Otto and Patrick must tell if they need support. There was little movement in the recent past.

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.
Let me work on it, and come back to you.

KR, Eric


On November 17, 2019 10:59:14 AM UTC, Frank Crawford <[hidden email]> wrote:
>Eric,
>
>Are you still looking at doing a release before the end of the year?
>
>If so, what items do you still need to complete, and can we help you
>out with it?
>
>Regards
>Frank

Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

Robinson, Eric-2
Guys, not that I mind being included in internal discussions about rdiff-backup development (it's actually quite interesting) but I don't think you intended me to be in this discussion.  ;-)

-Eric R.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: rdiff-backup-users <rdiff-backup-users-bounces+eric.robinson=[hidden email]> on behalf of EricZolf <[hidden email]>
Sent: Sunday, November 17, 2019 3:29:10 PM
To: [hidden email] <[hidden email]>
Subject: Re: Release Plan

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
- cross-platform testing is also a topic where we need testers
- if nobody takes care of MacOS, it'll get dropped as an officially supported platform (we won't remove code, but it'll be by chance that it'll work)
- the remaining enhancements we need for this release (mainly around CI/CD) are mostly addressed via on-going PRs, here Otto and Patrick must tell if they need support. There was little movement in the recent past.

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.
Let me work on it, and come back to you.

KR, Eric


On November 17, 2019 10:59:14 AM UTC, Frank Crawford <[hidden email]> wrote:
>Eric,
>
>Are you still looking at doing a release before the end of the year?
>
>If so, what items do you still need to complete, and can we help you
>out with it?
>
>Regards
>Frank

Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

ewl+rdiffbackup
Hi Eric,

I'm not sure how you mean this remark:

- if you fear to hear secrets not meant for users, do not fear! One, it's open source so there is nothing secret; two, it's also meant for users, because users are the best beta testers! And you're welcome to help!
- if you feel disturbed, we don't have a separate list for developers, we can have one if really needed, but it's not like we're generating a lot of traffic, and perhaps we can do without?
- if you meant something else, then I didn't get it :-P

KR, Eric

On November 17, 2019 10:05:59 PM UTC, Eric Robinson <[hidden email]> wrote:

>Guys, not that I mind being included in internal discussions about
>rdiff-backup development (it's actually quite interesting) but I don't
>think you intended me to be in this discussion.  ;-)
>
>-Eric R.
>
>Get Outlook for Android<https://aka.ms/ghei36>
>
>________________________________
>From: rdiff-backup-users
><rdiff-backup-users-bounces+eric.robinson=[hidden email]> on
>behalf of EricZolf <[hidden email]>
>Sent: Sunday, November 17, 2019 3:29:10 PM
>To: [hidden email] <[hidden email]>
>Subject: Re: Release Plan
>
>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
>- cross-platform testing is also a topic where we need testers
>- if nobody takes care of MacOS, it'll get dropped as an officially
>supported platform (we won't remove code, but it'll be by chance that
>it'll work)
>- the remaining enhancements we need for this release (mainly around
>CI/CD) are mostly addressed via on-going PRs, here Otto and Patrick
>must tell if they need support. There was little movement in the recent
>past.
>
>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.
>Let me work on it, and come back to you.
>
>KR, Eric
>
>
>On November 17, 2019 10:59:14 AM UTC, Frank Crawford
><[hidden email]> wrote:
>>Eric,
>>
>>Are you still looking at doing a release before the end of the year?
>>
>>If so, what items do you still need to complete, and can we help you
>>out with it?
>>
>>Regards
>>Frank
>
>Disclaimer : This email and any files transmitted with it are
>confidential and intended solely for intended recipients. If you are
>not the named addressee you should not disseminate, distribute, copy or
>alter this email. Any views or opinions presented in this email are
>solely those of the author and might not represent those of Physician
>Select Management. Warning: Although Physician Select Management has
>taken reasonable precautions to ensure no viruses are present in this
>email, the company cannot accept responsibility for any loss or damage
>arising from the use of this email or attachments.
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

Arrigo Marchiori
In reply to this post by ewl+rdiffbackup
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,
--
rigo

http://rigo.altervista.org

Reply | Threaded
Open this post in threaded view
|

RE: Release Plan

Robinson, Eric-2
In reply to this post by ewl+rdiffbackup
Thanks, Eric (Z.), I understand now. I got confused for a minute because my name is also Eric, so I thought the message was sent to me by mistake. I eventually figured out that it was a general message.

--Eric (R.)

-----Original Message-----
From: rdiff-backup-users <rdiff-backup-users-bounces+eric.robinson=[hidden email]> On Behalf Of EricZolf
Sent: Monday, November 18, 2019 3:31 PM
To: [hidden email]
Subject: Re: Release Plan

Hi Eric,

I'm not sure how you mean this remark:

- if you fear to hear secrets not meant for users, do not fear! One, it's open source so there is nothing secret; two, it's also meant for users, because users are the best beta testers! And you're welcome to help!
- if you feel disturbed, we don't have a separate list for developers, we can have one if really needed, but it's not like we're generating a lot of traffic, and perhaps we can do without?
- if you meant something else, then I didn't get it :-P

KR, Eric

On November 17, 2019 10:05:59 PM UTC, Eric Robinson <[hidden email]> wrote:

>Guys, not that I mind being included in internal discussions about
>rdiff-backup development (it's actually quite interesting) but I don't
>think you intended me to be in this discussion.  ;-)
>
>-Eric R.
>
>Get Outlook for Android<https://aka.ms/ghei36>
>
>________________________________
>From: rdiff-backup-users
><rdiff-backup-users-bounces+eric.robinson=[hidden email]> on
>behalf of EricZolf <[hidden email]>
>Sent: Sunday, November 17, 2019 3:29:10 PM
>To: [hidden email] <[hidden email]>
>Subject: Re: Release Plan
>
>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
>- cross-platform testing is also a topic where we need testers
>- if nobody takes care of MacOS, it'll get dropped as an officially
>supported platform (we won't remove code, but it'll be by chance that
>it'll work)
>- the remaining enhancements we need for this release (mainly around
>CI/CD) are mostly addressed via on-going PRs, here Otto and Patrick
>must tell if they need support. There was little movement in the recent
>past.
>
>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.
>Let me work on it, and come back to you.
>
>KR, Eric
>
>
>On November 17, 2019 10:59:14 AM UTC, Frank Crawford
><[hidden email]> wrote:
>>Eric,
>>
>>Are you still looking at doing a release before the end of the year?
>>
>>If so, what items do you still need to complete, and can we help you
>>out with it?
>>
>>Regards
>>Frank
>
>Disclaimer : This email and any files transmitted with it are
>confidential and intended solely for intended recipients. If you are
>not the named addressee you should not disseminate, distribute, copy or
>alter this email. Any views or opinions presented in this email are
>solely those of the author and might not represent those of Physician
>Select Management. Warning: Although Physician Select Management has
>taken reasonable precautions to ensure no viruses are present in this
>email, the company cannot accept responsibility for any loss or damage
>arising from the use of this email or attachments.
Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

ewl+rdiffbackup
In reply to this post by Arrigo Marchiori
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,
>

Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

Patrik Dufresne-2
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.
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

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.

--
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 <[hidden email]> 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,
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

ewl+rdiffbackup
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 <[hidden email]
> <mailto:ewl%[hidden email]>> 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,
>      >
>

Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

Patrik Dufresne-2
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 <[hidden email]> 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 <[hidden email]
> > <mailto:ewl%[hidden email]>> 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,
> >      >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Beta 1.4.0b0 available [Re: Release Plan]

ewl+rdiffbackup
In reply to this post by ewl+rdiffbackup
Hi,

On 17/11/2019 22:29, EricZolf wrote:
> 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.

So, I've created a release in GitHub (yeah!), it's far from perfect and
I'm looking forward to see the automated release pipeline from Otto,
Patrik and/or Arrigo, so that we get this as automated as possible.

 From my part, I'll revamp the documentation, it's currently mixing
development, installation and usage, and doesn't properly highlight the
requirements.

In the meantime, anybody can download the Linux binaries from
https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta -
install and test. Windows will follow shortly (tonight, I hope).

Remember: it's a beta version, be careful!

- if you're confused or not sure, ask on this mailing list
- if you find a bug, create an issue on GitHub with rdiff-backup
version, OS and its version, command and log with -v9 verbosity.

Let's get the ball rolling,
Eric

Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

Frank Crawford
Eric,

On Sat, 2019-11-23 at 11:08 +0100, [hidden email] wrote:

> Hi,
> On 17/11/2019 22:29, EricZolf wrote:
> > 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.
>
> So, I've created a release in GitHub (yeah!), it's far from perfect
> and I'm looking forward to see the automated release pipeline from
> Otto, Patrik and/or Arrigo, so that we get this as automated as
> possible.

Congratulations on reaching this milestone, and thank you for all your
hard work.

>  From my part, I'll revamp the documentation, it's currently mixing
> development, installation and usage, and doesn't properly highlight
> the requirements.
> In the meantime, anybody can download the Linux binaries from
> https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta
> - install and test. Windows will follow shortly (tonight, I hope).

I'll also see if I can push a version to Fedora rawhide over the
weekend, so you can pull down the current RPM for it.

> Remember: it's a beta version, be careful!
> - if you're confused or not sure, ask on this mailing list- if you
> find a bug, create an issue on GitHub with rdiff-backup version, OS
> and its version, command and log with -v9 verbosity.

I think I need to push a couple of small changes to the RPM spec file
templates to build with SCM, that can wait until I've tested with the
Fedora build system.

> Let's get the ball rolling,Eric

Regards
Frank
Reply | Threaded
Open this post in threaded view
|

Re: Release Plan

ewl+rdiffbackup
In reply to this post by Patrik Dufresne-2
Hi,

On 21/11/2019 14:49, Patrik Dufresne wrote:
> 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.

My understanding is that Otto is already the Debian packager of
rdiff-backup [1] and that he'll shout loud and clear if he's not able to
package the next version of it :-)

Based on my personal experience as Debian packager, as upstream project,
we just need to "stay out of the way", i.e. in a nutshell make sure to have:

- clearly released source code
- no hidden or very strange dependencies
- no binaries in the source code
- fully automatable build and installation process
- rather stable structure of build and installation process (packagers
don't like to redo their package anew with each new release)
- support the packager if he has questions or improvement suggestions to
make their life easier

And I think those are all given in our case, but Otto is very welcome to
comment. Same thing for Frank and Fedora [2]!

KR, Eric

PS: please don't put me in copy of the list, I'm on it and I read it.

[1] https://packages.debian.org/bullseye/rdiff-backup (right hand side).
[2] https://apps.fedoraproject.org/packages/rdiff-backup/overview/

>
> 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 <[hidden email]
> <mailto:ewl%[hidden email]>> 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 <[hidden email]
>     <mailto:ewl%[hidden email]>
>      > <mailto:ewl%[hidden email]
>     <mailto:ewl%[hidden email]>>> 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,
>      >      >
>      >
>


Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

ewl+rdiffbackup
In reply to this post by Frank Crawford
Hi,

thanks for the flowers but it's team work.

On 23/11/2019 12:58, Frank Crawford wrote:
> I'll also see if I can push a version to Fedora rawhide over the
> weekend, so you can pull down the current RPM for it.

That would be great, I'm on Fedora 31. From [1] I think you could close
the Python 2 and the EPEL 8 bug with the next release.

As a side note, I discovered the 3rd bug about restore-as-of - I haven't
understood at first lecture, need to have a deeper look and perhaps
create an upstream issue...

>> Remember: it's a beta version, be careful!
>>
>> - if you're confused or not sure, ask on this mailing list
>> - if you find a bug, create an issue on GitHub with rdiff-backup
>> version, OS and its version, command and log with -v9 verbosity.
>
> I think I need to push a couple of small changes to the RPM spec file
> templates to build with SCM, that can wait until I've tested with the
> Fedora build system.

Yes, I've always had mixed feelings about upstream packages, they can
only be generic, where most distributions actually need specific packages.

Thanks, Eric

[1] https://apps.fedoraproject.org/packages/rdiff-backup/bugs/#

Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

Patrik Dufresne-2
@EricZolf
I'm confused about how you manage to build the binaries packages (.whl).
It's not part of any pipeline so I'm guessing you have compiled them
manually ?

--
Patrik Dufresne Service Logiciel inc.
http://www.patrikdufresne.com <http://patrikdufresne.com/>/
514-971-6442
130 rue Doris
St-Colomban, QC J5K 1T9


On Sat, Nov 23, 2019 at 7:18 AM <[hidden email]> wrote:

> Hi,
>
> thanks for the flowers but it's team work.
>
> On 23/11/2019 12:58, Frank Crawford wrote:
> > I'll also see if I can push a version to Fedora rawhide over the
> > weekend, so you can pull down the current RPM for it.
>
> That would be great, I'm on Fedora 31. From [1] I think you could close
> the Python 2 and the EPEL 8 bug with the next release.
>
> As a side note, I discovered the 3rd bug about restore-as-of - I haven't
> understood at first lecture, need to have a deeper look and perhaps
> create an upstream issue...
>
> >> Remember: it's a beta version, be careful!
> >>
> >> - if you're confused or not sure, ask on this mailing list
> >> - if you find a bug, create an issue on GitHub with rdiff-backup
> >> version, OS and its version, command and log with -v9 verbosity.
> >
> > I think I need to push a couple of small changes to the RPM spec file
> > templates to build with SCM, that can wait until I've tested with the
> > Fedora build system.
>
> Yes, I've always had mixed feelings about upstream packages, they can
> only be generic, where most distributions actually need specific packages.
>
> Thanks, Eric
>
> [1] https://apps.fedoraproject.org/packages/rdiff-backup/bugs/#
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

Eric Lavarde
In reply to this post by ewl+rdiffbackup
Hi,

On 23/11/2019 11:08, [hidden email] wrote:
> In the meantime, anybody can download the Linux binaries from
> https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta -
> install and test. Windows will follow shortly (tonight, I hope).

Windows binary is out and can be used on any Windows with 64 bits support!

Just FYI, not relevant for tests: the version given by `rdiff-backup
--version` is DEV not 1.4.0b0.

@Patrik something to look into, we know where it comes from... ;-)
Issue #190 created

KR, Eric

https://github.com/rdiff-backup/rdiff-backup/issues/190

Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

Patrik Dufresne
Would need to get access to the build script used to generate it. Most
likely, the exe is missing the pkg-info.

On Sat, Nov 23, 2019, 10:46 AM Eric Lavarde, <[hidden email]> wrote:

> Hi,
>
> On 23/11/2019 11:08, [hidden email] wrote:
> > In the meantime, anybody can download the Linux binaries from
> > https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta -
> > install and test. Windows will follow shortly (tonight, I hope).
>
> Windows binary is out and can be used on any Windows with 64 bits support!
>
> Just FYI, not relevant for tests: the version given by `rdiff-backup
> --version` is DEV not 1.4.0b0.
>
> @Patrik something to look into, we know where it comes from... ;-)
> Issue #190 created
>
> KR, Eric
>
> https://github.com/rdiff-backup/rdiff-backup/issues/190
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

ewl+rdiffbackup
On 23/11/2019 16:50, Patrik Dufresne wrote:
> Would need to get access to the build script used to generate it. Most
> likely, the exe is missing the pkg-info.

Because I like so much Windows, I do my best to stay away from it: all
Windows build steps are under `tools/windows` in Ansible playbooks (with
a readme file). Even if you don't speak Ansible, I think that the
playbooks are readable enough to understand what they're doing.

If you find the magic commands to fix this, I can adapt the playbooks
accordingly.

KR, Eric

>
> On Sat, Nov 23, 2019, 10:46 AM Eric Lavarde, <[hidden email]> wrote:
>
>> Hi,
>>
>> On 23/11/2019 11:08, [hidden email] wrote:
>>> In the meantime, anybody can download the Linux binaries from
>>> https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta -
>>> install and test. Windows will follow shortly (tonight, I hope).
>>
>> Windows binary is out and can be used on any Windows with 64 bits support!
>>
>> Just FYI, not relevant for tests: the version given by `rdiff-backup
>> --version` is DEV not 1.4.0b0.
>>
>> @Patrik something to look into, we know where it comes from... ;-)
>> Issue #190 created
>>
>> KR, Eric
>>
>> https://github.com/rdiff-backup/rdiff-backup/issues/190
>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

ewl+rdiffbackup
In reply to this post by Eric Lavarde
Hi,

On 23/11/2019 16:45, Eric L. wrote:
> On 23/11/2019 11:08, [hidden email] wrote:
>> In the meantime, anybody can download the Linux binaries from
>> https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta 
>> - install and test. Windows will follow shortly (tonight, I hope).
>
> Windows binary is out and can be used on any Windows with 64 bits support!

I had forgotten that the wheel packages are specific for a Python
version, the wheel packages for Python 3.5 to 3.8 are now available
under the above URL.

Happy testing! Eric

Reply | Threaded
Open this post in threaded view
|

Re: Beta 1.4.0b0 available [Re: Release Plan]

Frank Crawford
In reply to this post by Frank Crawford
On Sat, 2019-11-23 at 22:58 +1100, Frank Crawford wrote:

> Eric,
> On Sat, 2019-11-23 at 11:08 +0100, [hidden email] wrote:
> > Hi,On 17/11/2019 22:29, EricZolf wrote:
> > > Writing these lines, I realise that I should try to generate a
> > > betarelease (even if only manually) so that people can more
> > > easilytest, without the trouble of compiling the code.
> >
> > So, I've created a release in GitHub (yeah!), it's far from
> > perfectand I'm looking forward to see the automated release
> > pipeline fromOtto, Patrik and/or Arrigo, so that we get this as
> > automated aspossible.
>
> Congratulations on reaching this milestone, and thank you for all
> yourhard work.
> >  From my part, I'll revamp the documentation, it's currently
> > mixingdevelopment, installation and usage, and doesn't properly
> > highlightthe requirements.In the meantime, anybody can download the
> > Linux binaries from
> > https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.4.0.beta
> > - install and test. Windows will follow shortly (tonight, I hope).
>
> I'll also see if I can push a version to Fedora rawhide over
> theweekend, so you can pull down the current RPM for it.

Okay, so I have pushed the beta to Fedora rawhide for anyone who wants
to try it there, but I've also created a COPR repository for all
supported architectures for F29, F30, F31, EPEL7 & EPEL8.

You can access it with "dnf copr enable frankcrawford/rdiff-backup" and
then "dnf install rdiff-backup".

Note that this the beta version, with all the standard
qualifications.  Also, while it should be compatible with existing
backups, you cannot mix current Fedora python2 release (1.2.8) and this
release.

Frank

 
12