Git in GSoC 2024

Git in GSoC 2024

[Kaartic Sivaraam]

Hi everyone,

GSoC Org Applications for 2024 are open now [1] and are due before 
Tuesday, February 6 at 1800 UTC. It's good to see that contributors have 
already started working on microprojects this year :-)

I could help as an Org Admin like previous years. I could volunteer as a 
mentor depending on the set of available projects that we're able to 
gather for this year.

There are one noticeable change to the program that should be highlighted:

"For 2024 we have the concept of Small ~90 hour projects that are a
  standard 8 weeks long (they can extended but it is suggest not
  extending beyond 12 weeks for the small projects). We aren't
  required to have small projects available but might be worth
  considering if we have any small projects that contributors could
  work on."

The GSoC contributor application deadline is April 2 - 18:00 UTC, 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-2023-Ideas/). Feel free to share your 
thoughts and discuss.

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

There's also seems to be a GSoC stand at FOSDEM on Saturday or Sunday. 
It's said to be located in building H, level 1.

[1]: 
https://opensource.googleblog.com/2024/01/google-summer-of-code-2024-mentor-organization-applications-now-open.html

-- 
Sivaraam

Re: Git in GSoC 2024

[Christian Couder]

Hi Kaartic and all,

On Mon, Jan 29, 2024 at 7:16 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
>
> Hi everyone,
>
> GSoC Org Applications for 2024 are open now [1] and are due before
> Tuesday, February 6 at 1800 UTC. It's good to see that contributors have
> already started working on microprojects this year :-)
>
> I could help as an Org Admin like previous years. I could volunteer as a
> mentor depending on the set of available projects that we're able to
> gather for this year.

Thanks a lot for sending this and for volunteering as an Org Admin and
possibly as a mentor too!

> There are one noticeable change to the program that should be highlighted:
>
> "For 2024 we have the concept of Small ~90 hour projects that are a
>   standard 8 weeks long (they can extended but it is suggest not
>   extending beyond 12 weeks for the small projects). We aren't
>   required to have small projects available but might be worth
>   considering if we have any small projects that contributors could
>   work on."

Unless some mentors are only willing to mentor Small projects, I don't
think it's a good idea to propose such projects. Except for some very
good contributors, I think it usually takes a long time for the
contributors we mentor to become efficient and autonomous enough by
themselves. So I think a Small project would likely leave the
contributor halfway there, and they would then have trouble continuing
to work on their project if it's not finished or contributing
significantly in some way afterwards.

> The GSoC contributor application deadline is April 2 - 18:00 UTC, 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-2023-Ideas/). Feel free to share your
> thoughts and discuss.

I am volunteering as both an Org Admin and a mentor too.

I am not sure how many tests there are left to be ported to the new
unit test framework. Patrick told me about porting some reftable unit
tests to the new unit test framework though. So it might still work as
a GSoC project.

> 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 3rd 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.
>
> There's also seems to be a GSoC stand at FOSDEM on Saturday or Sunday.
> It's said to be located in building H, level 1.

Unfortunately I cannot attend the FOSDEM this year. Thanks for
mentioning this though! It's a great opportunity to meet GSoC people
and open source people in general.

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Tue, Jan 30, 2024 at 09:38:48AM +0100, Christian Couder wrote:
> On Mon, Jan 29, 2024 at 7:16 PM Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> wrote:
[snip]
> > The GSoC contributor application deadline is April 2 - 18:00 UTC, 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-2023-Ideas/). Feel free to share your
> > thoughts and discuss.
> 
> I am volunteering as both an Org Admin and a mentor too.
> 
> I am not sure how many tests there are left to be ported to the new
> unit test framework. Patrick told me about porting some reftable unit
> tests to the new unit test framework though. So it might still work as
> a GSoC project.

Yes, the tests in t0032-reftable-unittest.sh should be ported over to
the new unit test framework eventually, and I think that this might be a
good GSoC project indeed.

If there is interest I'd also be happy to draft up some more topics in
the context of refs and the reftable backend. I'm sure there should be
some topics here that would be a good fit for the GSoC project, and I'd
be happy to mentor any such project in this context.

Patrick

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

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Tue, Jan 30, 2024 at 10:08:53AM +0100, Patrick Steinhardt wrote:
> On Tue, Jan 30, 2024 at 09:38:48AM +0100, Christian Couder wrote:
> > On Mon, Jan 29, 2024 at 7:16 PM Kaartic Sivaraam
> > <kaartic.sivaraam@gmail.com> wrote:
> [snip]
> > > The GSoC contributor application deadline is April 2 - 18:00 UTC, 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-2023-Ideas/). Feel free to share your
> > > thoughts and discuss.
> > 
> > I am volunteering as both an Org Admin and a mentor too.
> > 
> > I am not sure how many tests there are left to be ported to the new
> > unit test framework. Patrick told me about porting some reftable unit
> > tests to the new unit test framework though. So it might still work as
> > a GSoC project.
> 
> Yes, the tests in t0032-reftable-unittest.sh should be ported over to
> the new unit test framework eventually, and I think that this might be a
> good GSoC project indeed.
> 
> If there is interest I'd also be happy to draft up some more topics in
> the context of refs and the reftable backend. I'm sure there should be
> some topics here that would be a good fit for the GSoC project, and I'd
> be happy to mentor any such project in this context.

I noticed that the starting period falls right into my honeymoon from
June 17th until July 19th. This unfortunately makes it quite a lot
harder for me to mentor projects alone. Still, I'd be happy to co-mentor
or help out in other ways.

Patrick

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

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Patrick,

On 31 January 2024 6:40:36 pm IST, Patrick Steinhardt <ps@pks.im> wrote:
>On Tue, Jan 30, 2024 at 10:08:53AM +0100, Patrick Steinhardt wrote:
>> On Tue, Jan 30, 2024 at 09:38:48AM +0100, Christian Couder wrote:
>>
>> Yes, the tests in t0032-reftable-unittest.sh should be ported over to
>> the new unit test framework eventually, and I think that this might be a
>> good GSoC project indeed.
>> 

Nice. Good to hear that.

>> If there is interest I'd also be happy to draft up some more topics in
>> the context of refs and the reftable backend. I'm sure there should be
>> some topics here that would be a good fit for the GSoC project, and I'd
>> be happy to mentor any such project in this context.
>

Great. Thanks for your interest in willing to mentor!

I created a fairly rough SoC ideas page for now including a barebones 
information about the unit test migration idea:

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

Note well that the existing idea's description is far from complete and 
I mostly just cooked it up to serve as a template for how the idea entry 
could look like. Kindly contribute towards elaborating the same :-)

Also, feel free to suggest ideas you have around refs and reftable 
backed, Patrick. Those would be helpful.

>I noticed that the starting period falls right into my honeymoon from
>June 17th until July 19th. This unfortunately makes it quite a lot
>harder for me to mentor projects alone. Still, I'd be happy to co-mentor
>or help out in other ways.
>

I too don't believe your vacation is going to be a deal breaker for you 
being a mentor. It should be totally fine given that we get a backup 
mentor who is also willing to mentor the candidate. (side note: I myself 
have no knowledge about refs backends. So, I suppose I might not be able 
to help co-mentor this one).

Reg. the timline [1] Jun 17th won't be much of the start. The community 
bonding period starts May 1. Many contributors typically start dipping 
their toes into their project right away. So, you would have ample time 
before the start of the vacation to set the contributor up and going 
with the project.

[1]: https://developers.google.com/open-source/gsoc/timeline

--
Sivaraam

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi,

On 31/01/24 23:27, Kaartic Sivaraam wrote:
> 
> Great. Thanks for your interest in willing to mentor!
> 
> I created a fairly rough SoC ideas page for now including a barebones 
> information about the unit test migration idea:
> 
> https://git.github.io/SoC-2024-Ideas/
> 

