Git in GSoC 2025

Git in GSoC 2025

[Kaartic Sivaraam]

Hello everyone,

It is that time of year. GSoC Org Applications for 2025 are open now[1].
They are due before Tuesday, February 11 at 1800 UTC. It's good to see 
that few contributors have already started working on microprojects this 
year :-)

I could help as an Org Admin like previous years. I prefer not to
volunteer as a mentor this time owing to other commitments, though.

There are no noticeable changes to the program this year.

The GSoC contributor application period is March 24 - April 8, so
(co-)mentors and org admins are already welcome to volunteer. As usual,
we also need project ideas to refresh our idea page from last year
(https://git.github.io/SoC-2024-Ideas/). Feel free to share your
thoughts and discuss. It would be great if we could come up with a good 
mix of small, medium and large projects.

Do feel free to ask if there's anything that needs to be clarified.

Just like previous year, there will be a GSoC Meetup in Brussels during
FOSDEM weekend on Saturday, February 1st in the evening. If you are
around, interested and haven't received the link to register directly
from Google, let me know so I can send it to you.

[1]: 
https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html

-- 
Sivaraam

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Sun, Jan 19, 2025 at 03:43:29PM +0530, Kaartic Sivaraam wrote:
> Hello everyone,
> 
> It is that time of year. GSoC Org Applications for 2025 are open now[1].
> They are due before Tuesday, February 11 at 1800 UTC. It's good to see that
> few contributors have already started working on microprojects this year :-)
> 
> I could help as an Org Admin like previous years. I prefer not to
> volunteer as a mentor this time owing to other commitments, though.

Thanks for your work, as usual!

