hi,
On Wed, Mar 15, 2023 at 12:16:04PM -0400, Tim Kelly wrote:
> 1) first commit attributed to me was not written by me and broke a lot of
> stuff and had to be reverted
Yeah, it was a mistake and I think the correct way in that case would
be to put me like author and you in a footer like 'Reported-by:'. Cases
like that one would be caught better following a more strict review
process.
> 2) identification and isolation of bugs go unattributed
>
> 3) patches get rejected, leaving my tree out of sync and require hand
> modifying (to paraphrase one rejection: "programmers don't need feedback
> about errors, let them read the man pages")
You cannot force people to accept your changes in the way you wrote
them. I tried to simplify the process removing unneeded round
trips. Sorry if the attribution of the patches were lost in some
moment, but we usually don't care so much about these kind of things.
I can understand that they are important for you, but you should
also try to understand that other people have relaxed point of
views and can make mistakes about it. This is what I am trying to
solve now.
Also, you have to understand that a project maintainer can take
the decisions about what changes to be merged, and what changes not
to be merged.
>
> 4) patches get modified without attribution or opportunity to revise,
> leaving my work incompatible, and either I have to back out my own work or
> get further out of sync
As I said I just tried to avoid unneeded round trips. I had to live
with even 5 iterations upstreaming to some projects and I usually
prefer to avoid it to make the life of everyone easier. Doing
multiple iterations would also create the same problems in you if
you cannot work directly over the diff, and I am not going to accept
patches with known problems because it breaks the history.
> 5) I don't even have git on my main development environment (32-bit Minix
> 3.1.6) and will absolutely not port a GPL tool to it (use Fossil ffs)
You don't have to port git. 9front wrote its own git implementation
from scratch for example [1] (in fact, OpenBSD is creating its own
git implementation based in the code from 9front).
Still, you don't need to use a tool to follow the format, just to
know how to write patch files that can be automatically applied
containing all the metadata for ownership, summary and comments.
Otherwise I have to rephrase and reorganize your commit comments
before applying them and in that case maybe I should add me like a
co-author. This is why I ask you to follow that convention that
avoids that problem because then the commit is created just from
your diff file.
>
> 7) stunning hypocrisy to suggest I need to follow better commit and patch
> protocols
> 8) stunning hypocrisy to complain about having to hand-modify patches
>
Sorry if you felt that I was being hypocratic, I just pointed you to
common resources used in many projects and followed by the scc project
itself. Please, just try to understand that we can have some protocols
and in your case I tried to relax them to make easier for you to upstream
contributions but then I mistook and then you got angry with me. I apologize
for my errors but to avoid future problems I just tried to follow strictly
the process to avoid new mistakes from my side or your side in the future.
If we follow this process then the patch will not be applied until all of us
we agree that it is in the correct shape, including attributions and comments
in the commit.
Again, sorry because I think the shorcuts that I applied were harmful at the
end, but I just tried to make easier to upstream your contributions.
> Basically, I'm upstreaming my patches as a courtesy.
Thank you for that. I am just trying to follow the etiquette that would
avoid new mistakes in the future.
Regards
[1]
https://github.com/oridb/git9
--
To unsubscribe send a mail to scc-dev+unsubscribe_at_simple-cc.org
Received on Wed 15 Mar 2023 - 17:53:15 CET