For the note, I also put up the 2024 microprojects page by basically 
renaming the 2022 page. I'm supposing the projects are still relevant. 
Kindly correct me if that's not the case.

https://git.github.io/SoC-2024-Microprojects/

Also, feel free to suggest other microproject ideas that you may have.

-- 
Sivaraam

Re: Git in GSoC 2024

[Karthik Nayak]

Hello all!

On Wed, Jan 31, 2024 at 6:58 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
>
> Hi Patrick,
>
> On 31 January 2024 6:40:36 pm IST, Patrick Steinhardt <ps@pks.im> wrote:
> >On Tue, Jan 30, 2024 at 10:08:53AM +0100, Patrick Steinhardt wrote:
> >> On Tue, Jan 30, 2024 at 09:38:48AM +0100, Christian Couder wrote:
> >>
> >> Yes, the tests in t0032-reftable-unittest.sh should be ported over to
> >> the new unit test framework eventually, and I think that this might be a
> >> good GSoC project indeed.
> >>
>
> Nice. Good to hear that.
>
> >> If there is interest I'd also be happy to draft up some more topics in
> >> the context of refs and the reftable backend. I'm sure there should be
> >> some topics here that would be a good fit for the GSoC project, and I'd
> >> be happy to mentor any such project in this context.
> >
>
> Great. Thanks for your interest in willing to mentor!
>
> I created a fairly rough SoC ideas page for now including a barebones
> information about the unit test migration idea:
>
> https://git.github.io/SoC-2024-Ideas/
>
> Note well that the existing idea's description is far from complete and
> I mostly just cooked it up to serve as a template for how the idea entry
> could look like. Kindly contribute towards elaborating the same :-)
>
> Also, feel free to suggest ideas you have around refs and reftable
> backed, Patrick. Those would be helpful.
>
> >I noticed that the starting period falls right into my honeymoon from
> >June 17th until July 19th. This unfortunately makes it quite a lot
> >harder for me to mentor projects alone. Still, I'd be happy to co-mentor
> >or help out in other ways.
> >
>
> I too don't believe your vacation is going to be a deal breaker for you
> being a mentor. It should be totally fine given that we get a backup
> mentor who is also willing to mentor the candidate. (side note: I myself
> have no knowledge about refs backends. So, I suppose I might not be able
> to help co-mentor this one).

I should be able to help out here, happy to co-mentor on the reftable topics.

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Wed, Jan 31, 2024 at 11:27:13PM +0530, Kaartic Sivaraam wrote:
> Hi Patrick,
> 
> On 31 January 2024 6:40:36 pm IST, Patrick Steinhardt <ps@pks.im> wrote:
> > On Tue, Jan 30, 2024 at 10:08:53AM +0100, Patrick Steinhardt wrote:
> > > On Tue, Jan 30, 2024 at 09:38:48AM +0100, Christian Couder wrote:
> > > 
> > > Yes, the tests in t0032-reftable-unittest.sh should be ported over to
> > > the new unit test framework eventually, and I think that this might be a
> > > good GSoC project indeed.
> > > 
> 
> Nice. Good to hear that.
> 
> > > If there is interest I'd also be happy to draft up some more topics in
> > > the context of refs and the reftable backend. I'm sure there should be
> > > some topics here that would be a good fit for the GSoC project, and I'd
> > > be happy to mentor any such project in this context.
> > 
> 
> Great. Thanks for your interest in willing to mentor!
> 
> I created a fairly rough SoC ideas page for now including a barebones
> information about the unit test migration idea:
> 
> https://git.github.io/SoC-2024-Ideas/
> 
> Note well that the existing idea's description is far from complete and I
> mostly just cooked it up to serve as a template for how the idea entry could
> look like. Kindly contribute towards elaborating the same :-)
> 
> Also, feel free to suggest ideas you have around refs and reftable backed,
> Patrick. Those would be helpful.

I'll have a the beginning of next week and will think about topics
meanwhile.

> > I noticed that the starting period falls right into my honeymoon from
> > June 17th until July 19th. This unfortunately makes it quite a lot
> > harder for me to mentor projects alone. Still, I'd be happy to co-mentor
> > or help out in other ways.
> > 
> 
> I too don't believe your vacation is going to be a deal breaker for you
> being a mentor. It should be totally fine given that we get a backup mentor
> who is also willing to mentor the candidate. (side note: I myself have no
> knowledge about refs backends. So, I suppose I might not be able to help
> co-mentor this one).
> 
> Reg. the timline [1] Jun 17th won't be much of the start. The community
> bonding period starts May 1. Many contributors typically start dipping their
> toes into their project right away. So, you would have ample time before the
> start of the vacation to set the contributor up and going with the project.
> 
> [1]: https://developers.google.com/open-source/gsoc/timeline

Yeah, as long as there is a co-mentor that can take over during my
absence I'm happy to do it. Karthik said that he'd be willing to cover
me, which I think would be a good fit given that he's already got quite
a bit of exposure to the reftable backend internally at GitLab. Thanks!

Patrick

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

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Patrick, Karthik and Christian,

For the note, other project ideas and volunteer are always welcome. So, 
feel free to chime in if you have any ideas or wish to volunteer as a 
mentor to guide potential future contributors of the community. :-)

On 01/02/24 15:08, Patrick Steinhardt wrote:
> On Wed, Jan 31, 2024 at 11:27:13PM +0530, Kaartic Sivaraam wrote:
>>
>> I created a fairly rough SoC ideas page for now including a barebones
>> information about the unit test migration idea:
>>
>> https://git.github.io/SoC-2024-Ideas/
>>
>> Note well that the existing idea's description is far from complete and I
>> mostly just cooked it up to serve as a template for how the idea entry could
>> look like. Kindly contribute towards elaborating the same :-)
>>
>> Also, feel free to suggest ideas you have around refs and reftable backed,
>> Patrick. Those would be helpful.
> 
> I'll have a the beginning of next week and will think about topics
> meanwhile.
>

Thanks, Patrick! It would be great if you could share the same as soon 
as possible. The deadline for applying to GSoC is Feb 6 (18:00 UTC) and 
we need the ideas page to be decent enough before we go ahead with 
applying for this year.

If the elaborate project description could take time, feel free to share 
a paragraph or two that are supplemented with a few references. That 
should be sufficient for applying to GSoC.

Christian,

It would be great if you could look into and improve the detail for the 
unit test migration idea. I just added a very terse description based on 
what I could get my hands on. If you think the description we used for 
the Outreachy round would do, kindly update the page with the same or 
kindly share it here so that I could update the same in the ideas page :-)

> 
> Yeah, as long as there is a co-mentor that can take over during my
> absence I'm happy to do it. Karthik said that he'd be willing to cover
> me, which I think would be a good fit given that he's already got quite
> a bit of exposure to the reftable backend internally at GitLab. Thanks!
> 

Sounds good. Thank you for volunteering to co-mentor, Karthik!

-- 
Sivaraam

Re: Git in GSoC 2024

[Kaartic Sivaraam]

On 03/02/24 17:11, Kaartic Sivaraam wrote:
> 
> On 01/02/24 15:08, Patrick Steinhardt wrote:
>>
>> I'll have a the beginning of next week and will think about topics
>> meanwhile.
>>
> 
> Thanks, Patrick! It would be great if you could share the same as soon 
> as possible. The deadline for applying to GSoC is Feb 6 (18:00 UTC) and 
> we need the ideas page to be decent enough before we go ahead with 
> applying for this year.
> 
> If the elaborate project description could take time, feel free to share 
> a paragraph or two that are supplemented with a few references. That 
> should be sufficient for applying to GSoC.
> 

If at all it's helpful, you could find the earlier idea pages in the 
website repo [1]. For instance, the one from 2022 could be found at [2].


[[ References ]]

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

[2]: https://github.com/git/git.github.io/blob/master/SoC-2022-Ideas.md

-- 
Sivaraam