> There are no noticeable changes to the program this year.
> 
> The GSoC contributor application period is March 24 - April 8, so
> (co-)mentors and org admins are already welcome to volunteer. As usual,
> we also need project ideas to refresh our idea page from last year
> (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> thoughts and discuss. It would be great if we could come up with a good mix
> of small, medium and large projects.
> 
> Do feel free to ask if there's anything that needs to be clarified.
> 
> Just like previous year, there will be a GSoC Meetup in Brussels during
> FOSDEM weekend on Saturday, February 1st in the evening. If you are
> around, interested and haven't received the link to register directly
> from Google, let me know so I can send it to you.
> 
> [1]: https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html

I'd be happy to mentor this year again. A couple of ideas:

  - Consolidate ref-related functionality into git-refs(1). This would
    mean that we add new subcommands "list", "get", "exists", "write"
    and "optimize" to it so that we have a central place to manage refs
    overall. This would replace git-update-ref(1), git-for-each-ref(1)
    git-show-ref(1) as well as git-pack-ref(1), which would of course
    stay around for the foreseeable future.

  - Refactor "environment.c" such that more of its global state is
    instead stored locally, e.g. as part of `struct repository` or
    `struct repository_settings`.

  - Create a new command to query repository-level information,
    potentially making it machine-readable via for example JSON. This
    would move such information out of git-rev-parse(1), which is a
    somewhat weird home for it. It's something I have been thinking
    about quite a bit, but it wasn't ever discussed to the best of my
    knowledge. So maybe not a good fit.

I'll keep on thinking about potential topics.

Patrick

Re: Git in GSoC 2025

[shejialuo]

On Mon, Jan 20, 2025 at 08:07:53AM +0100, Patrick Steinhardt wrote:
> On Sun, Jan 19, 2025 at 03:43:29PM +0530, Kaartic Sivaraam wrote:
> > Hello everyone,
> > 
> > It is that time of year. GSoC Org Applications for 2025 are open now[1].
> > They are due before Tuesday, February 11 at 1800 UTC. It's good to see that
> > few contributors have already started working on microprojects this year :-)
> > 
> > I could help as an Org Admin like previous years. I prefer not to
> > volunteer as a mentor this time owing to other commitments, though.
> 
> Thanks for your work, as usual!
> 
> > There are no noticeable changes to the program this year.
> > 
> > The GSoC contributor application period is March 24 - April 8, so
> > (co-)mentors and org admins are already welcome to volunteer. As usual,
> > we also need project ideas to refresh our idea page from last year
> > (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> > thoughts and discuss. It would be great if we could come up with a good mix
> > of small, medium and large projects.
> > 
> > Do feel free to ask if there's anything that needs to be clarified.
> > 
> > Just like previous year, there will be a GSoC Meetup in Brussels during
> > FOSDEM weekend on Saturday, February 1st in the evening. If you are
> > around, interested and haven't received the link to register directly
> > from Google, let me know so I can send it to you.
> > 
> > [1]: https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html
> 
> I'd be happy to mentor this year again. A couple of ideas:
> 
>   - Consolidate ref-related functionality into git-refs(1). This would
>     mean that we add new subcommands "list", "get", "exists", "write"
>     and "optimize" to it so that we have a central place to manage refs
>     overall. This would replace git-update-ref(1), git-for-each-ref(1)
>     git-show-ref(1) as well as git-pack-ref(1), which would of course
>     stay around for the foreseeable future.
> 
>   - Refactor "environment.c" such that more of its global state is
>     instead stored locally, e.g. as part of `struct repository` or
>     `struct repository_settings`.

I think this is a good project which is not too difficult for a student
to finish. By refactoring "environment.c", we could slowly drop the
global variable "the_repository". I'd like to co-mentor with this idea
if possible.

Thanks,
Jialuo

Re: Git in GSoC 2025

[Oswald Buddenhagen]

On Mon, Jan 20, 2025 at 08:07:53AM +0100, Patrick Steinhardt wrote:
>  - Create a new command to query repository-level information,

>    potentially making it machine-readable via for example JSON.
>
only optionally, please. the current positional output (each line
corresponds to the respective query command) is much easier to deal with
in shell scripts.

>    This
>    would move such information out of git-rev-parse(1), which is a
>    somewhat weird home for it. It's something I have been thinking
>    about quite a bit,

> but it wasn't ever discussed to the best of my knowledge.
>
that depends on what level of engagement counts as "discussed".
https://lore.kernel.org/git/ZZbFGTkM8aR7MXQu@tanuki/

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Mon, Jan 27, 2025 at 12:19:26PM +0530, Kaartic Sivaraam wrote:
> Hi Patrick, Christian, Karthik and Jialuo,
> 
> Thank you very much for your interest in volunteering as a mentor!
> 
> On Mon, Jan 20, 2025 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:
> 
> > I'd be happy to mentor this year again. A couple of ideas:
> >
> >
> Thank you for suggesting these ideas, Patrick! I've incorporated them into
> a draft
> ideas page for now. You can see them here:
> 
> https://git.github.io/SoC-2025-Ideas/

Great, thanks a lot!

> Kindly suggest any corrections to the description, project size /
> difficulty as necessary.
> I've mentioned potential mentors based on what I'm aware of so far.
> 
> Patrick, Christian and Karthik, kindly mention the ideas that you're
> interested to
> mentor.
> 
> While I have not included them as of yet, I wonder if the following ideas
> which we
> had last year[1] could still be retained this year:
> 
> - Implement consistency checks for refs. The idea could be about
>    implementing further ref checks which Jialuo appears to be helping
>    out with. We could leave it if Jialuo prefers to continue working on
>    the same in a flow.

The biggest omission right now is the reftable backend, but that one I
plan to work on myself in this release cycle.

I'll leave it to Jialuo to decide whether there's anything else in this
context that would make for a good GSoC project, as he's been the
primary driving force here.

> - Refactor git-bisect(1) to make its state self-contained

I'd rather remove that project. It would be nice to have it, but it
feels too risky for a GSoC project, and we have better ones.

> - Implement support for reftables in "dumb" HTTP transport

I'd be fine mentoring this project.

Patrick

Re: Git in GSoC 2025

[shejialuo]

On Mon, Jan 27, 2025 at 09:06:36AM +0100, Patrick Steinhardt wrote:
> On Mon, Jan 27, 2025 at 12:19:26PM +0530, Kaartic Sivaraam wrote:
> > Hi Patrick, Christian, Karthik and Jialuo,
> > 
> > Thank you very much for your interest in volunteering as a mentor!
> > 
> > On Mon, Jan 20, 2025 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:
> > 
> > > I'd be happy to mentor this year again. A couple of ideas:
> > >
> > >
> > Thank you for suggesting these ideas, Patrick! I've incorporated them into
> > a draft
> > ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> 
> Great, thanks a lot!
> 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary.
> > I've mentioned potential mentors based on what I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to
> > mentor.
> > 
> > While I have not included them as of yet, I wonder if the following ideas
> > which we
> > had last year[1] could still be retained this year:
> > 
> > - Implement consistency checks for refs. The idea could be about
> >    implementing further ref checks which Jialuo appears to be helping
> >    out with. We could leave it if Jialuo prefers to continue working on
> >    the same in a flow.
> 
> The biggest omission right now is the reftable backend, but that one I
> plan to work on myself in this release cycle.
> 

I am happy to see this. If you plan to work on this in this release
cycle. I won't touch this. I'll review to learn more knowledge about
reftable backend.

> I'll leave it to Jialuo to decide whether there's anything else in this
> context that would make for a good GSoC project, as he's been the
> primary driving force here.
> 

One thing I could think about is to clean up "git-fsck(1)" to make the
boundary between the ref checks and object checks clear which means we
need to remove unnecessary checks and reorder the program sequence.
However, I think this is a little risky for a GSoC project. So, I'd like
to implement this later on my own.

Thanks,
Jialuo

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Patrick and Jialuo,

On 27/01/25 13:36, Patrick Steinhardt wrote:
> On Mon, Jan 27, 2025 at 12:19:26PM +0530, Kaartic Sivaraam wrote:
>> While I have not included them as of yet, I wonder if the following ideas
>> which we
>> had last year[1] could still be retained this year:
>>
>> - Implement consistency checks for refs. The idea could be about
>>     implementing further ref checks which Jialuo appears to be helping
>>     out with. We could leave it if Jialuo prefers to continue working on
>>     the same in a flow.
> 
> The biggest omission right now is the reftable backend, but that one I
> plan to work on myself in this release cycle.
> 
> I'll leave it to Jialuo to decide whether there's anything else in this
> context that would make for a good GSoC project, as he's been the
> primary driving force here.
>

Got it.

>> - Refactor git-bisect(1) to make its state self-contained
> 
> I'd rather remove that project. It would be nice to have it, but it
> feels too risky for a GSoC project, and we have better ones.
> 

Ok. I'll leave it dropped.

>> - Implement support for reftables in "dumb" HTTP transport
> 
> I'd be fine mentoring this project.
> 

Sure. I'll include this one. I've retained Karthik as a co-mentor. 
Karthik, let me know in case of any concerns.


On 27/01/25 18:13, shejialuo wrote:
 > One thing I could think about is to clean up "git-fsck(1)" to make the
 > boundary between the ref checks and object checks clear which means we
 > need to remove unnecessary checks and reorder the program sequence.
 > However, I think this is a little risky for a GSoC project. So, I'd like
 > to implement this later on my own.

Done. Thank you for your thoughts!

--
Sivaraam

Re: Git in GSoC 2025

[Kaartic Sivaraam]

(Apologies for the delayed re-send. I just noticed that this one
  got dropped by the mailing list. I'll respond to existing replies
  in that thread)

Hi Patrick, Christian, Karthik and Jialuo,

Thank you very much for your interest in volunteering as a mentor!

On Mon, Jan 20, 2025 at 12:37 PM Patrick Steinhardt <ps@pks.im> wrote:

 > I'd be happy to mentor this year again. A couple of ideas:


Thank you for suggesting these ideas, Patrick! I've incorporated them 
into a draft ideas page for now. You can see them here:

https://git.github.io/SoC-2025-Ideas/

Kindly suggest any corrections to the description, project size /
difficulty as necessary. I've mentioned potential mentors based on what
I'm aware of so far.

Patrick, Christian and Karthik, kindly mention the ideas that you're
interested to mentor.

While I have not included them as of yet, I wonder if the following
ideas which we had last year[1] could still be retained this year:

- Implement consistency checks for refs. The idea could be about
   implementing further ref checks which Jialuo appears to be helping
   out with. We could leave it if Jialuo prefers to continue working on
   the same in a flow.

- Refactor git-bisect(1) to make its state self-contained

- Implement support for reftables in "dumb" HTTP transport

Would these be interesting ones to consider? Is anyone willing to
mentor these this time around?


 > I'll keep on thinking about potential topics.


Sure. That would be great! Others could also chime in with your
potential ideas. Also, do not hesitate to let us know if you're
interested in mentoring.

-- 
Sivaraam

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hello Christian, Karthik, Jialuo, Patrick and all,

On 28/01/25 23:00, Kaartic Sivaraam wrote:
> 
> Thank you for suggesting these ideas, Patrick! I've incorporated them 
> into a draft ideas page for now. You can see them here:
> 
> https://git.github.io/SoC-2025-Ideas/
> 
> Kindly suggest any corrections to the description, project size /
> difficulty as necessary. I've mentioned potential mentors based on what
> I'm aware of so far.
> 
> Patrick, Christian and Karthik, kindly mention the ideas that you're
> interested to mentor.
> 

Gentle reminder that the ideas list needs completion. Specifically, the
following ideas only list Patrick as a potential mentor:

   - Refactoring in order to reduce Git’s global state

   - Machine-Readable Repository Information Query Tool

The following idea mentions Karthik and Patrick as potential
mentors.

   - Implement support for reftables in “dumb” HTTP transport

The following idea mentions Jialuo and Patrick as potential
mentors.

   - Consolidate ref-related functionality into git-refs

It would helpful if you all could chime in to let me know if the
existing allocation is fine and to what other projects you need
to be mentioned as potential mentors.

--
Sivaraam

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Sun, Feb 02, 2025 at 05:22:05PM +0530, Kaartic Sivaraam wrote:
> Hello Christian, Karthik, Jialuo, Patrick and all,
> 
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
> > 
> > Thank you for suggesting these ideas, Patrick! I've incorporated them
> > into a draft ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> > 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary. I've mentioned potential mentors based on what
> > I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to mentor.
> > 
> 
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:

Thanks for the reminder!

>   - Refactoring in order to reduce Git’s global state
> 
>   - Machine-Readable Repository Information Query Tool

I'll definitely need a co-mentor as I'll be out of office for two weeks
in May. Otherwise we'll have to drop these two projects if nobody else
wants to mentor them with me.

> The following idea mentions Karthik and Patrick as potential
> mentors.
> 
>   - Implement support for reftables in “dumb” HTTP transport
> 
> The following idea mentions Jialuo and Patrick as potential
> mentors.
> 
>   - Consolidate ref-related functionality into git-refs

Overall it would also be nice if I wasn't mentoring in all projects :)
I'm fine with being mentor in one project and co-mentor in another, but
don't think that I'll have the capacity to do more than that.

Patrick

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hello Christian, Karthik, Jialuo, Patrick and all,
>
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
>>
>> Thank you for suggesting these ideas, Patrick! I've incorporated them
>> into a draft ideas page for now. You can see them here:
>>
>> https://git.github.io/SoC-2025-Ideas/
>>
>> Kindly suggest any corrections to the description, project size /
>> difficulty as necessary. I've mentioned potential mentors based on what
>> I'm aware of so far.
>>
>> Patrick, Christian and Karthik, kindly mention the ideas that you're
>> interested to mentor.
>>
>
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:
>

Sorry for the delay here, was OOO for a bit. Thanks for following up :)

