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?
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
- Replace a run_command*() call by direct calls to C functions
- 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.
--
Sivaraam