[PATCH] Add ideas for GSoC 2024

[Patrick Steinhardt]

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

Add project ideas for the GSoC 2024.
---

I came up with four different topics:

  - The reftable unit test refactorings. This topic can also be squashed
    into the preexisting unit test topics, I wouldn't mind. In that case
    I'd be happy to be a possible mentor, too.

  - Ref consistency checks for git-fsck(1). This should be rather
    straight forward and make for an interesting topic.

  - Making git-bisect(1)'s state more self-contained as recently
    discussed. This topic is easy to implement, but the backwards
    compatibility issues might require a lot of attention.

  - Implementing support for reftables in the "dumb" HTTP protocol. It's
    quite niche given that the dumb protocol isn't really used much
    nowadays anymore. But it could make for an interesting project
    regardless.

It's hard to estimate for me whether their scope is either too small or
too big. So please feel free to chime in and share your concerns if you
think that any of those proposals don't make much sense in your opinion.

Patrick

 SoC-2024-Ideas.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 129 insertions(+)

diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md
index 3efbcaf..286aea0 100644
--- a/SoC-2024-Ideas.md
+++ b/SoC-2024-Ideas.md
@@ -39,3 +39,132 @@ Languages: C, shell(bash)
 Possible mentors:
 * Christian Couder < <christian.couder@gmail.com> >
 
+### Convert reftable unit tests to use the unit testing framework
+
+The "reftable" unit tests in "t0032-reftable-unittest.sh"
+predate the unit testing framework that was recently
+introduced into Git. These tests should be converted to use
+the new framework.
+
+See:
+
+  - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@google.com/>
+
+Expected Project Size: 175 hours or 350 hours
+
+Difficulty: Low
+
+Languages: C, shell(bash)
+
+Possible mentors:
+* Patrick Steinhardt < <ps@pks.im> >
+* Karthik Nayak < <karthik.188@gmail.com> >
+
+### Implement consistency checks for refs
+
+The git-fsck(1) command is used to check various data
+structures for consistency. Notably missing though are
+consistency checks for the refdb. While git-fsck(1)
+implicitly checks some of the properties of the refdb
+because it uses its refs for a connectivity check, these
+checks aren't sufficient to properly ensure that all refs
+are properly consistent.
+
+The goal of this project would be to introduce consistency
+checks that can be implemented by the ref backend. Initially
+these checks may only apply to the "files" backend. With the
+ongoing efforts to upstream a new "reftable" backend the
+effort may be extended.
+
+See:
+
+  - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@rd10.de/
+  - https://lore.kernel.org/git/cover.1706601199.git.ps@pks.im/
+
+Expected Project Size: 175 hours or 350 hours
+
+Difficulty: Medium
+
+Languages: C, shell(bash)
+
+Possible mentors:
+* Patrick Steinhardt < <ps@pks.im> >
+* Karthik Nayak < <karthik.188@gmail.com> >
+
+### Refactor git-bisect(1) to make its state self-contained
+
+The git-bisect(1) command is used to find a commit in a
+range of commits that introduced a specific bug. Starting a
+bisection run creates a set of state files into the Git
+repository which record various different parameters like
+".git/BISECT_START". These files look almost like refs
+due to their names being all-uppercase. This has led to
+confusion with the new "reftable" backend because it wasn't
+quite clear whether those files are in fact refs or not.
+
+As it turns out they are not refs and should never be
+treated like one. Overall, it has been concluded that the
+way those files are currently stored is not ideal. Instead
+of having a proliferation of files in the Git directory, it
+was discussed whether the bisect state should be moved into
+its own "bisect-state" subdirectory. This would make it more
+self-contained and thereby avoid future confusion. It is
+also aligned with the sequencer state used by rebases, which
+is neatly contained in the "rebase-apply" and "rebase-merge"
+directories.
+
+The goal of this project would be to realize this change.
+While rearchitecting the layout should be comparatively easy
+to do, the harder part will be to hash out how to handle
+backwards compatibility.
+
+See:
+
+  - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/
+
+Expected Project Size: 175 hours or 350 hours
+
+Difficulty: Medium
+
+Languages: C, shell(bash)
+
+Possible mentors:
+* Patrick Steinhardt < <ps@pks.im> >
+* Karthik Nayak < <karthik.188@gmail.com> >
+
+### Implement support for reftables in "dumb" HTTP transport
+
+Fetching Git repositories uses one of two major protocols:
+
+  - The "dumb" protocol works without requiring any kind of
+    interactive negotiation like a CGI module. It can thus
+    be served by a static web server.
+
+  - The "smart" protocol works by having the client and
+    server exchange multiple messages with each other. It is
+    more efficient, but requires support for Git in the
+    server.
+
+While almost all servers nowadays use the "smart" protocol,
+there are still some that use the "dumb" protocol.
+
+The "dumb" protocol cannot serve repositories which use the
+"reftable" backend though. While there exists a "info/refs"
+file that is supposed to be backend-agnostic, this file does
+not contain information about the default branch. Instead,
+clients are expected to download the "HEAD" file and derive
+the default branch like that. This file is a mere stub in
+the "reftable" backend though, which breaks this protocol.
+
+The goal of this project is to implement "reftable" support
+for "dumb" fetches.
+
+Expected Project Size: 175 hours or 350 hours
+
+Difficulty: Medium
+
+Languages: C, shell(bash)
+
+Possible mentors:
+* Patrick Steinhardt < <ps@pks.im> >
+* Karthik Nayak < <karthik.188@gmail.com> >
-- 
2.43.GIT


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

Re: [PATCH] Add ideas for GSoC 2024

[Christian Couder]

On Mon, Feb 5, 2024 at 9:39 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> Add project ideas for the GSoC 2024.
> ---
>
> I came up with four different topics:
>
>   - The reftable unit test refactorings. This topic can also be squashed
>     into the preexisting unit test topics, I wouldn't mind. In that case
>     I'd be happy to be a possible mentor, too.
>
>   - Ref consistency checks for git-fsck(1). This should be rather
>     straight forward and make for an interesting topic.
>
>   - Making git-bisect(1)'s state more self-contained as recently
>     discussed. This topic is easy to implement, but the backwards
>     compatibility issues might require a lot of attention.
>
>   - Implementing support for reftables in the "dumb" HTTP protocol. It's
>     quite niche given that the dumb protocol isn't really used much
>     nowadays anymore. But it could make for an interesting project
>     regardless.
>
> It's hard to estimate for me whether their scope is either too small or
> too big. So please feel free to chime in and share your concerns if you
> think that any of those proposals don't make much sense in your opinion.

Thanks a lot for these ideas! I have applied your patch and pushed it.

I have a few concerns though, see below.

>  SoC-2024-Ideas.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 129 insertions(+)
>
> diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md
> index 3efbcaf..286aea0 100644
> --- a/SoC-2024-Ideas.md
> +++ b/SoC-2024-Ideas.md
> @@ -39,3 +39,132 @@ Languages: C, shell(bash)
>  Possible mentors:
>  * Christian Couder < <christian.couder@gmail.com> >
>
> +### Convert reftable unit tests to use the unit testing framework
> +
> +The "reftable" unit tests in "t0032-reftable-unittest.sh"
> +predate the unit testing framework that was recently
> +introduced into Git. These tests should be converted to use
> +the new framework.
> +
> +See:
> +
> +  - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@google.com/>
> +
> +Expected Project Size: 175 hours or 350 hours
> +
> +Difficulty: Low

"Difficulty: Low" might not be very accurate from the point of view of
contributors. I think it's always quite difficult to contribute
something significant to Git, and sometimes more than we expected.

