By it's very nature, backup tends to be a conservative entity. Whilst I'm no stranger to
agile code and chasing the latest and coolest features. I don't think this migration is
a fork in the sense of a change of direction. I don't really see much evidence of a desire
for custom versions and multiple repos - Backuppc is just not that sort of software.
From reading this list for some time now, I feel the move to github is more about the project
keeping pace with peoples "business needs" in terms of keeping the software relevant,
operating reliably. And also getting 4.0 into a stable state.
Certainly there is a strong sense of community in Backuppc and it's features are
quite unique. I'm glad to see the enthusiasm to help pick up the slack and the momentum
where Craig is under pressure with other things. This is all happening with his blessing
if I'm not mistaken? So I don't think there is any intended negatives to this.
Following two discussion lists is a bit messy however. Whilst the archives are an invaluable resource
on sourceforge, ultimately I'd love to see everything consolidated.
Graham
From: David Cramblett [mailto:david AT functionalchaos DOT net]
Sent: 07 June 2016 17:48
To: General list for user discussion, questions and support <backuppc-users AT lists.sourceforge DOT net>
Subject: Re: [BackupPC-users] Is this software abandoned? Who is packager Bernard Johnson?
I'm very familiar with GitHub. However, forking a "github repo" and forking a "project" have different connotations.
On Tue, Jun 7, 2016 at 12:41 AM, Kenneth Porter <shiva AT sewingwitch DOT com> wrote:
On 6/6/2016 9:52 AM, David Cramblett wrote:
> Not forking, just migrating to GitHUb. Craig will still be project
> lead and maintain control. This is probably what you meant, just want
> to be clear for others who may read this.
It wasn't clear to me whether Craig would be returning.
However, note that the git architecture naturally creates forks, if only
short-lived ones. It allows us all to pick and choose patches from
downstream repos to create our own custom version of a project. So if
Craig gets busy and can't keep up with everyone's fixes, someone else
can gather them in an independent repo. Much like the way there are many
Linux kernels that share the same core code but focus on different
objectives. This isn't a bad thing. Embrace it. Much like we enjoy
"covers" of popular songs.
--