Contributor Summit planning

The Git Merge Contributor Summit is scheduled for this coming Wednesday, March 7th, in Barcelona.

If you're not registered, there are still one or two slots left for last-minute attendees. Please email me if you're interested.

As in past years, I plan to run it like an unconference. Attendees are expected to bring topics for group discussion. Short presentations are also welcome. We'll put the topics on a whiteboard in the morning, and pick whichever ones people are interested in.

Feel free to reply to this thread if you want to make plans or discuss any proposed topics before the summit. Input or questions from non-attendees is welcome here.

The rest of this email is all logistics for attendees, so if you're not coming, you can stop reading. :)

There should be breakfast available in the contributor summit room starting at 9am, so plan to get there around then, mingle and eat, and then we'll start in earnest at 10am.

Registration is at the main Git Merge event space (Convent dels Àngels at MACBA), and then our contributor summit space is across the street. So go to the main registration first, and then signs and clueful staff should be able to point you to the contributor summit room.

We have the space until 5pm, so we'll go until then or until we run out of stuff to say, whichever comes first. Lunch will be served in the room, and we'll probably take a few informal breaks during the day.

After we finish for the day, there are a few other events. Bitbucket is hosting drinks and discussion from 5:30-7:30pm, open to all Git Merge attendees (not just contributor summit people). Details and RSVP at:

  https://www.bevylabs.com/events/details/bevy-beers-with-bitbucket-presents-beers-with-bitbucket#/

Microsoft is sponsoring a dinner that evening at 8pm for just contributor summit attendees. Details will be provided at the summit.

I look forward to seeing everybody there!

-Peff

On Sat, Mar 03, 2018 at 05:30:10AM -0500, Jeff King wrote:

I'll plan to offer two topics:

 - a round-up of the current state and past year's activities of Git as
   a member project of Software Freedom Conservancy

 - some updates on the state of the git-scm.com since my report last
   year

As with last year, I'll try to send a written report to the list for those who aren't at the summit in person.

-Peff

On 3/3/2018 5:39 AM, Jeff King wrote:

Thanks for putting this together, Peff.

I'll be ready to talk about the serialized commit graph [1], generation numbers, and other commit-walk optimizations.

Thanks, -Stolee

[1] https://public-inbox.org/git/1519698787-190494-1-git-send-email-dstolee@microsoft.com/T/#u

On 03/03, Jeff King wrote:

Thanks for kicking things off!

Since I've been working on protocol stuff I'd like to spend a bit of time discussing protocol v2 :)

Thanks for starting this. I would like to propose the following topics:

- hooks: Discuss a proposal for multiple local Git hooks of the same type.

- error reporting: Git is distributed and therefore lots of errors are only
  reported locally. That makes it hard for administrators in larger 
  companies to see trouble. Would it make sense to add a config option that 
  would push recent errors along with "git push" to the server?

- fuzzing: Would it make sense to register Git to Google's OSS fuzzing
  program https://github.com/google/oss-fuzz ?

- Lars

Lars Schneider wrote:

Cool! Do you mind starting threads for these so people who aren't there can provide input into the discussion, too? In other words, I'm imagining

 1. Thread starts on mailing list

 2. Contributor summit: in-person presentation, discussion, etc lead to
    people having better ideas

 3. On-list thread goes really well as a result of aforementioned
    in-person discussion

Quick feedback:

I'd be happy to weigh in on a mailing list thread about this. It's also related to https://public-inbox.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/ which is an interest of mine.

I'm interested in instrumentation but worried about the privacy ramifications of this particular proposal. I'd be happy to see some built-in instrumentation hooks (or even a standard instrumentation approach, if the mailing list comes up with a good one that respects privacy).

Of course!

Alongside the obvious security benefit, there is money available to support someone working on this: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html https://www.google.com/about/appsecurity/patch-rewards/ clarifies that the reward goes to the contributor, so you don't even necessarily have to share your reward with the Git project. ;-)

Thanks, Jonathan