> +Languages: C, shell(bash)
> +
> +Possible mentors:
> +* Patrick Steinhardt < <ps@pks.im> >
> +* Karthik Nayak < <karthik.188@gmail.com> >
> +
> +### Implement consistency checks for refs
> +
> +The git-fsck(1) command is used to check various data
> +structures for consistency. Notably missing though are
> +consistency checks for the refdb. While git-fsck(1)
> +implicitly checks some of the properties of the refdb
> +because it uses its refs for a connectivity check, these
> +checks aren't sufficient to properly ensure that all refs
> +are properly consistent.
> +
> +The goal of this project would be to introduce consistency
> +checks that can be implemented by the ref backend. Initially
> +these checks may only apply to the "files" backend. With the
> +ongoing efforts to upstream a new "reftable" backend the
> +effort may be extended.
> +
> +See:
> +
> +  - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@rd10.de/
> +  - https://lore.kernel.org/git/cover.1706601199.git.ps@pks.im/
> +
> +Expected Project Size: 175 hours or 350 hours
> +
> +Difficulty: Medium
> +
> +Languages: C, shell(bash)
> +
> +Possible mentors:
> +* Patrick Steinhardt < <ps@pks.im> >
> +* Karthik Nayak < <karthik.188@gmail.com> >
> +
> +### Refactor git-bisect(1) to make its state self-contained
> +
> +The git-bisect(1) command is used to find a commit in a
> +range of commits that introduced a specific bug. Starting a
> +bisection run creates a set of state files into the Git
> +repository which record various different parameters like
> +".git/BISECT_START". These files look almost like refs
> +due to their names being all-uppercase. This has led to
> +confusion with the new "reftable" backend because it wasn't
> +quite clear whether those files are in fact refs or not.
> +
> +As it turns out they are not refs and should never be
> +treated like one. Overall, it has been concluded that the
> +way those files are currently stored is not ideal. Instead
> +of having a proliferation of files in the Git directory, it
> +was discussed whether the bisect state should be moved into
> +its own "bisect-state" subdirectory. This would make it more
> +self-contained and thereby avoid future confusion. It is
> +also aligned with the sequencer state used by rebases, which
> +is neatly contained in the "rebase-apply" and "rebase-merge"
> +directories.
> +
> +The goal of this project would be to realize this change.
> +While rearchitecting the layout should be comparatively easy
> +to do, the harder part will be to hash out how to handle
> +backwards compatibility.
> +
> +See:
> +
> +  - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/

From reading the discussion it looks like everyone is Ok with doing
this. I really hope that we are not missing something that might make
us decide early not to do this though.

> +Expected Project Size: 175 hours or 350 hours
> +
> +Difficulty: Medium
> +
> +Languages: C, shell(bash)
> +
> +Possible mentors:
> +* Patrick Steinhardt < <ps@pks.im> >
> +* Karthik Nayak < <karthik.188@gmail.com> >

Re: [PATCH] Add ideas for GSoC 2024

[Kaartic Sivaraam]

Hi Patrick, Christian and all,

On 05/02/24 22:13, Christian Couder wrote:
> 
> Thanks a lot for these ideas! I have applied your patch and pushed it.
> 

Yeah. Thanks for sharing these great ideas! I've submitted the 
application using the new ideas page now as mentioned in the parent thread.

>> +### Convert reftable unit tests to use the unit testing framework
>> +
>> +The "reftable" unit tests in "t0032-reftable-unittest.sh"
>> +predate the unit testing framework that was recently
>> +introduced into Git. These tests should be converted to use
>> +the new framework.
>> +
>> +See:
>> +
>> +  - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@google.com/>
>> +
>> +Expected Project Size: 175 hours or 350 hours
>> +
>> +Difficulty: Low
> 
> "Difficulty: Low" might not be very accurate from the point of view of
> contributors. I think it's always quite difficult to contribute
> something significant to Git, and sometimes more than we expected.
> 

Makes sense. Also, I'm kind of cat-one-the-wall about whether it makes 
sense to have two projects about the unit test migration effort itself. 
If we're clear that both of them would not overlap, it should be fine. 
Otherwise, it would be better to merge them as Patrick suggests.

That said, how helpful would it be to link the following doc in the unit 
testing related ideas?

https://github.com/git/git/blob/master/Documentation/technical/unit-tests.txt

>> +### Implement consistency checks for refs
>> +
 >>
 >> [ ... snip ... ]
 >>
>> +
>> +  - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@rd10.de/
>> +  - https://lore.kernel.org/git/cover.1706601199.git.ps@pks.im/
>> +
 >> [ .... snip ... ]
>> +
>> +### Implement support for reftables in "dumb" HTTP transport

Would it worth linking the reftable technical doc for the above ideas?

https://git-scm.com/docs/reftable

I could see it goes into a lot of detail. I'm just wondering if link to 
it would help someone who's looking to learn about reftable.

-- 
Sivaraam

Re: [PATCH] Add ideas for GSoC 2024

[Patrick Steinhardt]

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

On Tue, Feb 06, 2024 at 12:25:31AM +0530, Kaartic Sivaraam wrote:
> Hi Patrick, Christian and all,
> 
> On 05/02/24 22:13, Christian Couder wrote:
> > 
> > Thanks a lot for these ideas! I have applied your patch and pushed it.
> > 
> 
> Yeah. Thanks for sharing these great ideas! I've submitted the application
> using the new ideas page now as mentioned in the parent thread.
> 
> > > +### Convert reftable unit tests to use the unit testing framework
> > > +
> > > +The "reftable" unit tests in "t0032-reftable-unittest.sh"
> > > +predate the unit testing framework that was recently
> > > +introduced into Git. These tests should be converted to use
> > > +the new framework.
> > > +
> > > +See:
> > > +
> > > +  - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@google.com/>
> > > +
> > > +Expected Project Size: 175 hours or 350 hours
> > > +
> > > +Difficulty: Low
> > 
> > "Difficulty: Low" might not be very accurate from the point of view of
> > contributors. I think it's always quite difficult to contribute
> > something significant to Git, and sometimes more than we expected.
> > 
> 
> Makes sense. Also, I'm kind of cat-one-the-wall about whether it makes sense
> to have two projects about the unit test migration effort itself. If we're
> clear that both of them would not overlap, it should be fine. Otherwise, it
> would be better to merge them as Patrick suggests.

I don't quite mind either way. I think overall we have enough tests that
can be converted even if both projects got picked up separately. And the
reftable unit tests are a bit more involved than the other tests given
that their coding style doesn't fit at all into the Git project. So it's
not like they can just be copied over, they definitely need some special
care.

Also, the technical complexity of the "reftable" backend is rather high,
which is another hurdle to take.

Which overall makes me lean more towards keeping this as a separate
project now that I think about it.

> That said, how helpful would it be to link the following doc in the unit
> testing related ideas?
> 
> https://github.com/git/git/blob/master/Documentation/technical/unit-tests.txt

Makes sense to me.

> > > +### Implement consistency checks for refs
> > > +
> >>
> >> [ ... snip ... ]
> >>
> > > +
> > > +  - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@rd10.de/
> > > +  - https://lore.kernel.org/git/cover.1706601199.git.ps@pks.im/
> > > +
> >> [ .... snip ... ]
> > > +
> > > +### Implement support for reftables in "dumb" HTTP transport
> 
> Would it worth linking the reftable technical doc for the above ideas?
> 
> https://git-scm.com/docs/reftable
> 
> I could see it goes into a lot of detail. I'm just wondering if link to it
> would help someone who's looking to learn about reftable.

Definitely doesn't hurt.

Patrick

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

Re: [PATCH] Add ideas for GSoC 2024

[Christian Couder]

On Tue, Feb 6, 2024 at 6:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> On Tue, Feb 06, 2024 at 12:25:31AM +0530, Kaartic Sivaraam wrote:

