Re: Git in GSoC 2025

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 30, 2025, 07:32 UTC
Message-ID: <Z5srHBSPKQlsuH53@pks.im>
In-Reply-To: <b784f612-4b6b-414a-9742-86611c50c55f@gmail.com>

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

Show 27 quoted lines

> Hi Patrick and Junio,
> 
> On 22/01/25 02:05, Junio C Hamano wrote:
> > 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.
> > > 
> > > 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.

Show 12 quoted lines

> 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.

Show 9 quoted lines

>   - 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