On Thu, Jan 30, 2025 at 11:14:06AM +0530, Kaartic Sivaraam wrote:

Hi Patrick and Junio,

On 22/01/25 02:05, Junio C Hamano wrote:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

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.

It would also help to document consensus in the Git project. The file
would likely not always be 100% accurate, but it'd probably be more so
compared to tracking it out of our tree.

I am OK with the general idea, with one condition.  Each item in the
list should have clear expiration date that makes it automatically
eligible to be dropped from there.  Another uncurated list of random
things is not what I want to add to and carry in my tree (the other
uncurated list of random things being the set of topic branches that
go stale without hitting 'next').

Understood. We could certainly curate it from time to time. I wonder how
we could set the timeline for a microproject idea, though. Would it make
sense to fix a rough timeline such as 1 year or so and remove any idea
whose age is more than the same?

That'd be fine with me. Ideas don't necessarily have to get removed
immediately, but may get "refreshed" in case they are still accurate.
So personally I'd frame it less like an expiration date and more like
the following:

    Every topic added to the list will need to be checked regularly for
    whether it is still accurate so that we can avoid an ever-growing
    list of stale topics. As such, every topic needs to be accompanied
    by a "best-before" date that indicates when the next check for this
    topic is due.

    It is the responsibility of the owner of the topic to determine
    whether it is still accurate. This check should happen close to the
    noted best-before date and come in the form of a patch that either
    bumps the date in case it _is_ accurate, or alternatively removes
    the topic from the list in case it is _not_ accurate anymore.

    In case the topic owner does not send such a patch, contributors
    other than the owner are encouraged to send a patch that removes the
    topic, putting the owner into Cc.

Well... maybe it _is_ an expiration date. I dunno, I don't mind which
exact term we use for it.

In any case, my proposal would be to add this paragraph or a variant
thereof to a preamble explaining the purpose of the document as well as
how to use it. This is somewhat similar to how our "BreakingChanges.txt"
lays out expectations, which I think should be an inspiration for the
new document, as well.

Also, the current list of ideas could roughly be seen here:


https://github.com/git/git.github.io/blob/2025-microprojects/SoC-2025-Microprojects.md#ideas-for-microprojects

The topics are:

  - Fix Sign Comparison Warnings in Git's Codebase

  - Modernize Test Path Checking in Git's Test Suite

  - Add more builtin patterns for userdiff

This one doesn't feel like a sensible addition to me as it is
open-ended.

  - Replace a run_command*() call by direct calls to C functions

This one, too.

  - Avoid suppressing git's exit code in test scripts

  - Use unsigned integral type for collection of bits.

  - Modernize a test script

Do share your thoughts on which of these you find being relevant
currently. That would help in preparing the first version of the in-tree
project ideas list.

All the other topics are ongoing topics indeed and would be a good fit
from my perspective.

Note that Chris is also preparing such a doc right now, so you might
want to coordinate with him.

Patrick