> > Makes sense. Also, I'm kind of cat-one-the-wall about whether it makes sense
> > to have two projects about the unit test migration effort itself. If we're
> > clear that both of them would not overlap, it should be fine. Otherwise, it
> > would be better to merge them as Patrick suggests.
>
> I don't quite mind either way. I think overall we have enough tests that
> can be converted even if both projects got picked up separately. And the
> reftable unit tests are a bit more involved than the other tests given
> that their coding style doesn't fit at all into the Git project. So it's
> not like they can just be copied over, they definitely need some special
> care.
>
> Also, the technical complexity of the "reftable" backend is rather high,
> which is another hurdle to take.
>
> Which overall makes me lean more towards keeping this as a separate
> project now that I think about it.

Ok, for me. If we have a contributor working on each of these 2
projects, we just need to be clear that the contributors should not
work together on the 2 projects as I think the GSoC forbids that.

> > That said, how helpful would it be to link the following doc in the unit
> > testing related ideas?
> >
> > https://github.com/git/git/blob/master/Documentation/technical/unit-tests.txt
>
> Makes sense to me.

To me too.

> > Would it worth linking the reftable technical doc for the above ideas?
> >
> > https://git-scm.com/docs/reftable
> >
> > I could see it goes into a lot of detail. I'm just wondering if link to it
> > would help someone who's looking to learn about reftable.
>
> Definitely doesn't hurt.

I agree.

Thanks!

Re: [PATCH] Add ideas for GSoC 2024

[Kaartic Sivaraam]

Hi Patrick amd Christian,


On 6 February 2024 1:43:02 pm IST, Christian Couder <christian.couder@gmail.com> wrote:
>On Tue, Feb 6, 2024 at 6:51 AM Patrick Steinhardt <ps@pks.im> wrote:
>> On Tue, Feb 06, 2024 at 12:25:31AM +0530, Kaartic Sivaraam wrote:
>
>> I don't quite mind either way. I think overall we have enough tests that
>> can be converted even if both projects got picked up separately. And the
>> reftable unit tests are a bit more involved than the other tests given
>> that their coding style doesn't fit at all into the Git project. So it's
>> not like they can just be copied over, they definitely need some special
>> care.
>>
>> Also, the technical complexity of the "reftable" backend is rather high,
>> which is another hurdle to take.
>>
>> Which overall makes me lean more towards keeping this as a separate
>> project now that I think about it.

Makes sense.  I suppose we need to capture the distinction more clearly in the ideas page.

I've tweaked the doc for the same. Do check it out and feel free to suggest any corrections.

Ideas page: https://git.github.io/SoC-2024-Ideas/

>Ok, for me. If we have a contributor working on each of these 2
>projects, we just need to be clear that the contributors should not
>work together on the 2 projects as I think the GSoC forbids that.
>

Indeed. We must make sure to communicate this to selected contributors if we end up choosing two of them for the unit test migration projects.

On a related note, I think I could help as a co-mentor the non-reftable unit tests migration project if we don't find any other willing volunteer. :-) 

I'm hoping I should be of some help on guiding the contributor as a co-mentor. Feel free to let me correct me if I might potentially lack required knowledge.

>> > That said, how helpful would it be to link the following doc in the unit
>> > testing related ideas?
>> >
>> > https://github.com/git/git/blob/master/Documentation/technical/unit-tests.txt
>>
>> Makes sense to me.
>
>To me too.
>
>> > Would it worth linking the reftable technical doc for the above ideas?
>> >
>> > https://git-scm.com/docs/reftable
>> >
>> > I could see it goes into a lot of detail. I'm just wondering if link to it
>> > would help someone who's looking to learn about reftable.
>>
>> Definitely doesn't hurt.
>
>I agree.
>

Thanks for the feedback. Included both of these links in relevant ideas too. Feel free to cross-check them!

-- 
Sivaraam

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

Re: [PATCH] Add ideas for GSoC 2024

[Patrick Steinhardt]

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

On Thu, Feb 08, 2024 at 07:32:50PM +0530, Kaartic Sivaraam wrote:
> Hi Patrick amd Christian,
> 
> 
> On 6 February 2024 1:43:02 pm IST, Christian Couder <christian.couder@gmail.com> wrote:
> >On Tue, Feb 6, 2024 at 6:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> >> On Tue, Feb 06, 2024 at 12:25:31AM +0530, Kaartic Sivaraam wrote:
> >
> >> I don't quite mind either way. I think overall we have enough tests that
> >> can be converted even if both projects got picked up separately. And the
> >> reftable unit tests are a bit more involved than the other tests given
> >> that their coding style doesn't fit at all into the Git project. So it's
> >> not like they can just be copied over, they definitely need some special
> >> care.
> >>
> >> Also, the technical complexity of the "reftable" backend is rather high,
> >> which is another hurdle to take.
> >>
> >> Which overall makes me lean more towards keeping this as a separate
> >> project now that I think about it.
> 
> Makes sense.  I suppose we need to capture the distinction more
> clearly in the ideas page.
> 
> I've tweaked the doc for the same. Do check it out and feel free to
> suggest any corrections.
> 
> Ideas page: https://git.github.io/SoC-2024-Ideas/

Yeah, the clarification looks good to me. Thanks!

Patrick

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

Re: [PATCH] Add ideas for GSoC 2024

[Christian Couder]

Hi Kaartic,

On Thu, Feb 8, 2024 at 3:02 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> On 6 February 2024 1:43:02 pm IST, Christian Couder <christian.couder@gmail.com> wrote:
> >On Tue, Feb 6, 2024 at 6:51 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> >> I don't quite mind either way. I think overall we have enough tests that
> >> can be converted even if both projects got picked up separately. And the
> >> reftable unit tests are a bit more involved than the other tests given
> >> that their coding style doesn't fit at all into the Git project. So it's
> >> not like they can just be copied over, they definitely need some special
> >> care.
> >>
> >> Also, the technical complexity of the "reftable" backend is rather high,
> >> which is another hurdle to take.
> >>
> >> Which overall makes me lean more towards keeping this as a separate
> >> project now that I think about it.
>
> Makes sense.  I suppose we need to capture the distinction more clearly in the ideas page.
>
> I've tweaked the doc for the same. Do check it out and feel free to suggest any corrections.
>
> Ideas page: https://git.github.io/SoC-2024-Ideas/

Thanks! It looks good to me too.

> >Ok, for me. If we have a contributor working on each of these 2
> >projects, we just need to be clear that the contributors should not
> >work together on the 2 projects as I think the GSoC forbids that.
>
> Indeed. We must make sure to communicate this to selected contributors if we end up choosing two of them for the unit test migration projects.
>
> On a related note, I think I could help as a co-mentor the non-reftable unit tests migration project if we don't find any other willing volunteer. :-)
>
> I'm hoping I should be of some help on guiding the contributor as a co-mentor. Feel free to let me correct me if I might potentially lack required knowledge.

Thanks a lot for volunteering to co-mentor with me! I think you don't
need any special knowledge and you will be very helpful as usual.

> >> > That said, how helpful would it be to link the following doc in the unit
> >> > testing related ideas?
> >> >
> >> > https://github.com/git/git/blob/master/Documentation/technical/unit-tests.txt
> >>
> >> Makes sense to me.
> >
> >To me too.
> >
> >> > Would it worth linking the reftable technical doc for the above ideas?
> >> >
> >> > https://git-scm.com/docs/reftable
> >> >
> >> > I could see it goes into a lot of detail. I'm just wondering if link to it
> >> > would help someone who's looking to learn about reftable.
> >>
> >> Definitely doesn't hurt.
> >
> >I agree.
>
> Thanks for the feedback. Included both of these links in relevant ideas too. Feel free to cross-check them!

Great, thanks!

Re: [PATCH] Add ideas for GSoC 2024

[Patrick Steinhardt]

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

