please note that this is a fork of git-annex

[joeyh]

This is not the canonical git-annex repository. You have applied (and then reverted) an AI generated patch to it. You are tracking supposed bugs here. Thus, this is a fork (in the traditional sense, not the git sense), and it must be documented as such.

[joeyh]

Also note that, as this is a fork, git-annex is no longer distributing artifacts built from this repository.

[yarikoptic]

Please review

• doc: clarify that we are potentially providing builds of modified git-annex #261

which modifies README for that -- https://github.com/datalad/git-annex/blob/enh-README/README.md ,
where I have aimed to address all of your concerns and while at it to extend description overall.

I didn't call the repository itself a "fork" since AFAIK it is not, as it even doesn't contain modified sources. I do describe that it provides a "distribution" for git-annex, analogously in spirit to any other distribution of any other software where builds, potentially patched, are provided.

[joeyh]

I have no interest in debating semantics.

I do wonder when the datalad project as a whole decided to change the existing purpose of this repository, and why the documentation was not updated at the point in time when you did, when #251 was merged into master in contradiction to what was documented in the README. At that point, you violated my trust and the trust of my users IMHO.

[yarikoptic]

I am really sorry that you feel that we (DataLad project), or specifically I as leading this particular aspect of it, violated anybody's trust as I was always paying particular attention to stating provenance of changes and providing adequate attribution, and never attempting or doing any malicious actions. It is the only way, since we (DataLad, and I) heavily rely on trusting you and all the open-source projects we use in DataLad! So I really hope that we could figure out how to remain trustworthy to each other.

AFAIK. the purpose of this repository was always to build, test, and distribute git-annex to benefit all users of git-annex (and DataLad). As with any other distribution, since awhile we implemented and documented in README the patching capability, which we had to use a few times to address some FTBFS or other bugs through patches originating from us, or potentially cherry-picked from upstream (you). I find it difficult to answer "when" since AFAIK there were no change in the purpose of this repository.

Specifically to #251: that minimal patch, which I informed you about, I merged since it looked benign, passed the tests, and fixed a bug for me . So, altogether, the standard practice in FOSS distributions. That is why I am really missing on what contradiction you have in mind, please clarify. May be indeed documentation should be updated even beyond even what I proposed in #261?

Then you promptly identified that some AI statement was incorrect in the description and generalized the fix to be of a wider benefit. As soon as you pushed the proper fix -- patch was removed immediately after in 995f177 .

If somehow I overstepped some written or unwritten terms or conditions, I am sorry but it definitely was not of any ill will.

Since no objections to #261 I will merge it since it describe the structure and purpose of this repository more fully, but this issue would remain available for further comments and clarifications if needed.

[yarikoptic]

FTR for (continued) full disclosure since that information is not versioned anyhow on github AFAIK: I have now spotted that there is "No PRs will be merged, but could be used to test perspective git-annex patches." in the sidebar description of the repository. I think that is what Joey might have had in mind.

Indeed, we (likely I) should have been clearer in the intention statement there (e.g., "no PR against upstream branch" or "no external PR" if that what was meant originally) or updated when we merged first PR ever (#6 ?) which was concerned with establishing git-annex branch itself here, or ever pushed (was not even a PR I think) first patch, or (edited) likely when we documented in the README submission and merging of patches workflow in 2022, or ... Overall the wording of description was unclear and potentially misleading. Sorry about that -- removed now.