Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get rid of master/slave terminology #5248

Open
ThomasWaldmann opened this issue Jul 7, 2020 · 9 comments
Open

get rid of master/slave terminology #5248

ThomasWaldmann opened this issue Jul 7, 2020 · 9 comments
Labels

Comments

@ThomasWaldmann
Copy link
Member

@ThomasWaldmann ThomasWaldmann commented Jul 7, 2020

master/slave was used a lot in the code that deals with hardlinks:

when we archive multiple hardlinks pointing to same inode (file contents), this happens:

  • the first encountered hardlink is treated like any regular file: its file contents are chunked, chunks written to repo, file metadata and chunkid_list is written to the archived item.
  • all afterwards discovered hardlinks referring to same inode also create a regular file item, but its source attribute points back to the name of the first encountered hardlink. these items do not have a chunkid_list and thus no own content.

so we need new terminology for this now, please suggest.

@ThomasWaldmann
Copy link
Member Author

@ThomasWaldmann ThomasWaldmann commented Jul 7, 2020

maybe:

  • full hardlink vs. reference hardlink
  • contentful hardlink vs. contentless/reference hardlinks

don't like:

  • primary / secondary (because there might be any amount, not just 2. also, in the filesystem, hardlinks are fully symmetric)
@strugee
Copy link

@strugee strugee commented Jul 8, 2020

canonical/alias maybe?

@ThomasWaldmann
Copy link
Member Author

@ThomasWaldmann ThomasWaldmann commented Jul 9, 2020

@strugee i know that terminology rather from naming things. but in our case, hardlink names are all equally "good" in the filesystem (only for symlinks, there is a asymmetry).

So this is rather about how borg stores these items in the archive.

@strugee
Copy link

@strugee strugee commented Jul 10, 2020

Yeah, I see what you're saying 👍

* contentful hardlink vs. contentless/reference hardlinks

The more I think about it the more I like this pairing. It does a pretty good job communicating the idea right in the name, without needing a ton of further explanation.

@ThomasWaldmann
Copy link
Member Author

@ThomasWaldmann ThomasWaldmann commented Jul 25, 2020

Not sure why there is a thumbs down on the top post, but maybe it needs some clarification:

Of course renaming some words in an open source project does not change history nor does it improve the situation of slaves that still exist in today's world.

but keeping such negatively loaded terminology without a good reason or opposing to change them would be even worse, so let's just change them.

of course they were never meant in any negative way.

@deathtrip
Copy link

@deathtrip deathtrip commented Jul 30, 2020

no need to inject divisive politics into open source software

@enkore
Copy link
Contributor

@enkore enkore commented Jul 30, 2020

primary/reference, stored/referencing [hardlink], first/following (<-- this is very accurate, but the terms are possibly too generic to be immediately registered as "jargon"). Contentful/contentless is very accurate and descriptive as well, but imho as far as contrasting pairs go both are pretty similar if you squint your eyes.

no need to inject divisive politics into open source software

As far as I can tell this is your first comment on a borg repo, perhaps contribute something else before trying to tell people what to do.

@enkore
Copy link
Contributor

@enkore enkore commented Jul 30, 2020

master chunks index -> primary/main chunks index (when referring to .../cache/.../chunks) and reference chunks index (in the case of borg.hashindex.ChunkIndex.stats_against -- the docstring basically calls it this already).

Renaming base branches might be a little bit annoying, but I'd suggest develop over latest, so that people are less tempted to run "the latest version" in production. Honestly "master" as a base branch name in git has always made little sense, if any. A poor default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.