>    - Refactoring in order to reduce Git’s global state
>

I've worked a bit on this and would be happy to mentor or co-mentor
here.

>    - Machine-Readable Repository Information Query Tool
>

Here too, I'm happy to co-mentor or mentor here.

So I could co-mentor one of these with Patrick, as I can cover when he's
OOO.

> The following idea mentions Karthik and Patrick as potential
> mentors.
>
>    - Implement support for reftables in “dumb” HTTP transport
>

I don't have a bunch of knowledge here, so I could co-mentor but not
mentor by myself.

> The following idea mentions Jialuo and Patrick as potential
> mentors.
>
>    - Consolidate ref-related functionality into git-refs
>
> It would helpful if you all could chime in to let me know if the
> existing allocation is fine and to what other projects you need
> to be mentioned as potential mentors.
>
> --
> Sivaraam

Overall, I should be able to cover a maximum of 2 projects (with at
least one as a co-mentor).

Thanks for putting this together.

Karthik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: Git in GSoC 2025

[shejialuo]

On Sun, Feb 02, 2025 at 05:22:05PM +0530, Kaartic Sivaraam wrote:
> Hello Christian, Karthik, Jialuo, Patrick and all,
> 
> On 28/01/25 23:00, Kaartic Sivaraam wrote:
> > 
> > Thank you for suggesting these ideas, Patrick! I've incorporated them
> > into a draft ideas page for now. You can see them here:
> > 
> > https://git.github.io/SoC-2025-Ideas/
> > 
> > Kindly suggest any corrections to the description, project size /
> > difficulty as necessary. I've mentioned potential mentors based on what
> > I'm aware of so far.
> > 
> > Patrick, Christian and Karthik, kindly mention the ideas that you're
> > interested to mentor.
> > 
> 
> Gentle reminder that the ideas list needs completion. Specifically, the
> following ideas only list Patrick as a potential mentor:
> 

Thanks for the reminder.

>   - Refactoring in order to reduce Git’s global state
> 

Although I never code for this, I have reviewed a lot of patches others
work on. So, I think I could co-mentor this.

>   - Machine-Readable Repository Information Query Tool
> 
> The following idea mentions Karthik and Patrick as potential
> mentors.
> 
>   - Implement support for reftables in “dumb” HTTP transport
> 
> The following idea mentions Jialuo and Patrick as potential
> mentors.
> 
>   - Consolidate ref-related functionality into git-refs
> 

I am OK wth this.

> It would helpful if you all could chime in to let me know if the
> existing allocation is fine and to what other projects you need
> to be mentioned as potential mentors.
> 

In conclusion, I could cover two projects as a co-mentor.

Thanks,
Jialuo

> --
> Sivaraam

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Patrick, Karthik, Jialuo and all,

On 02/02/25 17:22, Kaartic Sivaraam wrote:
> 
> Gentle reminder that the ideas list needs completion. 

Thank you for your responses! The updated assignment is as
follows:

- Consolidate ref-related functionality into git-refs

   Possible mentors:
   * Patrick Steinhardt
   * Jialuo She

- Refactoring in order to reduce Git's global state

   Possible mentors:
   * Patrick Steinhardt
   * Karthik Nayak
   * Jialuo She

- Machine-Readable Repository Information Query Tool

   Possible mentors:
   * Patrick Steinhardt
   * Karthik Nayak

- Implement support for reftables in "dumb" HTTP transport

   Possible mentors:
   * Patrick Steinhardt
   * Karthik Nayak

Note that I haven't assigned any mentors / co-mentors for each project. 
I suppose we could assign that based on the applications we receive and 
the ideas that we end up selecting.

Based on Christian's inputs, we should be able to distribute
projects among mentors well.

--
Sivaraam

Re: Git in GSoC 2025

[Christian Couder]

Hi Kaartic and all,

On Tue, Feb 4, 2025 at 7:33 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:

> - Consolidate ref-related functionality into git-refs
>
>    Possible mentors:
>    * Patrick Steinhardt
>    * Jialuo She

I have just added myself as a possible mentor. If possible I'd like to
just co-mentor this project and someone else to be the main mentor for
this project.

> - Refactoring in order to reduce Git's global state
>
>    Possible mentors:
>    * Patrick Steinhardt
>    * Karthik Nayak
>    * Jialuo She

I have just added myself as a possible mentor. If possible I'd like to
be the main mentor for this project.

> Note that I haven't assigned any mentors / co-mentors for each project.
> I suppose we could assign that based on the applications we receive and
> the ideas that we end up selecting.
>
> Based on Christian's inputs, we should be able to distribute
> projects among mentors well.

Yeah, I hope it will be possible to distribute projects among mentors well.

Thanks for working on this!

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Christian, Karthik, Patrick, Jialuo and all,