On Mon, Mar 05 2018, Jonathan Nieder jotted:

I have this use-case as well, and figured a good approach would be:q

 1. Add corresponding config variables for GIT_TRACE_* so you could
    config them in /etc/gitconfig (or elsewhere). Similar to
    e.g. user.name & GIT_AUTHOR_NAME

 2. Add some new trace like e.g. GIT_TRACE_COMMANDS, make it take a
    format string in GIT_TRACE_COMMANDS_FORMAT (or usually via
    config). Thus setting GIT_TRACE_COMMANDS to a file would e.g. spew
    your current repo path, subcommand, or even the absolute command
    line to the file.

 3. Have some cronjob or other monitoring thingy pick up the file &
    submit to central logging.

Of course you could overdo the format specifiers in #2 and e.g. send the full commands along, but it seems to me that it would be sufficient for privacy concerns to document that caveat with some examples.

After all, for this use-case we're talking about us somehow guarding against a sysadmin who can just install a /etc/profile.d/git_wrapper anyway that'll log everything you do with git, or even provide a custom git binary, so it's always going to be left to their best judgement.

On Mon, Mar 05 2018, Lars Schneider jotted:

I'm assuming you mean having stuff like pre-receive.d/* in addition to pre-receive:

I had a WIP series for this that I didn't end up pursuing after getting discouraged at: https://public-inbox.org/git/CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@mail.gmail.com/

There's various bolt-on solutions that do this for subsets of the hooks, e.g. GitLab now has this at https://docs.gitlab.com/ee/administration/custom_hooks.html and this stand-alone solution: https://gist.github.com/carlos-jenkins/89da9dcf9e0d528ac978311938aade43

I still think this would be great to have, but Junio's objection being:

Got me discouraged, it would have made the implementation a bit more complex, and I found other solutions to the problem I was trying to solve.

Now we use Gitlab's implementation of this which has the semantics I proposed at the time, and you just put log hooks at the beginning, but of course that's server-side only. Having this be generally usable in git would be great.

On Sat, Mar 03 2018, Jeff King jotted:

1)

Last year we discussed the general topic of performance. That's of course very general, and can touch multiple unrelated areas of git (worktree 'status' performance, all things protocol, storing big objects, graph traversal, etc.).

No doubt others will propose other topics we'd want to carve out into their own discussions (e.g. I'm expecting the v2 protocol to be one such topic), but it'll be nice to have something that brings everyone up-to-date on what the status is for purposes of coordination & collaboration.

2)

I doubt many are interested in these as topics during the contributor summit (but will propose them on the board if others care), but I have a couple of things that touch quite a lot of things that I'm going to get around to working on (or have in some WIP state):

 - PCRE-ification & PCRE convert:

   a) Use the interface recently added to PCRE to use it also for basic &
      extended POSIX regexps. This speeds things up a lot

   b) See if we can use PCRE (or at least extended regexp) consistently in
      the rest of git via single interface. Relevant code:

      git grep '\b(regcomp|regexec)\b' -- '*.[ch]'

   c) Maybe if we like a) && b) enough for performance reasons we'd be
     happy to make PCRE a hard dependency, and would then ship with a
     compat/pcre2 (~80k lines) instead of the current ancient (and hard
     to update) compat/regex/* (~10k lines).

 - Adding the ability to optionally read a .gitconfig shipped with the
   repo, see
   https://public-inbox.org/git/87zi6eakkt.fsf@evledraar.gmail.com/

On Sat, Mar 03 2018, Jeff King jotted:

I'll be arriving in BCN around 17:00 tomorrow. If someone wants to grab pre-dinner beer or dinner, preferably in the Eixample district (just across the street from the conference venue) before or at Spanish dinner time (around 21-22) add me on WhatsApp @ +31 611 763 987.

If there's more than one person interested I'll create a WhatsApp group for it so we can keep adding people. Or reply here if you prefer E-Mail, but I'm thinking subscribers to the ML who aren't there tomorrow will thank us...