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:
> > Patrick Steinhardt <ps@xxxxxx> 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.
> 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