On 05/02/25 18:50, Christian Couder wrote:
> Hi Kaartic and all,
> 
> On Tue, Feb 4, 2025 at 7:33 PM Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
> 
> I have just added myself as a possible mentor. If possible I'd like to
> just co-mentor this project and someone else to be the main mentor for
> this project.
> 
 > ...
> 
> I have just added myself as a possible mentor. If possible I'd like to
> be the main mentor for this project.
> 

Thank you for adding yourself as a potential mentor!

With this, it seems to me like we could at the max. accept 3 students

>> Note that I haven't assigned any mentors / co-mentors for each project.
>> I suppose we could assign that based on the applications we receive and
>> the ideas that we end up selecting.
>>
>> Based on Christian's inputs, we should be able to distribute
>> projects among mentors well.
> 
> Yeah, I hope it will be possible to distribute projects among mentors well.
>

Indeed. From all of your inputs I was able to come to the following
allocation of mentor / co-mentor.

-- 8< --

Consolidate ref-related functionality into git-refs

- Mentor: Patrick
- Co-mentor: Jialuo / Christian

Refactoring in order to reduce Git’s global state

- Mentor: Christian
- Co-mentor: Karthik / Jialuo

Machine-Readable Repository Information Query Tool

- Mentor: Karthik
- Co-mentor: Patrick

Implement support for reftables in “dumb” HTTP transport

- Mentor: Patrick
- Co-mentor: Karthik

-- >8 --

Let me know if this sounds fine to all of you. So, I suppose we could
pick a maximum of 3 projects but we cannot pick both "Consolidate
ref-related functionality into git-refs" and "Implement support
for reftables in “dumb” HTTP transport" at the same time as Patrick
only prefers to be mentor in one project.

Based on this, I'll tweak the ideas page to mention that we could
pick a max of 3 candidates.


BTW, I've just submitted Git's application for GSoC. We should know
by February 26 about the selection result.

--
Sivaraam

Re: Git in GSoC 2025

[Christian Couder]

Hi Kaartic,

On Fri, Feb 7, 2025 at 8:32 AM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:

> -- 8< --
>
> Consolidate ref-related functionality into git-refs
>
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
>
> Refactoring in order to reduce Git’s global state
>
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
>
> Machine-Readable Repository Information Query Tool
>
> - Mentor: Karthik
> - Co-mentor: Patrick
>
> Implement support for reftables in “dumb” HTTP transport
>
> - Mentor: Patrick
> - Co-mentor: Karthik
>
> -- >8 --
>
> Let me know if this sounds fine to all of you.

Fine for me. Thanks!

> So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.

Yeah, but we have time to decide on this. It seems to me that we can
still come up with new project ideas and possibly new mentors or
co-mentors until it's time for applicants to send their.application.

> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.

Thanks!

> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.

Thanks again!

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Fri, Feb 07, 2025 at 01:02:25PM +0530, Kaartic Sivaraam wrote:
> Consolidate ref-related functionality into git-refs
> 
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
> 
> Refactoring in order to reduce Git’s global state
> 
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
> 
> Machine-Readable Repository Information Query Tool
> 
> - Mentor: Karthik
> - Co-mentor: Patrick
> 
> Implement support for reftables in “dumb” HTTP transport
> 
> - Mentor: Patrick
> - Co-mentor: Karthik
> 
> -- >8 --
> 
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.

This all looks fine to me.

One thought: From my point of view I'd strongly favor extending
git-refs(1) over reftable support in the dumb HTTP transport. So if I
had two applications, one for each topic, I'd lean towards applications
for the former topic. That might easily cause unfairness in case
students aren't aware of that.

So unless somebody else wants to be main-mentor in that project, I think
we should either drop the HTTP transport tropic, or communicate our
priorities clearly.

> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
> 
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.

Great! Thanks again for handling all of this.

Patrick

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Patrick, Christian and all,

On 07/02/25 16:25, Patrick Steinhardt wrote:
> One thought: From my point of view I'd strongly favor extending
> git-refs(1) over reftable support in the dumb HTTP transport. So if I
> had two applications, one for each topic, I'd lean towards applications
> for the former topic. That might easily cause unfairness in case
> students aren't aware of that.
> 
> So unless somebody else wants to be main-mentor in that project, I think
> we should either drop the HTTP transport tropic, or communicate our
> priorities clearly.

That makes sense. I've added a note to convey this clearly. Kindly check 
if the change in the following PR looks fine.

   https://github.com/git/git.github.io/pull/750/files


On 07/02/25 13:37, Christian Couder wrote:
 > Yeah, but we have time to decide on this. It seems to me that we can
 > still come up with new project ideas and possibly new mentors or
 > co-mentors until it's time for applicants to send their.application.

Indeed. More volunteer mentors and ideas are always welcome :-)

--
Sivaraam

Re: Git in GSoC 2025

[Ghanshyam Thakkar]

On Tue Feb 11, 2025 at 10:48 AM IST, Kaartic Sivaraam wrote:
> Hi Patrick, Christian and all,
>
> On 07/02/25 16:25, Patrick Steinhardt wrote:
> > One thought: From my point of view I'd strongly favor extending
> > git-refs(1) over reftable support in the dumb HTTP transport. So if I
> > had two applications, one for each topic, I'd lean towards applications
> > for the former topic. That might easily cause unfairness in case
> > students aren't aware of that.
> > 
> > So unless somebody else wants to be main-mentor in that project, I think
> > we should either drop the HTTP transport tropic, or communicate our
> > priorities clearly.
>
> That makes sense. I've added a note to convey this clearly. Kindly check 
> if the change in the following PR looks fine.
>
>    https://github.com/git/git.github.io/pull/750/files
>
>
> On 07/02/25 13:37, Christian Couder wrote:
>  > Yeah, but we have time to decide on this. It seems to me that we can
>  > still come up with new project ideas and possibly new mentors or
>  > co-mentors until it's time for applicants to send their.application.
>
> Indeed. More volunteer mentors and ideas are always welcome :-)

Hi,

I can co-mentor this summer. The 'Machine-Readable Repository Information
Query Tool' project seems interesting to me, although I'm up for co-mentoring
in other projects as well. Let me know if you need any help with
anything else.

Thanks.

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Ghanshyam,

On 16/02/25 18:26, Ghanshyam Thakkar wrote:
> 
> I can co-mentor this summer. The 'Machine-Readable Repository Information
> Query Tool' project seems interesting to me, although I'm up for co-mentoring
> in other projects as well. Let me know if you need any help with
> anything else.
>

That's great to hear! Thank you for volunteering. I've added you as
a potential co-mentor for the project that you've mentioned. We
could discuss about the allocation to other projects based on the
applications that we receive. Feel free to let me know if there are
specific projects you wish to co-mentor in.

Also, feel free to share if you have any other ideas that we could have
for this GSoC.

--
Sivaraam

Re: Git in GSoC 2025