On Mon, Feb 05, 2024 at 05:43:17PM +0100, Christian Couder wrote:
> On Mon, Feb 5, 2024 at 9:39 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > Add project ideas for the GSoC 2024.
> > ---
> >
> > I came up with four different topics:
> >
> >   - The reftable unit test refactorings. This topic can also be squashed
> >     into the preexisting unit test topics, I wouldn't mind. In that case
> >     I'd be happy to be a possible mentor, too.
> >
> >   - Ref consistency checks for git-fsck(1). This should be rather
> >     straight forward and make for an interesting topic.
> >
> >   - Making git-bisect(1)'s state more self-contained as recently
> >     discussed. This topic is easy to implement, but the backwards
> >     compatibility issues might require a lot of attention.
> >
> >   - Implementing support for reftables in the "dumb" HTTP protocol. It's
> >     quite niche given that the dumb protocol isn't really used much
> >     nowadays anymore. But it could make for an interesting project
> >     regardless.
> >
> > It's hard to estimate for me whether their scope is either too small or
> > too big. So please feel free to chime in and share your concerns if you
> > think that any of those proposals don't make much sense in your opinion.
> 
> Thanks a lot for these ideas! I have applied your patch and pushed it.
> 
> I have a few concerns though, see below.
> 
> >  SoC-2024-Ideas.md | 129 ++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 129 insertions(+)
> >
> > diff --git a/SoC-2024-Ideas.md b/SoC-2024-Ideas.md
> > index 3efbcaf..286aea0 100644
> > --- a/SoC-2024-Ideas.md
> > +++ b/SoC-2024-Ideas.md
> > @@ -39,3 +39,132 @@ Languages: C, shell(bash)
> >  Possible mentors:
> >  * Christian Couder < <christian.couder@gmail.com> >
> >
> > +### Convert reftable unit tests to use the unit testing framework
> > +
> > +The "reftable" unit tests in "t0032-reftable-unittest.sh"
> > +predate the unit testing framework that was recently
> > +introduced into Git. These tests should be converted to use
> > +the new framework.
> > +
> > +See:
> > +
> > +  - this discussion <https://lore.kernel.org/git/cover.1692297001.git.steadmon@google.com/>
> > +
> > +Expected Project Size: 175 hours or 350 hours
> > +
> > +Difficulty: Low
> 
> "Difficulty: Low" might not be very accurate from the point of view of
> contributors. I think it's always quite difficult to contribute
> something significant to Git, and sometimes more than we expected.

That's certainly true. I understood the difficulty levels here as being
relative to the already-high bar that the Git project typically sets.
Otherwise there wouldn't be much use to specify difficulty in the first
place if all items had the same difficulty.

Or is the intent of the difficulty level rather on a global GSoC level?
In that case I agree that we should bump the difficulty to "medium".

> > +Languages: C, shell(bash)
> > +
> > +Possible mentors:
> > +* Patrick Steinhardt < <ps@pks.im> >
> > +* Karthik Nayak < <karthik.188@gmail.com> >
> > +
> > +### Implement consistency checks for refs
> > +
> > +The git-fsck(1) command is used to check various data
> > +structures for consistency. Notably missing though are
> > +consistency checks for the refdb. While git-fsck(1)
> > +implicitly checks some of the properties of the refdb
> > +because it uses its refs for a connectivity check, these
> > +checks aren't sufficient to properly ensure that all refs
> > +are properly consistent.
> > +
> > +The goal of this project would be to introduce consistency
> > +checks that can be implemented by the ref backend. Initially
> > +these checks may only apply to the "files" backend. With the
> > +ongoing efforts to upstream a new "reftable" backend the
> > +effort may be extended.
> > +
> > +See:
> > +
> > +  - https://lore.kernel.org/git/6cfee0e4-3285-4f18-91ff-d097da9de737@rd10.de/
> > +  - https://lore.kernel.org/git/cover.1706601199.git.ps@pks.im/
> > +
> > +Expected Project Size: 175 hours or 350 hours
> > +
> > +Difficulty: Medium
> > +
> > +Languages: C, shell(bash)
> > +
> > +Possible mentors:
> > +* Patrick Steinhardt < <ps@pks.im> >
> > +* Karthik Nayak < <karthik.188@gmail.com> >
> > +
> > +### Refactor git-bisect(1) to make its state self-contained
> > +
> > +The git-bisect(1) command is used to find a commit in a
> > +range of commits that introduced a specific bug. Starting a
> > +bisection run creates a set of state files into the Git
> > +repository which record various different parameters like
> > +".git/BISECT_START". These files look almost like refs
> > +due to their names being all-uppercase. This has led to
> > +confusion with the new "reftable" backend because it wasn't
> > +quite clear whether those files are in fact refs or not.
> > +
> > +As it turns out they are not refs and should never be
> > +treated like one. Overall, it has been concluded that the
> > +way those files are currently stored is not ideal. Instead
> > +of having a proliferation of files in the Git directory, it
> > +was discussed whether the bisect state should be moved into
> > +its own "bisect-state" subdirectory. This would make it more
> > +self-contained and thereby avoid future confusion. It is
> > +also aligned with the sequencer state used by rebases, which
> > +is neatly contained in the "rebase-apply" and "rebase-merge"
> > +directories.
> > +
> > +The goal of this project would be to realize this change.
> > +While rearchitecting the layout should be comparatively easy
> > +to do, the harder part will be to hash out how to handle
> > +backwards compatibility.
> > +
> > +See:
> > +
> > +  - https://lore.kernel.org/git/Za-gF_Hp_lXViGWw@tanuki/
> 
> From reading the discussion it looks like everyone is Ok with doing
> this. I really hope that we are not missing something that might make
> us decide early not to do this though.

I agree that this is a risky one, and that's what I tried to bring
across with the "harder part will be to hash out how to handle backwards
compatibility". Overall I think this project will be more about selling
the patch and reasoning about how it can be done without breaking
backwards compatibility.

We could bump the difficulty to high to reflect that better. But if you
deem the risk to be too high then I'm also happy to drop the topic
completely.

Patrick

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

Re: [PATCH] Add ideas for GSoC 2024

[Christian Couder]

On Tue, Feb 6, 2024 at 6:47 AM Patrick Steinhardt <ps@pks.im> wrote:
> On Mon, Feb 05, 2024 at 05:43:17PM +0100, Christian Couder wrote:

> > "Difficulty: Low" might not be very accurate from the point of view of
> > contributors. I think it's always quite difficult to contribute
> > something significant to Git, and sometimes more than we expected.
>
> That's certainly true. I understood the difficulty levels here as being
> relative to the already-high bar that the Git project typically sets.

I am not sure potential contributors are aware of the high bar that
the Git project typically sets.

> Otherwise there wouldn't be much use to specify difficulty in the first
> place if all items had the same difficulty.
>
> Or is the intent of the difficulty level rather on a global GSoC level?

Yeah, I think it makes more sense to consider it like this.

> In that case I agree that we should bump the difficulty to "medium".

Yeah, I think we should bump it to "medium".

> > From reading the discussion it looks like everyone is Ok with doing
> > this. I really hope that we are not missing something that might make
> > us decide early not to do this though.
>
> I agree that this is a risky one, and that's what I tried to bring
> across with the "harder part will be to hash out how to handle backwards
> compatibility". Overall I think this project will be more about selling
> the patch and reasoning about how it can be done without breaking
> backwards compatibility.
>
> We could bump the difficulty to high to reflect that better. But if you
> deem the risk to be too high then I'm also happy to drop the topic
> completely.

I think we can keep this topic with a "Medium" difficulty. Perhaps it
will actually not be very difficult if all goes well.

Yeah, it may seem strange, but I think unless we start to have
projects not related much to our code base, like perhaps projects
related to our web sites or some infrastructure or the Git Rev News or
our docs, I think most projects should have a "Medium" difficulty. We
might want to use "High" sometimes if we want to discourage
contributors unless they have some special background related to the
specific topic (like multi-threading for example if we had related
projects).

Re: Git in GSoC 2024

[Christian Couder]

Hi Kaartic, Patrick, Karthik and all,

