Re: Git in GSoC 2025

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> I was wondering whether it might make sense to also move the list of
> microprojects into the Git project itself, e.g. as something like
> "Documentation/Projects.txt". This would make it easier for us to update
> the list of long-running projects whenever a new project is added and
> makes it easier for people to discover it.

I am starting to have a second thought on this.

Stepping back a bit, if we were to do this, it is very likely that
I'll let the patches (to add or update entries) sit on the mailing
list until the discussion beats the horse to death and then apply
the final version _directly_ on 'master', as such a document is
really not worth spending our usual "cook in 'next' for a week to
shake out problems" mode of operation that eats quite a lot of
braincycles out of the maintainer and to a smaller degree, other
authors that make overlapping contributions.  And this thing, being
a single document, is *DESIGNED* to force all authors to make
overlapping contributions (and an "easy to enter" contributions at
that) that will cause conflicts.

But if we are to have a single document that records a list
discussion consensus *after* the consensus is reached, it does not
really have to be _me_ the maintainer to do the record-keeper.  And
pushing as much busywork as possible out of my plate would be a good
thing to ensure that the project scales.  Even today, we have a lot
more folks who generate patches than those who can process patches
by vetting, polishing, finding problems in, making sure they play
well with other topics, etc.

I wonder if this is better managed as either a separate tree (like
the 'todo' branch that houses "What's cooking" reports among other
things) with history disjoint from the main project, or even a
separate Wiki?

Thanks.