[Junio C Hamano]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
>> I can co-mentor this summer. The 'Machine-Readable Repository
>> Information
>> Query Tool' project seems interesting to me, although I'm up for co-mentoring
>> in other projects as well. Let me know if you need any help with
>> anything else.
>>
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.
>
> Also, feel free to share if you have any other ideas that we could have
> for this GSoC.

It is great to see that old timers who have been dormant for a
while, as well as newcomers who have been around for less than a
year, to be running and volunteering these mentoring programs.

Please keep the community thriving with more of both old and new
blood.

Thanks.

Re: Git in GSoC 2025

[Ghanshyam Thakkar]

On Sun Feb 16, 2025 at 7:23 PM IST, Kaartic Sivaraam wrote:
> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
> > 
> > I can co-mentor this summer. The 'Machine-Readable Repository Information
> > Query Tool' project seems interesting to me, although I'm up for co-mentoring
> > in other projects as well. Let me know if you need any help with
> > anything else.
> >
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.

Sure, I can co-mentor either of the "Consolidate ref-related functionality
into git-refs" or "Refactoring in order to reduce Git’s global state"
projects as well, if needed.

> Also, feel free to share if you have any other ideas that we could have
> for this GSoC.

Sure thing!

Thanks.

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hi Ghanshyam,
>
> On 16/02/25 18:26, Ghanshyam Thakkar wrote:
>>
>> I can co-mentor this summer. The 'Machine-Readable Repository Information
>> Query Tool' project seems interesting to me, although I'm up for co-mentoring
>> in other projects as well. Let me know if you need any help with
>> anything else.
>>
>
> That's great to hear! Thank you for volunteering. I've added you as
> a potential co-mentor for the project that you've mentioned. We
> could discuss about the allocation to other projects based on the
> applications that we receive. Feel free to let me know if there are
> specific projects you wish to co-mentor in.
>
> Also, feel free to share if you have any other ideas that we could have
> for this GSoC.
>

I wonder if with Ghanshyam also mentoring, if this statement still
holds true

  Note about limit of project selection

  Kindly note that considering the bandwidth of available mentors, the
  Git project would only mentor up to 3 contributors this year.

Maybe we can do 4 projects this year?

> --
> Sivaraam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Karthik,

Sorry for the delayed response! I kind of missed to respond unintentionally.

On 07/03/25 15:31, Karthik Nayak wrote:
> 
> I wonder if with Ghanshyam also mentoring, if this statement still
> holds true
> 
>    Note about limit of project selection
> 
>    Kindly note that considering the bandwidth of available mentors, the
>    Git project would only mentor up to 3 contributors this year.
> 
> Maybe we can do 4 projects this year?
> 

While we do have 5 volunteers for mentoring students this year, we only 
have 3 candidates who could play the role of the primary mentor. 
Ghanshyam and Jialuo only prefer to co-mentor as far as I could 
understand. So, that still gives us a limit of 3 projects doesn't it?

Kindly correct me in case I'm missing anything.

--
Sivaraam

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hi Karthik,
>
> Sorry for the delayed response! I kind of missed to respond unintentionally.
>
> On 07/03/25 15:31, Karthik Nayak wrote:
>>
>> I wonder if with Ghanshyam also mentoring, if this statement still
>> holds true
>>
>>    Note about limit of project selection
>>
>>    Kindly note that considering the bandwidth of available mentors, the
>>    Git project would only mentor up to 3 contributors this year.
>>
>> Maybe we can do 4 projects this year?
>>
>
> While we do have 5 volunteers for mentoring students this year, we only
> have 3 candidates who could play the role of the primary mentor.
> Ghanshyam and Jialuo only prefer to co-mentor as far as I could
> understand. So, that still gives us a limit of 3 projects doesn't it?
>
> Kindly correct me in case I'm missing anything.
>

You're right, I didn't think of that :)

> --
> Sivaraam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: Git in GSoC 2025

[shejialuo]

On Fri, Feb 07, 2025 at 01:02:25PM +0530, Kaartic Sivaraam wrote:
> 
> Indeed. From all of your inputs I was able to come to the following
> allocation of mentor / co-mentor.
> 
> -- 8< --
> 
> Consolidate ref-related functionality into git-refs
> 
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
> 
> Refactoring in order to reduce Git’s global state
> 
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
> 
> Machine-Readable Repository Information Query Tool
> 
> - Mentor: Karthik
> - Co-mentor: Patrick
> 
> Implement support for reftables in “dumb” HTTP transport
> 
> - Mentor: Patrick
> - Co-mentor: Karthik
> 
> -- >8 --
> 
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.
> 

I am OK with this.

> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
> 
> 
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.
> 

Thanks for working on this.

> --
> Sivaraam

Jialuo

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hi Christian, Karthik, Patrick, Jialuo and all,
>
> On 05/02/25 18:50, Christian Couder wrote:
>> Hi Kaartic and all,
>>
>> On Tue, Feb 4, 2025 at 7:33 PM Kaartic Sivaraam
>> <kaartic.sivaraam@gmail.com> wrote:
>>
>> I have just added myself as a possible mentor. If possible I'd like to
>> just co-mentor this project and someone else to be the main mentor for
>> this project.
>>
>  > ...
>>
>> I have just added myself as a possible mentor. If possible I'd like to
>> be the main mentor for this project.
>>
>
> Thank you for adding yourself as a potential mentor!
>
> With this, it seems to me like we could at the max. accept 3 students
>
>>> Note that I haven't assigned any mentors / co-mentors for each project.
>>> I suppose we could assign that based on the applications we receive and
>>> the ideas that we end up selecting.
>>>
>>> Based on Christian's inputs, we should be able to distribute
>>> projects among mentors well.
>>
>> Yeah, I hope it will be possible to distribute projects among mentors well.
>>
>
> Indeed. From all of your inputs I was able to come to the following
> allocation of mentor / co-mentor.
>
> -- 8< --
>
> Consolidate ref-related functionality into git-refs
>
> - Mentor: Patrick
> - Co-mentor: Jialuo / Christian
>
> Refactoring in order to reduce Git’s global state
>
> - Mentor: Christian
> - Co-mentor: Karthik / Jialuo
>
> Machine-Readable Repository Information Query Tool
>
> - Mentor: Karthik
> - Co-mentor: Patrick
>
> Implement support for reftables in “dumb” HTTP transport
>
> - Mentor: Patrick
> - Co-mentor: Karthik
>
> -- >8 --
>
> Let me know if this sounds fine to all of you. So, I suppose we could
> pick a maximum of 3 projects but we cannot pick both "Consolidate
> ref-related functionality into git-refs" and "Implement support
> for reftables in “dumb” HTTP transport" at the same time as Patrick
> only prefers to be mentor in one project.
>

This looks great to me, thanks for putting it together. Once the
applications start coming in, we can finalize on which combination works
out for us.