On Sat, Feb 3, 2024 at 12:41 PM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:
> On 01/02/24 15:08, Patrick Steinhardt wrote:
> > On Wed, Jan 31, 2024 at 11:27:13PM +0530, Kaartic Sivaraam wrote:
> >>
> >> I created a fairly rough SoC ideas page for now including a barebones
> >> information about the unit test migration idea:
> >>
> >> https://git.github.io/SoC-2024-Ideas/

Thanks for creating the page!

I have just applied the patch Patrick sent to the mailing list with
the ideas related to reftable.

> >> Note well that the existing idea's description is far from complete and I
> >> mostly just cooked it up to serve as a template for how the idea entry could
> >> look like. Kindly contribute towards elaborating the same :-)
> >>
> >> Also, feel free to suggest ideas you have around refs and reftable backed,
> >> Patrick. Those would be helpful.
> >
> > I'll have a the beginning of next week and will think about topics
> > meanwhile.
> >
>
> Thanks, Patrick! It would be great if you could share the same as soon
> as possible. The deadline for applying to GSoC is Feb 6 (18:00 UTC) and
> we need the ideas page to be decent enough before we go ahead with
> applying for this year.
>
> If the elaborate project description could take time, feel free to share
> a paragraph or two that are supplemented with a few references. That
> should be sufficient for applying to GSoC.

Yeah, we need a decent idea page, but it doesn't need to be finalized.
I think we can still make changes after the deadline (which is for the
Open Source Orgs to apply).

> Christian,
>
> It would be great if you could look into and improve the detail for the
> unit test migration idea. I just added a very terse description based on
> what I could get my hands on. If you think the description we used for
> the Outreachy round would do, kindly update the page with the same or
> kindly share it here so that I could update the same in the ideas page :-)

The project description for Outreachy was not very elaborate and is
now quite outdated. I have instead improved the project description in
the Ideas page.

> > Yeah, as long as there is a co-mentor that can take over during my
> > absence I'm happy to do it. Karthik said that he'd be willing to cover
> > me, which I think would be a good fit given that he's already got quite
> > a bit of exposure to the reftable backend internally at GitLab. Thanks!
>
> Sounds good. Thank you for volunteering to co-mentor, Karthik!

Yeah, thank you Patrick and Karthik!

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Christian,

On 05/02/24 22:37, Christian Couder wrote:
> Hi Kaartic, Patrick, Karthik and all,
> 
> Thanks for creating the page!
> 
> I have just applied the patch Patrick sent to the mailing list with
> the ideas related to reftable.
> 

Thank you! I've now successfully submitted the application for Git using 
the Ideas page we have :-)

Let's hope that we get selected this year. We should know about that by 
February 21 - 18:00 UTC.

> Yeah, we need a decent idea page, but it doesn't need to be finalized.
> I think we can still make changes after the deadline (which is for the
> Open Source Orgs to apply).
> 

Indeed. Let's see if we could get any new ideas / potential mentors for 
this GSoC :-]

>> Christian,
>>
>> It would be great if you could look into and improve the detail for the
>> unit test migration idea. I just added a very terse description based on
>> what I could get my hands on. If you think the description we used for
>> the Outreachy round would do, kindly update the page with the same or
>> kindly share it here so that I could update the same in the ideas page :-)
> 
> The project description for Outreachy was not very elaborate and is
> now quite outdated. I have instead improved the project description in
> the Ideas page.
> 

That's great. Thanks!

-- 
Sivaraam

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hello Christian, Patrick, Karthik and all,

On 06/02/24 00:09, Kaartic Sivaraam wrote:
> Hi Christian,
>
> On 05/02/24 22:37, Christian Couder wrote:
>> Hi Kaartic, Patrick, Karthik and all,
>>
>> Thanks for creating the page!
>>
>> I have just applied the patch Patrick sent to the mailing list with
>> the ideas related to reftable.
>>
>
> Thank you! I've now successfully submitted the application for Git using
> the Ideas page we have :-)
>
> Let's hope that we get selected this year. We should know about that by
> February 21 - 18:00 UTC.
>

I think it's time we start being prepared for potential contributors who
are interested in contributing to Git via GSoC. ;-)

On a more important note, we need to assign Org Admins and mentors for
the 2024 program. For now, I'm the only Org Admin for the 2024 program.

Christian, could you do the following so that I could add you as an Org
Admin for the 2024 program?

"Visit https://g.co/gsoc site, click on the 2024 bar which will display
the 2024 Program Rules and Org Member agreement, read and agree to the
same."

For mentors, as Patrick and Karthik are new to the program, we need to
invite them first and only after they've accepted the invitation can we
add them to the program.

Karthik, I was able to get your Gmail address and have sent an invite to
you. Could you accept the same after reading through the program rules
and member agreement?

Patrick, could you kindly share with me your Gmail address so that I could
invite you to the program?

--
Sivaraam

PS: Apologies if you've got this email multiple times. My email client has not
yet been able to deliver the message to the list. So, I'm trying other ways to
get it done. Sorry for the noise.

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Wed, Feb 21, 2024 at 10:32:25AM +0530, Kaartic Sivaraam wrote:
> Hello Christian, Patrick, Karthik and all,
> 
> On 06/02/24 00:09, Kaartic Sivaraam wrote:
> > Hi Christian,
> >
> > On 05/02/24 22:37, Christian Couder wrote:
> >> Hi Kaartic, Patrick, Karthik and all,
> >>
> >> Thanks for creating the page!
> >>
> >> I have just applied the patch Patrick sent to the mailing list with
> >> the ideas related to reftable.
> >>
> >
> > Thank you! I've now successfully submitted the application for Git using
> > the Ideas page we have :-)
> >
> > Let's hope that we get selected this year. We should know about that by
> > February 21 - 18:00 UTC.
> >
> 
> I think it's time we start being prepared for potential contributors who
> are interested in contributing to Git via GSoC. ;-)
> 
> On a more important note, we need to assign Org Admins and mentors for
> the 2024 program. For now, I'm the only Org Admin for the 2024 program.
> 
> Christian, could you do the following so that I could add you as an Org
> Admin for the 2024 program?
> 
> "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> the 2024 Program Rules and Org Member agreement, read and agree to the
> same."
> 
> For mentors, as Patrick and Karthik are new to the program, we need to
> invite them first and only after they've accepted the invitation can we
> add them to the program.
> 
> Karthik, I was able to get your Gmail address and have sent an invite to
> you. Could you accept the same after reading through the program rules
> and member agreement?
> 
> Patrick, could you kindly share with me your Gmail address so that I could
> invite you to the program?

You can use my GitLab mail address for this: psteinhardt@gitlab.com.
Thanks for handling the administrative parts, and happy to hear that the
Git project has been accepted.

Patrick

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

Re: Git in GSoC 2024

[Christian Couder]

Hi Kaartic,

On Wed, Feb 21, 2024 at 6:02 AM Kaartic Sivaraam
<kaartic.sivaraam@gmail.com> wrote:

> Christian, could you do the following so that I could add you as an Org
> Admin for the 2024 program?

Yeah, sure.

> "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> the 2024 Program Rules and Org Member agreement, read and agree to the
> same."

Done. My status is now "Accepted", but yeah I think you need to add me
to the GSoC 2024 program now.

> For mentors, as Patrick and Karthik are new to the program, we need to
> invite them first and only after they've accepted the invitation can we
> add them to the program.

Thanks for inviting them!

Re: Git in GSoC 2024

[Karthik Nayak]

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

Hello,

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

> Hello Christian, Patrick, Karthik and all,
> Karthik, I was able to get your Gmail address and have sent an invite to
> you. Could you accept the same after reading through the program rules
> and member agreement?
>

I confirm the same, and have signed up.

Thanks for handling everything here.

- Karthik

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

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Christian, Patrick, Karthik and all,

