1.0 goals

[ThomasWaldmann]

When looking at the current 1.0 milestone, one sees different goals:

• getting rid of legacy (like dropping support for old pythons and deprecated functionality in borg, being able to use newer python/stdlib features, libraries not supporting 3.2)
• smaller, but incompatible changes (like changing env var semantics, using different defaults)
• more far fetched goals needing bigger redesigns of borg (like crypto changes)

I currently have the idea that we could have a few more 0.xx releases (just fixing the stuff that is broken / causing issues with minimal effort) while starting to work on 1.0 (but without the more far fetched stuff, pushing that to 2.0).

Comments? Ideas?

[level323]

Your suggestion sounds reasonable to me.

If there was any 'big' issue that I'd like to see put in the 1.0 roadmap it
would be further enhancements toward minimal bandwidth consumption for
cache synchronisation. I'm thinking particularly of the use case where
there are multiple remote machines backing up to a single borg repo, the
links being relatively slow (e.g. DSL). This, to me, is a super-awesome use
case.

My understanding (correct me if I'm wrong) is that the only up-to-date
cache that is strictly required on the source machine is the chunks cache
(because the files cache is only needed to list/restore archives and the
repo index is only required on the destination machine because that's where
the repo resides). My understanding (again, possibly wrong/out-of-date) is
that borg in the above use case is still syncing the files cache and
therefore pulling down files caches for backups performed by other machines
to the same central repo more or less needlessly.

My apologies in advance if this has already been dealt with or I'm just
plain wrong about this.... I try to keep up with borg changes in my
out-of-hours time but the changes have been coming so thick and fast
[kudos, btw!] that I may have missed the implementation already.

On 2 November 2015 at 06:24, TW [email protected] wrote:

When looking at the current 1.0 milestone, one sees different goals:

• getting rid of legacy (like dropping support for old pythons and
  deprecated functionality in borg, being able to use newer python/stdlib
  features, libraries not supporting 3.2)
• smaller, but incompatible changes (like changing env var semantics,
  using different defaults)
• more far fetched goals needing bigger redesigns of borg (like crypto
  changes)

I currently have the idea that we could have a few more 0.xx releases
(just fixing the stuff that is broken / causing issues with minimal effort)
while starting to work on 1.0 (but without the more far fetched stuff,
pushing that to 2.0).

Comments? Ideas?

—
Reply to this email directly or view it on GitHub
#356.

[anarcat]

this seems to overlap with #1, no?

otherwise i think that #26 should be clarified before we publish a 1.0: how will upgrades happen from 0.x, what about 2.0... etc.

[anarcat]

in #1, i also mention the importance of clarifying the way the project operates. right now, we have "the borg collective" documented as a uniform entity, but it is not quite the case: some have commit access, some don't, and one has admin access everywhere (@ThomasWaldmann). it would help to clarify that structure and how decisions are taken. having a code of conduct would also be useful when problems arise.

i think this is why we did the fork, didn't we? :)

[ThomasWaldmann]

@anarcat with #1 please stay in #1. this ticket is to discuss technical goals. it's also not about policy or CoC discussions (which I find rather boring and time consuming at the same time).

[ThomasWaldmann]

@level323 yes, less expensive cache sync is on the radar.

[anarcat]

@ThomasWaldmann i guess i don't see the (need for?) distinction...

[ThomasWaldmann]

I've dissected stuff into 1.0 and 2.0 milestones.

Following the idea in first post, 1.0 is to get rid of legacy (python, bad defaults, deprecated stuff).

There are some "breaking" tags, but they are mostly harmless - people might just need to read the changelog and adapt their scripts a bit. Also, they will need a relatively new python (we'll require 3.4).

[jungle-boogie]

Yes, clean up old code so you don't have to deal with it later.

read this: http://www.tedunangst.com/flak/post/out-with-the-old-in-with-the-less

[ThomasWaldmann]

ok, as milestone for 1.0 is set up and populated, thus goals are clear, i am closing this.