>
> Based on this, I'll tweak the ideas page to mention that we could
> pick a max of 3 candidates.
>
>
> BTW, I've just submitted Git's application for GSoC. We should know
> by February 26 about the selection result.
>

Again, thanks for all the work here!

> --
> Sivaraam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: Git in GSoC 2025

[Christian Couder]

Hi,

On Sun, Jan 19, 2025 at 11:13 AM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
>
> Hello everyone,
>
> It is that time of year. GSoC Org Applications for 2025 are open now[1].
> They are due before Tuesday, February 11 at 1800 UTC. It's good to see
> that few contributors have already started working on microprojects this
> year :-)
>
> I could help as an Org Admin like previous years. I prefer not to
> volunteer as a mentor this time owing to other commitments, though.

Thanks for volunteering as an Org Admin and for this message!

> There are no noticeable changes to the program this year.
>
> The GSoC contributor application period is March 24 - April 8, so
> (co-)mentors and org admins are already welcome to volunteer.

I am happy to mentor and to be Org Admin this year again.

> As usual,
> we also need project ideas to refresh our idea page from last year
> (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> thoughts and discuss. It would be great if we could come up with a good
> mix of small, medium and large projects.

It might be nice if we could refresh our microproject idea list too.
Maybe we could add ideas related to removing the_repository or
compiling with -Wsign-compare?

> Do feel free to ask if there's anything that needs to be clarified.
>
> Just like previous year, there will be a GSoC Meetup in Brussels during
> FOSDEM weekend on Saturday, February 1st in the evening. If you are
> around, interested and haven't received the link to register directly
> from Google, let me know so I can send it to you.

Yeah, there might also be a GSoC Meetup in Madrid, Spain on Wednesday,
January 29th. People interested should let us know so we can send them
a link to an interest form they would have to complete.

Best,
Christian.

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Mon, Jan 20, 2025 at 09:19:53AM +0100, Christian Couder wrote:
> > As usual,
> > we also need project ideas to refresh our idea page from last year
> > (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> > thoughts and discuss. It would be great if we could come up with a good
> > mix of small, medium and large projects.
> 
> It might be nice if we could refresh our microproject idea list too.
> Maybe we could add ideas related to removing the_repository or
> compiling with -Wsign-compare?

Yes, agreed, both of these projects make sense to me.

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.

Patrick

Re: Git in GSoC 2025

[Junio C Hamano]

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

Thanks.

Re: Git in GSoC 2025

[Kaartic Sivaraam]

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?

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

Re: Git in GSoC 2025

[Patrick Steinhardt]

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

> 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

Re: Git in GSoC 2025

[Christian Couder]

On Thu, Jan 30, 2025 at 8:32 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Thu, Jan 30, 2025 at 11:14:06AM +0530, Kaartic Sivaraam wrote:

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

Thanks for this. I will use something similar.

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

I don't mind much either.

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

Sure.

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

We could put those two in a section for projects that are a bit larger
than microprojects though. It might help those who have already worked
on a microproject and want to do something a bit more involved.

It happens more and more often that people who want to apply to the
GSoC or Outreachy start getting involved early, which is nice. They
often have time, after their microproject and before working on their
application, to work on something a bit more involved. So it would be
nice if they could easily find something else to work on like those
two ideas and others similar to them.

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

I agree.

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

Yeah, I need to prepare a draft for the next Git Rev News edition
first, but I will work on this really soon after.

Thanks.

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Thu, Jan 30, 2025 at 09:37:47AM +0100, Christian Couder wrote:
> On Thu, Jan 30, 2025 at 8:32 AM Patrick Steinhardt <ps@pks.im> wrote:
> > 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.
> 
> We could put those two in a section for projects that are a bit larger
> than microprojects though. It might help those who have already worked
> on a microproject and want to do something a bit more involved.
> 
> It happens more and more often that people who want to apply to the
> GSoC or Outreachy start getting involved early, which is nice. They
> often have time, after their microproject and before working on their
> application, to work on something a bit more involved. So it would be
> nice if they could easily find something else to work on like those
> two ideas and others similar to them.

The issue I have with these is less about the project size, but more
about them not being clearly defined. There is no easy way to identify
sites that can be adapted, and neither is there a common understanding
in the project that this is even something we want to do. So personally
I'd leave them out of a first iteration so that we only have a set of
"trivial" projects that are commonly accepted, which allows us to focus
on the form of the new document instead of bikeshedding the proposed
projects.

Which doesn't mean that we shouldn't discuss adding these projects at
all. But I'd rather think that should be left for another iteration so
that we can discuss their scope and merit more in depth.

Patrick

Re: Git in GSoC 2025

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

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

I do not mind either word, either, but I have two small issues to
raise:

 - Is each topic "owned" by some specific person?  Would an owner
   retires from the project, would the leftover bits go away with
   the owner?

 - "relevant" may be a more appropriate adjective than "accurate".
   An item in the list may still accurately expresses somebody's
   wish, but because a better alternative has been implemented in
   the meantime, the feature-wish may no longer relevant.

>>   - Fix Sign Comparison Warnings in Git's Codebase

This one I am not sure if it is even something we want more of; a
careless "-Wsign-compare" squelching often makes the resulting code
worse.

>>   - Add more builtin patterns for userdiff
>
> This one doesn't feel like a sensible addition to me as it is
> open-ended.

If you add a list of missing types of documents and curate that
list, then it can evolve over time.  Cobol may be on that list
forever, while other minor languages may come and go.

>>   - Replace a run_command*() call by direct calls to C functions
>
> This one, too.

This one, too.

Re: Git in GSoC 2025

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I do not mind either word, either, but I have two small issues to
> raise:
>
>  - Is each topic "owned" by some specific person?  Would an owner
>    retires from the project, would the leftover bits go away with
>    the owner?

I obviously meant "When an owner retires", but more importantly, I
should have offered an alternative here, instead of just raising it
as an issue.

How about making the rule a lot simpler?

    The expiration date kicks in _mechanically_, i.e. stale entries
    are unconditionally dropped at the date, based solely on the
    comparison between the timestamp and the wall clock.

People are free to advocate for its continued existence, and when
such an effort achieves a concensus among then-active members of the
community by the stated expiration date, a patch to update the
entry's expiration date may be accepted, thereby prolonging its
shelf life.  Unless such a thing happens before the expiration date
comes, we will mechanically drop the entry.

Of course people _can_ resurrect an expired entry later as a new
one when it seems appropriate.

That makes the decision to expire things from the list easy to make.

This is a tangent, perhaps we should adopt the same "drop
mechanically purely based on timestamp, but allow resuscitation"
rule for topic branches that take forever to hit 'next'.  It would
make my life a little bit simpler ;-).

Thanks.

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Thu, Jan 30, 2025 at 01:00:27PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I do not mind either word, either, but I have two small issues to
> > raise:
> >
> >  - Is each topic "owned" by some specific person?  Would an owner
> >    retires from the project, would the leftover bits go away with
> >    the owner?
> 
> I obviously meant "When an owner retires", but more importantly, I
> should have offered an alternative here, instead of just raising it
> as an issue.
> 
> How about making the rule a lot simpler?
> 
>     The expiration date kicks in _mechanically_, i.e. stale entries
>     are unconditionally dropped at the date, based solely on the
>     comparison between the timestamp and the wall clock.
> 
> People are free to advocate for its continued existence, and when
> such an effort achieves a concensus among then-active members of the
> community by the stated expiration date, a patch to update the
> entry's expiration date may be accepted, thereby prolonging its
> shelf life.  Unless such a thing happens before the expiration date
> comes, we will mechanically drop the entry.
> 
> Of course people _can_ resurrect an expired entry later as a new
> one when it seems appropriate.
> 
> That makes the decision to expire things from the list easy to make.

Works for me. Ideally, as any other topic, the retirement should be sent
to the mailing list as a normal patch series so that people may chime in
on the retirement and state reasons why they don't think that is a good
idea.

Patrick

Re: Git in GSoC 2025

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

>> How about making the rule a lot simpler?
>> 
>>     The expiration date kicks in _mechanically_, i.e. stale entries
>>     are unconditionally dropped at the date, based solely on the
>>     comparison between the timestamp and the wall clock.
>> 
>> People are free to advocate for its continued existence, and when
>> such an effort achieves a concensus among then-active members of the
>> community by the stated expiration date, a patch to update the
>> entry's expiration date may be accepted, thereby prolonging its
>> shelf life.  Unless such a thing happens before the expiration date
>> comes, we will mechanically drop the entry.
>> 
>> Of course people _can_ resurrect an expired entry later as a new
>> one when it seems appropriate.
>> 
>> That makes the decision to expire things from the list easy to make.
>
> Works for me. Ideally, as any other topic, the retirement should be sent
> to the mailing list as a normal patch series so that people may chime in
> on the retirement and state reasons why they don't think that is a good
> idea.

That is the complete opposite of the ideal from my point of view.
The whole point of making the list items expire by default is that
the onus is on those who want to have them on list to justify why
these items must remain on the list.  A patch to remove an item that
hasn't had anybody advocating for its retention shouldn't have to be
chimed in to be supported.  There shouldn't even have to be a patch;
that is what I mean by "stale entries expire mechanically by default".

Thanks.

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Fri, Jan 31, 2025 at 08:09:41AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> How about making the rule a lot simpler?
> >> 
> >>     The expiration date kicks in _mechanically_, i.e. stale entries
> >>     are unconditionally dropped at the date, based solely on the
> >>     comparison between the timestamp and the wall clock.
> >> 
> >> People are free to advocate for its continued existence, and when
> >> such an effort achieves a concensus among then-active members of the
> >> community by the stated expiration date, a patch to update the
> >> entry's expiration date may be accepted, thereby prolonging its
> >> shelf life.  Unless such a thing happens before the expiration date
> >> comes, we will mechanically drop the entry.
> >> 
> >> Of course people _can_ resurrect an expired entry later as a new
> >> one when it seems appropriate.
> >> 
> >> That makes the decision to expire things from the list easy to make.
> >
> > Works for me. Ideally, as any other topic, the retirement should be sent
> > to the mailing list as a normal patch series so that people may chime in
> > on the retirement and state reasons why they don't think that is a good
> > idea.
> 
> That is the complete opposite of the ideal from my point of view.
> The whole point of making the list items expire by default is that
> the onus is on those who want to have them on list to justify why
> these items must remain on the list.  A patch to remove an item that
> hasn't had anybody advocating for its retention shouldn't have to be
> chimed in to be supported.  There shouldn't even have to be a patch;
> that is what I mean by "stale entries expire mechanically by default".

I completely agree, we were simply talking past one another :) Retiring
an item from the list doesn't need any additional reason other than the
expiry date. But people can try to advocate for _keeping_ the item and
extend the expiry date in case they have a good reason.