On 21/02/24 10:32, Kaartic Sivaraam wrote:
> 
> Christian, could you do the following so that I could add you as an Org
> Admin for the 2024 program?
> 
> "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> the 2024 Program Rules and Org Member agreement, read and agree to the
> same."
> 
> For mentors, as Patrick and Karthik are new to the program, we need to
> invite them first and only after they've accepted the invitation can we
> add them to the program.
> 
> Karthik, I was able to get your Gmail address and have sent an invite to
> you. Could you accept the same after reading through the program rules
> and member agreement?
> 
> Patrick, could you kindly share with me your Gmail address so that I could
> invite you to the program?
> 

Thanks for the quick turnaround all! I've added all of you to the 2024 
program. I hope you're able to access the program page at [1]. Let me 
know if you're facing any issues.

Also, it's official now. Git has been selected as one of the 
participating organizations[2] in GSoC 2024!

Let's look forward towards a summer with great GSoC contributors who 
hopefully become continued contributors to the community :-)

[[ References ]]

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

[2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git

-- 
Sivaraam

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> Hi Christian, Patrick, Karthik and all,
> 
> On 21/02/24 10:32, Kaartic Sivaraam wrote:
> > 
> > Christian, could you do the following so that I could add you as an Org
> > Admin for the 2024 program?
> > 
> > "Visit https://g.co/gsoc site, click on the 2024 bar which will display
> > the 2024 Program Rules and Org Member agreement, read and agree to the
> > same."
> > 
> > For mentors, as Patrick and Karthik are new to the program, we need to
> > invite them first and only after they've accepted the invitation can we
> > add them to the program.
> > 
> > Karthik, I was able to get your Gmail address and have sent an invite to
> > you. Could you accept the same after reading through the program rules
> > and member agreement?
> > 
> > Patrick, could you kindly share with me your Gmail address so that I could
> > invite you to the program?
> > 
> 
> Thanks for the quick turnaround all! I've added all of you to the 2024
> program. I hope you're able to access the program page at [1]. Let me know
> if you're facing any issues.
> 
> Also, it's official now. Git has been selected as one of the participating
> organizations[2] in GSoC 2024!
> 
> Let's look forward towards a summer with great GSoC contributors who
> hopefully become continued contributors to the community :-)
> 
> [[ References ]]
> 
> [1]:
> https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
> 
> [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git

I can access the second link, but the first one is broken for me. First
it claimed that my Google account wasn't connected to GSoC, and after a
reload it stays blank now.

Patrick

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

Re: Git in GSoC 2024

[Karthik Nayak]

On Thu, Feb 22, 2024 at 8:49 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> > [1]:
> > https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
> >
> > [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
>
> I can access the second link, but the first one is broken for me. First
> it claimed that my Google account wasn't connected to GSoC, and after a
> reload it stays blank now.
>

Both links seem to be working now for me.

Re: Git in GSoC 2024

[Christian Couder]

On Thu, Feb 22, 2024 at 9:57 AM Karthik Nayak <karthik.188@gmail.com> wrote:
>
> On Thu, Feb 22, 2024 at 8:49 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> > > [1]:
> > > https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
> > >
> > > [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
> >
> > I can access the second link, but the first one is broken for me. First
> > it claimed that my Google account wasn't connected to GSoC, and after a
> > reload it stays blank now.
> >
>
> Both links seem to be working now for me.

Both links are working for me too.

Thanks!

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Patrick, Karthik, Christian and all,


On 22 February 2024 1:19:42 pm IST, Patrick Steinhardt <ps@pks.im> wrote:
>On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
>> Hi Christian, Patrick, Karthik and all,
>> 
>> On 21/02/24 10:32, Kaartic Sivaraam wrote:
>> 
>> Also, it's official now. Git has been selected as one of the participating
>> organizations[2] in GSoC 2024!
>> 
>> Let's look forward towards a summer with great GSoC contributors who
>> hopefully become continued contributors to the community :-)
>> 
>> [[ References ]]
>> 
>> [1]:
>> https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
>> 
>> [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
>
>I can access the second link, but the first one is broken for me. First
>it claimed that my Google account wasn't connected to GSoC, and after a
>reload it stays blank now.
>

That's strange. Could you possibly try logging into the Summer of code website [3] directly in an incognito window using your GitLab account?

I've previously faced issues with logging into the summer of code website due to an add-on blocking access to other Google domains. So, if you have add-ons that might block resources accessed by the website, could you possibly try disabling them?

If you face issues despite all this, the only resort is to write to GSoC support about this issue at gsoc-support@google.com

[3]: https://summerofcode.withgoogle.com/

Hope this helps,
Sivaraam

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

Re: Git in GSoC 2024

[Patrick Steinhardt]

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

On Thu, Feb 22, 2024 at 07:35:33PM +0530, Kaartic Sivaraam wrote:
> Hi Patrick, Karthik, Christian and all,
> 
> 
> On 22 February 2024 1:19:42 pm IST, Patrick Steinhardt <ps@pks.im> wrote:
> >On Thu, Feb 22, 2024 at 10:01:54AM +0530, Kaartic Sivaraam wrote:
> >> Hi Christian, Patrick, Karthik and all,
> >> 
> >> On 21/02/24 10:32, Kaartic Sivaraam wrote:
> >> 
> >> Also, it's official now. Git has been selected as one of the participating
> >> organizations[2] in GSoC 2024!
> >> 
> >> Let's look forward towards a summer with great GSoC contributors who
> >> hopefully become continued contributors to the community :-)
> >> 
> >> [[ References ]]
> >> 
> >> [1]:
> >> https://summerofcode.withgoogle.com/organizations/git/programs/2024/timeline
> >> 
> >> [2]: https://summerofcode.withgoogle.com/programs/2024/organizations/git
> >
> >I can access the second link, but the first one is broken for me. First
> >it claimed that my Google account wasn't connected to GSoC, and after a
> >reload it stays blank now.
> >
> 
> That's strange. Could you possibly try logging into the Summer of code website [3] directly in an incognito window using your GitLab account?
> 
> I've previously faced issues with logging into the summer of code website due to an add-on blocking access to other Google domains. So, if you have add-ons that might block resources accessed by the website, could you possibly try disabling them?
> 
> If you face issues despite all this, the only resort is to write to GSoC support about this issue at gsoc-support@google.com
> 
> [3]: https://summerofcode.withgoogle.com/
> 
> Hope this helps,
> Sivaraam

Things work now after a re-login. Kinda strange, but so be it. Thanks!

Patrick

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

Re: Git in GSoC 2024

[Kaartic Sivaraam]

Hi Patrick, Karthik and Christian

On Thu, Feb 22, 2024 at 9:22 PM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Thu, Feb 22, 2024 at 07:35:33PM +0530, Kaartic Sivaraam wrote:
> > Hi Patrick, Karthik, Christian and all,
> >
> >
> > That's strange. Could you possibly try logging into the Summer of code website [3] directly in an incognito window using your GitLab account?
> >
> > I've previously faced issues with logging into the summer of code website due to an add-on blocking access to other Google domains. So, if you have add-ons that might block resources accessed by the website, could you possibly try disabling them?
> >
> > If you face issues despite all this, the only resort is to write to GSoC support about this issue at gsoc-support@google.com
> >
> > [3]: https://summerofcode.withgoogle.com/
>
> Things work now after a re-login. Kinda strange, but so be it. Thanks!
>

That's good to know! So, I suppose we're all set with adding Org Admins
and mentors for this year :-)

Just in case anyone hasn't come across it before, there are a few good
resources related to GSoC mentorship that Google has put up:

Google Summer of Code Mentor Guide [mentor-guide]

Mentor Roles and Responsibilities [mentor-responsibilities]

Feel free to check them out.

[[ References ]]

[mentor-guide]: https://google.github.io/gsocguides/mentor/index

[mentor-responsibilities]:
https://developers.google.com/open-source/gsoc/help/responsibilities#mentor_responsibilitie

-- 
Sivaraam