From: Stefan Beller <email@example.com> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: "Jonathan Nieder" <firstname.lastname@example.org>, "Junio C Hamano" <email@example.com>, "Phillip Wood" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Ævar Arnfjörð Bjarmason" <email@example.com> Subject: Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output Date: Wed, 7 Jun 2017 09:53:11 -0700 [thread overview] Message-ID: <CAGZ79ka5VnfvidpsWCe5py6uW2Yp0y9gHfdZt+aZSdyfEi8Fsg@mail.gmail.com> (raw) In-Reply-To: <alpine.DEB.126.96.36.1996071520280.171564@virtualbox> On Wed, Jun 7, 2017 at 7:47 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Hi Stefan, > > On Tue, 6 Jun 2017, Stefan Beller wrote: > >> On Tue, Jun 6, 2017 at 3:22 PM, Johannes Schindelin >> <Johannes.Schindelin@gmx.de> wrote: >> >> > 3) the only person who could make that call is Junio >> >> Occasionally I think the same, but in fact it is not true. > > Again my poor English skillz make sure I get misunderstood. So bear with > me, please, and let me try again. I don't think it is a language thing, but a matter of perspective. > > The current What's cooking mails are full of stuff other than the > transition from SHA-1 to a new function. True, but there is also * bw/object-id (2017-06-05) 33 commits ... Conversion from uchar to struct object_id continues. Will merge to 'next'. > In fact, every once in a while I > see brian carlson's patch series with the remark "Needs review" while > other patch series get reviewed even by Junio. So are you trying to impose priorities on what Junio has to review? (It sounds like so, but maybe you are just stating an observation, and a conclusion with an actionable item comes next) Sometimes I disagree with what Junio does and in which order, too. But he has more experience in how to guide a successful community, so I respect what he does even if I would have done it differently (such as a different order). > > In my mind, this sends a message. In the simplest form the message could be understood as a call for help to review the patches Brian sent. And the fact that YOU are not reviewing the patches, tells me that you have more important things to do, such as running a fork of Git. In my perception the conversion is picking up speed. It used to be Brian who decided to start this years ago as a one-man show, but now we have multiple people working on it * Brian sending out more patches, as more review happens: https://firstname.lastname@example.org/ https://public-inbox.org/git/20170509221322.GA106700@google.com/ * Brandon picking up one part of the conversion series (mentioned before, see current cooking email) * A potential migration plan has been made "Git hash function transition" (https://goo.gl/gh2Mzc). See the note atop the document "Note: this draft is somewhat out of date and is being reworked (in particular to use a different hash function). See public-inbox.org/git for more current discussion." * There are not a lot of patches, which do not have written "SHA1 CONVERISON" all over their face. (This one has, I made it last night as a one off response to this thread: https://email@example.com/) > > If, hypothetically, a couple of What's cooking mails would have in their > header some language to the extent that we need to focus on transitioning > away from SHA-1, and maybe even have the promise that Junio would not > review other patch series as long as there are patches to review that > prepare the tests for the transition, that convert more 20 and 40 > constants, that convert more users to object_ids (and maybe strongly > encourage to coordinate with brian so as not to trip over each others' > toes), to implement a command to convert a SHA-1 based repository to a > repository based on a different hash, to implement caching of legacy SHA-1 > <=> new hash mapping, then that would send a wholly different message. That message sent there would be "Junio thinks the SHA1 conversion is the most important thing now, so he does the work (the work a maintainer does to guide the project)". You could send the same message "Johannes thinks the SHA1 conversion is the most important thing and do the work (Johannes being a well respected contributor would send patches, and that would attract a lot of reviews for sure. -- I don't mean this snarky, please don't read any snark in this.) > And in my mind, if anybody else than Junio sent this message, it would > sound ludicrous. Yes I have seen a couple of these messages (unrelated topics). "Git should do X. Git should not do Y. k, thx bye!" and I ignored them, because these one-offs do not convince me to invest my own time in it to produce a reasonable ROI. If there are patches attached, it is not ludicrous any more as the "proof of work done" shows that the voice raised is more than just hot talk, but actual a genuine interest in moving things towards the right direction. Another big one: "Move Git away from global state all over the place". If you think about all subsystems, it may even reach the order of magnitude to the sha1 conversion, but the way the message was sent it did not seem ludicrous to me: https://public-inbox.org/git/20170530171217.GB2798@google.com/ Or the other big project "Protocol v2, that scales and serves large repos well (number of refs, large binary files omitted, refs in wants and so on)" took a different approach, and mostly discussed design (I recall emails both from Microsoft as well as Google discussing the design, most of them having RFC patches attached, such that it very much looked like "proof of work done, so it is not ludicrous") > For example, if I sent a mail to that extent, I would > find it ridiculous myself, in particular since I am a very unprolific > reviewer, and the promise to focus on favoring reviews of SHA-1 transition > related patches would sound very unsincere from somebody like me. If you were to actually follow through after such an announcement, and in fact review the sha1 conversion patches thoroughly and in a timely manner, I would think such a call up front would be well received. I thought about doing that myself, but I dread my future commitment. Specifically as my $DAY_JOBs wants me to work on submodules instead of the sha1 conversion. ("Submodules are more important than the SHA1 conversion [for me] ", if I were to trust the infinite wisdom of our management process. ) > >> As said above, Junio has strong veto power for things going off rails, >> but in his role as a maintainer he does not coordinate people. (He >> occasionally asks them to coordinate between themselves, though) > > I never had in mind that Junio would coordinate people or distribute > tasks. Coordinate is a strong word here. Most recent observed examples: https://firstname.lastname@example.org/ (My patch series conflicted with Ævars series, so we had to figure out how to fix it) https://public-inbox.org/git/20170602182215.GA57260@google.com/ (Aforementioned object id conversion series having merge conflicts) Note that this is only about coordination "You should talk to person Y so we can figure out how to make these 2 patches work well together, not about distributing tasks, as in "You must do X". > Instead, I had in mind that a certain time period could be called out as > focusing on that pretty important direction. As remarked in an earlier email, if such a thing is called out, I would very much prefer it in the next quarter, as then I can convince my manager to have more time following such a goal. Otherwise *I* would ignore it. The community at large may be different and jump on it like crazy. > That would be mostly symbolic, of course. And encouraging. In a positive > way. With a direction. So you want a project roadmap? As hinted at before the best would be to lead a good example here and show *your* roadmap such that others see how valuable of a tool it is to have a roadmap in the open. >> > 4) we still have the problem that there is no cryptography expert among >> > those who in the Git project are listened to >> >> I can assure you that Jonathan listened to crypto experts. It just did >> not happen on the mailing list, which is sad regarding openness and >> transparency. > > True. Same goes for me, of course. I just felt pretty uncomfortable > sharing the contents of my private conversation publicly, when I tried > very hard to convince my conversation partner to join the discussion on > this mailing list, and they refused. > > The gist of it was: SHA-256 should be preferred to SHA3-256 because we > will soon have good hardware support (and performance is really, really > important when you need to work on the largest Git repository on this > planet). And if there is no consensus about that, BLAKE should be > considered over other algorithms because it has been studied pretty well. BLAKE is what we're currently leaning on. (we=authors of "Git hash function transition"; Leaning in the sense: If nobody ever speaks up until all work is done, we'd just go with that. As soon as someone comes up with any reasonable argument either publicly or privately on why other hashes are better, we're easily persuaded to go with that) > Again my poor English skillz make sure I get misunderstood. So bear with > me, please, and let me try again. Same for me, if I misunderstood you please point out. tl;dr: Discussions are nice, but someone has to do the actual work, too. Thanks, Stefan
next prev parent reply other threads:[~2017-06-07 16:53 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-31 10:42 [PATCH 0/3] Add regression tests for recent rebase -i fixes Phillip Wood 2017-05-31 10:42 ` [PATCH 1/3] rebase -i: Add test for reflog message Phillip Wood 2017-06-01 2:00 ` Junio C Hamano 2017-05-31 10:42 ` [PATCH 2/3] rebase: Add tests for console output Phillip Wood 2017-05-31 19:02 ` Phillip Wood 2017-06-01 1:59 ` Junio C Hamano 2017-06-01 12:56 ` Johannes Schindelin 2017-06-01 23:40 ` Junio C Hamano 2017-06-01 23:47 ` Stefan Beller 2017-06-02 12:47 ` pushing for a new hash, was " Johannes Schindelin 2017-06-02 17:54 ` Jonathan Nieder 2017-06-02 18:05 ` Jonathan Nieder 2017-06-02 20:29 ` Ævar Arnfjörð Bjarmason 2017-06-15 10:38 ` Johannes Schindelin 2017-06-03 0:36 ` Junio C Hamano 2017-06-06 22:22 ` Johannes Schindelin 2017-06-06 22:45 ` Jonathan Nieder 2017-06-07 1:09 ` Junio C Hamano 2017-06-07 2:18 ` [PATCH] t4005: modernize style and drop hard coded sha1 Stefan Beller 2017-06-07 17:39 ` Brandon Williams 2017-06-06 22:45 ` pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output Stefan Beller 2017-06-06 22:52 ` Jonathan Nieder 2017-06-07 0:34 ` Samuel Lijin 2017-06-07 14:47 ` Johannes Schindelin 2017-06-07 16:53 ` Stefan Beller [this message] 2017-06-07 10:47 ` Phillip Wood 2017-06-09 16:39 ` Junio C Hamano 2017-06-14 10:18 ` Phillip Wood 2017-06-14 12:51 ` Johannes Schindelin 2017-05-31 10:42 ` [PATCH 3/3] rebase: Add tests for console output with conflicting stash Phillip Wood 2017-06-14 10:24 ` [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes Phillip Wood 2017-06-14 10:24 ` [PATCH v2 1/3] rebase -i: Add test for reflog message Phillip Wood 2017-06-14 10:24 ` [PATCH v2 2/3] rebase: Add regression tests for console output Phillip Wood 2017-06-14 10:24 ` [PATCH v2 3/3] rebase: Add more " Phillip Wood 2017-06-14 20:35 ` [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes Johannes Schindelin 2017-06-15 23:05 ` Junio C Hamano 2017-06-15 23:23 ` Junio C Hamano 2017-06-15 23:29 ` Junio C Hamano 2017-06-16 13:49 ` Johannes Schindelin 2017-06-16 18:43 ` Johannes Sixt 2017-06-16 21:05 ` Junio C Hamano 2017-06-19 19:45 ` Johannes Sixt 2017-06-19 20:02 ` Junio C Hamano 2017-06-19 9:49 ` Phillip Wood 2017-06-19 15:45 ` Junio C Hamano 2017-06-19 9:52 ` Phillip Wood 2017-06-19 17:56 ` [PATCH v3 0/4] Add regression tests for recent " Phillip Wood 2017-06-19 17:56 ` [PATCH v3 1/4] sequencer: print autostash messages to stderr Phillip Wood 2017-06-19 17:56 ` [PATCH v3 2/4] rebase -i: Add test for reflog message Phillip Wood 2017-06-19 17:56 ` [PATCH v3 3/4] rebase: Add regression tests for console output Phillip Wood 2017-06-19 17:56 ` [PATCH v3 4/4] rebase: Add more " Phillip Wood 2017-06-23 4:17 ` [PATCH v3 0/4] Add regression tests for recent rebase -i fixes Junio C Hamano 2017-06-23 5:07 ` Junio C Hamano 2017-06-23 9:53 ` Phillip Wood 2017-06-23 17:03 ` Junio C Hamano 2017-06-23 18:53 ` Junio C Hamano 2017-06-26 9:17 ` Phillip Wood 2017-06-23 19:01 ` Junio C Hamano 2017-06-26 9:23 ` Phillip Wood
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGZ79ka5VnfvidpsWCe5py6uW2Yp0y9gHfdZt+aZSdyfEi8Fsg@mail.gmail.com \ --email@example.com \ --cc=Johannes.Schindelin@gmx.de \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).