Patrick

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Thu, Jan 30, 2025 at 11:18:44AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> >     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.
> 
> I do not mind either word, either, but I have two small issues to
> raise:
> 
>  - Is each topic "owned" by some specific person?  Would an owner
>    retires from the project, would the leftover bits go away with
>    the owner?

Good point. "Owner" to me rather indicates who is the primary contact
for a specific topic. It doesn't mean that nobody else is allowed to
contribute to it, and neither does it say that the person has any kind
of authority over it. So if that person doesn't care about the topic
anymore due to whatever reason it's also fair to change the primary
contact to somebody else.

>  - "relevant" may be a more appropriate adjective than "accurate".
>    An item in the list may still accurately expresses somebody's
>    wish, but because a better alternative has been implemented in
>    the meantime, the feature-wish may no longer relevant.

Agreed.

> >>   - Fix Sign Comparison Warnings in Git's Codebase
> 
> This one I am not sure if it is even something we want more of; a
> careless "-Wsign-compare" squelching often makes the resulting code
> worse.

That's a fair remark indeed. We could add it, but add a warning that
these refactorings are non-trivial?

Patrick

Re: Git in GSoC 2025

[Junio C Hamano]

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.

Re: Git in GSoC 2025

[Kaartic Sivaraam]

On 03/02/25 18:51, 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.
> 
> 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?
>

Just to cross-check this, isn't the current home for this file,
http://git.github.io, already a separate wiki of sorts? The site's
description literally says something along the same lines:

 > These pages are intended to be edited collaboratively (i.e., it is an
 > alternative to us having a wiki, but one that is edited entirely via
 > Git pushes. The repository could be found on GitHub.

So, do you think if it would be fine to leave it where it currently is?


[[ References ]]

[1]: https://git.github.io/

--
Sivaraam

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Christian,

On 20/01/25 13:49, Christian Couder wrote:
> 
> It might be nice if we could refresh our microproject idea list too.
> Maybe we could add ideas related to removing the_repository or
> compiling with -Wsign-compare?
>

Thank you for your suggestion! I've incorporated the `-Wsign-compare`
idea in the new microprojects page that I've created here:

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

Kindly check it and let me know your thoughts. Would it be possible for
you to add the 'the_repository' idea to the same? I could do that if you
could elaborate a bit on what we expect out of the microproject.

--
Sivaraam

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hello everyone,
>
> It is that time of year. GSoC Org Applications for 2025 are open now[1].
> They are due before Tuesday, February 11 at 1800 UTC. It's good to see
> that few contributors have already started working on microprojects this
> year :-)
>
> I could help as an Org Admin like previous years. I prefer not to
> volunteer as a mentor this time owing to other commitments, though.

Thanks for volunteering again :)

> There are no noticeable changes to the program this year.
>
> The GSoC contributor application period is March 24 - April 8, so
> (co-)mentors and org admins are already welcome to volunteer. As usual,
> we also need project ideas to refresh our idea page from last year
> (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> thoughts and discuss. It would be great if we could come up with a good
> mix of small, medium and large projects.
>

I'd be up for mentoring again this year. I see Patrick has posted some
projects already, I'll reply inline if I come up with something!

> Do feel free to ask if there's anything that needs to be clarified.
>
> Just like previous year, there will be a GSoC Meetup in Brussels during
> FOSDEM weekend on Saturday, February 1st in the evening. If you are
> around, interested and haven't received the link to register directly
> from Google, let me know so I can send it to you.
>
> [1]:
> https://opensource.googleblog.com/2025/01/google-summer-of-code-2025-is-here.html
>
> --
> Sivaraam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]

Re: Git in GSoC 2025

[shejialuo]

On Sun, Jan 19, 2025 at 03:43:29PM +0530, Kaartic Sivaraam wrote:
> Hello everyone,
> 
> It is that time of year. GSoC Org Applications for 2025 are open now[1].
> They are due before Tuesday, February 11 at 1800 UTC. It's good to see that
> few contributors have already started working on microprojects this year :-)
> 
> I could help as an Org Admin like previous years. I prefer not to
> volunteer as a mentor this time owing to other commitments, though.
> 

Thanks for volunteering again just like previous year.

> There are no noticeable changes to the program this year.
> 
> The GSoC contributor application period is March 24 - April 8, so
> (co-)mentors and org admins are already welcome to volunteer. As usual,
> we also need project ideas to refresh our idea page from last year
> (https://git.github.io/SoC-2024-Ideas/). Feel free to share your
> thoughts and discuss. It would be great if we could come up with a good mix
> of small, medium and large projects.
> 

I'd like to mentor for GSoC this year. However, I think I could only
co-mentor with others due to the following two reasons:

1. I am still learning the internal things of Git.
2. I could mentor the student during my off-work hours.

Thanks,
Jialuo

Re: Git in GSoC 2025

[Kaartic Sivaraam]

Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,


On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
>Hello everyone,
>
>It is that time of year. GSoC Org Applications for 2025 are open now[1].
>They are due before Tuesday, February 11 at 1800 UTC. It's good to see that few contributors have already started working on microprojects this year :-)
>

I'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!

Christian, Patrick and Karthik,

As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.

Ghanshyam and Jialuo,

As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.

Let's look forward towards for a great summer this year! :-)

[[ References ]]

[1]: https://summerofcode.withgoogle.com/programs/2025/organizations/git

-- 
Sivaraam

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git in GSoC 2025

[shejialuo]

On Fri, Feb 28, 2025 at 08:33:38AM +0530, Kaartic Sivaraam wrote:
> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
> 
> 
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> >Hello everyone,
> >
> >It is that time of year. GSoC Org Applications for 2025 are open now[1].
> >They are due before Tuesday, February 11 at 1800 UTC. It's good to see that few contributors have already started working on microprojects this year :-)
> >
> 
> I'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!
> 

Thanks for working on this.

> Christian, Patrick and Karthik,
> 
> As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
> 
> Ghanshyam and Jialuo,
> 
> As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
> 

I have already signed up and accepted the agreement.

> Let's look forward towards for a great summer this year! :-)
> 

Yes, that would be a great journey.

Thanks,
Jialuo

Re: Git in GSoC 2025

[Patrick Steinhardt]

On Fri, Feb 28, 2025 at 08:33:38AM +0530, Kaartic Sivaraam wrote:
> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
> 
> 
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> >Hello everyone,
> >
> >It is that time of year. GSoC Org Applications for 2025 are open now[1].
> >They are due before Tuesday, February 11 at 1800 UTC. It's good to see that few contributors have already started working on microprojects this year :-)
> >
> 
> I'm glad to announce that we've successfully been selected as a
> mentoring organization for GSoC this year[1]!

Yay!

> Christian, Patrick and Karthik,
> 
> As you're already members of the organization kindly log in to the
> GSoC portal to read and accept this year's Program Rules and Org
> Member agreement. Let me know once that's done. I could then add you
> to this year's program.

Thanks, I've accepted the docs.

Patrick

Re: Git in GSoC 2025

[Christian Couder]

On Fri, Feb 28, 2025 at 4:03 AM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:

> I'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!

Nice! Thanks for your work on this and for reporting it!

> Christian, Patrick and Karthik,
>
> As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.

Done.

> Let's look forward towards for a great summer this year! :-)

Sure :-)

Re: Git in GSoC 2025

[Ghanshyam Thakkar]

On Fri Feb 28, 2025 at 8:33 AM IST, Kaartic Sivaraam wrote:
> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
>
>
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> >Hello everyone,
> >
> >It is that time of year. GSoC Org Applications for 2025 are open now[1].
> >They are due before Tuesday, February 11 at 1800 UTC. It's good to see that few contributors have already started working on microprojects this year :-)
> >
>
> I'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!

Nice!

> As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.

I'e signed up and accepted the Program Rules and Org Member agreement.
Thanks for managing the process!

>
> Let's look forward towards for a great summer this year! :-)

Looking forward to it!

Re: Git in GSoC 2025

[Kaartic Sivaraam]

On 28 February 2025 8:33:38 am IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
>
>Christian, Patrick and Karthik,
>
>As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>
>Ghanshyam and Jialuo,
>
>As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>

Nice. I've added all of you to the 2025 program. You should be able to access this year's program page at:

  https://summerofcode.withgoogle.com/organizations/git/programs/2025/

-- 
Sivaraam

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git in GSoC 2025

[Karthik Nayak]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> Hi Christian, Patrick, Ghanshyam, Karthik, Jialuo and all,
>
>
> On 19 January 2025 3:43:29 pm IST, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
>>Hello everyone,
>>
>>It is that time of year. GSoC Org Applications for 2025 are open now[1].
>>They are due before Tuesday, February 11 at 1800 UTC. It's good to see that few contributors have already started working on microprojects this year :-)
>>
>
> I'm glad to announce that we've successfully been selected as a mentoring organization for GSoC this year[1]!
>
> Christian, Patrick and Karthik,
>
> As you're already members of the organization kindly log in to the GSoC portal to read and accept this year's Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>

That's amazing news. I've signed up. Thanks for handling all of this!

>
> Ghanshyam and Jialuo,
>
> As you're new to the program, I've sent you an invite. You should've got an e-mail about it. Kindly sign up via the same to read an accept the Program Rules and Org Member agreement. Let me know once that's done. I could then add you to this year's program.
>
> Let's look forward towards for a great summer this year! :-)
>
> [[ References ]]
>
> [1]: https://summerofcode.withgoogle.com/programs/2025/organizations/git
>
> --
> Sivaraam
>
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 690 bytes --]