From: Taylor Blau <hidden> Date: 2021-09-03 02:40:50
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
Christian, Peff, and I discussed off-list that we would each try to pull
together funding for one intern from GitHub and GitLab respectively.
If we're interested, the project submission deadline is September 23rd
[1]. By then, we'd need:
- Volunteers to act as mentors
- Updates to our applicant materials on git.github.io (project ideas,
as well as potential microprojects).
Thanks,
Taylor
[1]: https://www.outreachy.org/docs/community/#current-timeline
On Thu, Sep 2, 2021 at 7:41 PM Taylor Blau [off-list ref] wrote:
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
Christian, Peff, and I discussed off-list that we would each try to pull
together funding for one intern from GitHub and GitLab respectively.
If we're interested, the project submission deadline is September 23rd
[1]. By then, we'd need:
- Volunteers to act as mentors
I'd be happy to mentor actively during the application stage, but I
don't have bandwidth to host/mentor an accepted intern this term. I
would also be happy to be CC'd, pinged, and so on on any reviews from
interns which aren't receiving enough love.
- Updates to our applicant materials on git.github.io (project ideas,
as well as potential microprojects).
Will bring this up with Google folks today and see if we've got any ideas.
Thanks for mentioning it, Taylor.
From: Christian Couder <hidden> Date: 2021-09-04 04:30:26
On Fri, Sep 3, 2021 at 4:40 AM Taylor Blau [off-list ref] wrote:
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
Christian, Peff, and I discussed off-list that we would each try to pull
together funding for one intern from GitHub and GitLab respectively.
Yeah, and we submitted an initial community application.
If we're interested, the project submission deadline is September 23rd
[1]. By then, we'd need:
- Volunteers to act as mentors
I am ok with co-mentoring 2 interns.
- Updates to our applicant materials on git.github.io (project ideas,
as well as potential microprojects).
About microprojects, I have been wondering if there are run_command*()
calls that could be replaced by direct calls to C functions like what
Junio did in ffcb4e94d3 (bisect: do not run show-branch just to show
the current commit, 2021-07-27), and if that could make a good
microproject.
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
From: ZheNing Hu <hidden> Date: 2021-09-04 07:40:54
Hi,
Christian Couder [off-list ref] 于2021年9月4日周六 下午12:30写道：
On Fri, Sep 3, 2021 at 4:40 AM Taylor Blau [off-list ref] wrote:
quoted
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
Christian, Peff, and I discussed off-list that we would each try to pull
together funding for one intern from GitHub and GitLab respectively.
Yeah, and we submitted an initial community application.
quoted
If we're interested, the project submission deadline is September 23rd
[1]. By then, we'd need:
- Volunteers to act as mentors
I am ok with co-mentoring 2 interns.
quoted
- Updates to our applicant materials on git.github.io (project ideas,
as well as potential microprojects).
About microprojects, I have been wondering if there are run_command*()
calls that could be replaced by direct calls to C functions like what
Junio did in ffcb4e94d3 (bisect: do not run show-branch just to show
the current commit, 2021-07-27), and if that could make a good
microproject.
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :) I can help them as a mentor.
This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.
If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.
The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded to take
advantage of multi-core.
These ideas may be very difficult to implement now.
[1]: https://lore.kernel.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@mail.gmail.com/
[2]: https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/
[3]: https://github.com/adlternative/git/commits/cat-file-reuse-ref-filter-logic
Thanks.
--
ZheNing Hu
From: Jeff King <hidden> Date: 2021-09-04 12:50:05
On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.
If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.
The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded to take
advantage of multi-core.
I don't think trying to thread it will help much. For expensive formats,
where we have to actually open and parse objects, in theory we could do
that in parallel. But most of our time there is spent in zlib getting
the object data, and that all needs to be done under a big lock.
For little formats (e.g., just printing "%(refname)"), we need to
serialize the output anyway. So our unit of work is so tiny, I suspect
that the threading overhead would be a net negative.
I was coincidentally looking at ref-filter last week, and it seemed to
me that a lot of the slowness is because of the over-use of malloc
(e.g., we allocate a substring for every atom_value, and then form them
into a separate buffer). If we could parse the original format into a
form that could be traversed without having to do further allocations,
just writing directly to a strbuf (or even a file handle), I think that
would be a big improvement.
I just posted the results of some of my experiments to the list:
https://lore.kernel.org/git/YTNpQ7Od1U%2F5i0R7@coredump.intra.peff.net/
I don't think that gives any kind of useful base to build on, but it
shows what's possible by skipping past various segments of the
ref-filter code.
-Peff
From: Taylor Blau <hidden> Date: 2021-09-04 17:51:52
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
- Updates to our applicant materials on git.github.io (project ideas,
as well as potential microprojects).
One project I have been thinking of is a grab-bag of bitmap-related
tasks. Some ideas for general improvements are:
- Designing a new .bitmap format (perhaps using the new chunkfile
API?) to allow us to add optional data to it in the future, like any
information we might need for a stable object order.
- Experimenting with replacing EWAH with different bitmap compression
algorithms to see if we can increase read performance and/or
decrease file size.
- Tidy up and take measurements from my RFC patch(es) to add an
extension which indicates which commits have bitmaps, and at what
position. These were discussed beginning at:
https://lore.kernel.org/git/YNuiM8TR5evSeNsN@nand.local/
(but they seem to help most when there isn't too much traversal
required between the ref tips and the bitmapped commits).
- Rethinking bitmap selection to be more robust against repositories
which have "spikey" ref tips and for which follow-on traversal is
expensive.
These are all fairly open-ended, and so may not make a good Outreachy
project. But I would be in favor of having more people familiar with and
interested in reachability bitmaps.
I'll think of some others, too.
Thanks,
Taylor
From: ZheNing Hu <hidden> Date: 2021-09-05 08:59:12
Jeff King [off-list ref] 于2021年9月4日周六 下午8:50写道：
On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
quoted
This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.
If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.
The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded to take
advantage of multi-core.
I don't think trying to thread it will help much. For expensive formats,
where we have to actually open and parse objects, in theory we could do
that in parallel. But most of our time there is spent in zlib getting
the object data, and that all needs to be done under a big lock.
This big lock is "obj_read_lock()", right? If there are indeed the limitations
of these locks, I am afraid that the parallel scheme is not good.
For little formats (e.g., just printing "%(refname)"), we need to
serialize the output anyway. So our unit of work is so tiny, I suspect
that the threading overhead would be a net negative.
Make sence.
I was coincidentally looking at ref-filter last week, and it seemed to
me that a lot of the slowness is because of the over-use of malloc
Agree. malloc() and data-copy is the reason for the poor performance of
ref-filter.
(e.g., we allocate a substring for every atom_value, and then form them
into a separate buffer). If we could parse the original format into a
form that could be traversed without having to do further allocations,
just writing directly to a strbuf (or even a file handle), I think that
would be a big improvement.
I just posted the results of some of my experiments to the list:
https://lore.kernel.org/git/YTNpQ7Od1U%2F5i0R7@coredump.intra.peff.net/
I don't think that gives any kind of useful base to build on, but it
shows what's possible by skipping past various segments of the
ref-filter code.
-Peff
On Sun, Sep 5, 2021 at 5:59 AM ZheNing Hu [off-list ref] wrote:
Jeff King [off-list ref] 于2021年9月4日周六 下午8:50写道：
quoted
On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
quoted
This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.
If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.
The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded to take
advantage of multi-core.
I don't think trying to thread it will help much. For expensive formats,
where we have to actually open and parse objects, in theory we could do
that in parallel. But most of our time there is spent in zlib getting
the object data, and that all needs to be done under a big lock.
This big lock is "obj_read_lock()", right?
The object reading code actually releases this lock before doing zlib
decompression (and acquires it right after), to allow better
multi-threaded performance.
However, it is unfortunately not so simple to call object reading
routines in multi-threaded code, even with this lock. The lock mainly
protects `oid_object_info_extended()` and its wrappers. Some global
resources used by these functions are also accessed outside of them,
which could lead to race conditions in threaded code.
That's why `builtin/grep.c` and `grep.c` have some explicit calls to
`obj_read_lock()` outside `object-file.c` and `packfile.c`. (And it
can be quite tricky to identity these cases.)
On Sun, Sep 5, 2021 at 5:59 AM ZheNing Hu [off-list ref] wrote:
quoted
Jeff King [off-list ref] 于2021年9月4日周六 下午8:50写道：
quoted
On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
quoted
This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.
If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.
The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded to take
advantage of multi-core.
I don't think trying to thread it will help much. For expensive formats,
where we have to actually open and parse objects, in theory we could do
that in parallel. But most of our time there is spent in zlib getting
the object data, and that all needs to be done under a big lock.
This big lock is "obj_read_lock()", right?
The object reading code actually releases this lock before doing zlib
decompression (and acquires it right after), to allow better
multi-threaded performance.
Yeah, I guess this unlock place is in unpack_loose_short_header().
However, it is unfortunately not so simple to call object reading
routines in multi-threaded code, even with this lock. The lock mainly
protects `oid_object_info_extended()` and its wrappers. Some global
resources used by these functions are also accessed outside of them,
which could lead to race conditions in threaded code.
That's why `builtin/grep.c` and `grep.c` have some explicit calls to
`obj_read_lock()` outside `object-file.c` and `packfile.c`. (And it
can be quite tricky to identity these cases.)
Indeed, a large number of global variables in ref-filter code are worth
eliminating.
Thanks.
--
ZheNing Hu
From: Taylor Blau <hidden> Date: 2021-09-18 16:10:44
[+everybody from upthread to cc]
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
If you are interested in mentoring, the time to sign-up and propose a
project is definitely ASAP :-). You can do so by clicking "Submit a
project proposal" at:
https://www.outreachy.org/communities/cfp/git/
Thanks,
Taylor
From: ZheNing Hu <hidden> Date: 2021-09-20 07:45:33
Taylor Blau [off-list ref] 于2021年9月19日周日 上午12:10写道：
[+everybody from upthread to cc]
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
quoted
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
If you are interested in mentoring, the time to sign-up and propose a
project is definitely ASAP :-). You can do so by clicking "Submit a
project proposal" at:
https://www.outreachy.org/communities/cfp/git/
I haven't thought of any good projects for the time being,
Christian, any ideas?
From: Christian Couder <hidden> Date: 2021-09-20 14:52:54
On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu [off-list ref] wrote:
Taylor Blau [off-list ref] 于2021年9月19日周日 上午12:10写道：
quoted
[+everybody from upthread to cc]
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
quoted
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
If you are interested in mentoring, the time to sign-up and propose a
project is definitely ASAP :-). You can do so by clicking "Submit a
project proposal" at:
https://www.outreachy.org/communities/cfp/git/
I haven't thought of any good projects for the time being,
Christian, any ideas?
I already suggested the following project upthread:
quoted
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
and you replied:
If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :) I can help them as a mentor.
so I am ok to co-mentor this project with you.
If you are still ok, I will submit it.
I will also prepare soon a page with a few micro-projects. Of course
more micro-project and regular project ideas are very welcome!
From: Christian Couder <hidden> Date: 2021-09-20 15:15:29
On Mon, Sep 20, 2021 at 4:52 PM Christian Couder
[off-list ref] wrote:
I will also prepare soon a page with a few micro-projects. Of course
more micro-project and regular project ideas are very welcome!
So here is the page:
https://git.github.io/Outreachy-23-Microprojects/
It's very similar as last year's page
(https://git.github.io/Outreachy-21-Microprojects/). The differences
are:
- added new "Replace a run_command*() call by direct calls to C functions" idea
- removed "Unify the meaning of -dirty between diff and describe" idea
as it looks a bit complex for a micro-project (though I can add it
back if someone disagree with this opinion).
From: ZheNing Hu <hidden> Date: 2021-09-21 05:39:56
Christian Couder [off-list ref] 于2021年9月20日周一 下午10:52写道：
On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu [off-list ref] wrote:
quoted
Taylor Blau [off-list ref] 于2021年9月19日周日 上午12:10写道：
quoted
[+everybody from upthread to cc]
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
quoted
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
If you are interested in mentoring, the time to sign-up and propose a
project is definitely ASAP :-). You can do so by clicking "Submit a
project proposal" at:
https://www.outreachy.org/communities/cfp/git/
I haven't thought of any good projects for the time being,
Christian, any ideas?
I already suggested the following project upthread:
quoted
quoted
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
and you replied:
quoted
If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :) I can help them as a mentor.
so I am ok to co-mentor this project with you.
If you are still ok, I will submit it.
Yeah, I am ok. grateful.
I will also prepare soon a page with a few micro-projects. Of course
more micro-project and regular project ideas are very welcome!
I am still looking at the code in ref-filter.c these two days, I deeply
doubt whether we can add a --no-sort option to git for-each-ref,
Inspired by Peff's experimental patches [1], I think the --no-sort option
may improve the performance of ref-filter by avoiding the execution
of ref_array_sort().
I don't know if this can be regarded as a micro-project.
This may require the help of this patch of mine: [2]
which use list api for ref_sorting. This may can help eliminate unnecessary
sorting.
[1] https://lore.kernel.org/git/YTTC2IUO1ZmTOEoR@coredump.intra.peff.net/
[2] https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/
Thanks.
--
ZheNing Hu
It's very similar as last year's page
(https://git.github.io/Outreachy-21-Microprojects/). The differences
are:
- added new "Replace a run_command*() call by direct calls to C functions" idea
- removed "Unify the meaning of -dirty between diff and describe" idea
as it looks a bit complex for a micro-project (though I can add it
back if someone disagree with this opinion).
From: Christian Couder <hidden> Date: 2021-09-21 15:35:19
On Tue, Sep 21, 2021 at 7:39 AM ZheNing Hu [off-list ref] wrote:
Christian Couder [off-list ref] 于2021年9月20日周一 下午10:52写道：
quoted
On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu [off-list ref] wrote:
quoted
quoted
I haven't thought of any good projects for the time being,
Christian, any ideas?
I already suggested the following project upthread:
quoted
quoted
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
and you replied:
quoted
If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :) I can help them as a mentor.
so I am ok to co-mentor this project with you.
If you are still ok, I will submit it.
I am still looking at the code in ref-filter.c these two days, I deeply
doubt whether we can add a --no-sort option to git for-each-ref,
Inspired by Peff's experimental patches [1], I think the --no-sort option
may improve the performance of ref-filter by avoiding the execution
of ref_array_sort().
I don't know if this can be regarded as a micro-project.
If you think that such a patch is likely to be accepted and that would
take you less than a few hours to prepare and submit, then it can
probably be regarded as a micro-project, and you are welcome to send a
pull request to add it to the micro-project page.
I think the number is not linked to the year but rather to the number
of Outreachy rounds since the beginning.
Last year's Winter round was round 21 and there has been a Summer
round we didn't participate in, so I think the Winter 2021-2022 is
round 23.
But yeah, it might be clearer to rename all the Outreachy files with
names like Outreachy-Winter-21-22-Microprojects to avoid such
confusion, as I think the round number is not used much anymore by
anyone.
From: Taylor Blau <hidden> Date: 2021-09-21 21:26:04
On Sat, Sep 18, 2021 at 12:10:40PM -0400, Taylor Blau wrote:
On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
quoted
Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
It looks like the deadline was extended to September 29th at 4pm UTC. So
we have a little less than an extra week. The below link is still the
right place to submit proposals:
https://www.outreachy.org/communities/cfp/git/
Thanks,
Taylor
From: ZheNing Hu <hidden> Date: 2021-09-22 14:59:11
Christian Couder [off-list ref] 于2021年9月21日周二 下午11:35写道：
On Tue, Sep 21, 2021 at 7:39 AM ZheNing Hu [off-list ref] wrote:
quoted
Christian Couder [off-list ref] 于2021年9月20日周一 下午10:52写道：
quoted
On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu [off-list ref] wrote:
quoted
quoted
quoted
I haven't thought of any good projects for the time being,
Christian, any ideas?
I already suggested the following project upthread:
quoted
quoted
About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.
and you replied:
quoted
If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :) I can help them as a mentor.
so I am ok to co-mentor this project with you.
If you are still ok, I will submit it.
I am still looking at the code in ref-filter.c these two days, I deeply
doubt whether we can add a --no-sort option to git for-each-ref,
Inspired by Peff's experimental patches [1], I think the --no-sort option
may improve the performance of ref-filter by avoiding the execution
of ref_array_sort().
I don't know if this can be regarded as a micro-project.
If you think that such a patch is likely to be accepted and that would
take you less than a few hours to prepare and submit, then it can
probably be regarded as a micro-project, and you are welcome to send a
pull request to add it to the micro-project page.
Eh, It may not be simple, I can try to solve it by myself first, but I
think it is
appropriate for novices to complete this mini-project to understand the
technical details of ref-filter.
I think the number is not linked to the year but rather to the number
of Outreachy rounds since the beginning.
Last year's Winter round was round 21 and there has been a Summer
round we didn't participate in, so I think the Winter 2021-2022 is
round 23.
Ok. I thought it was related to the year before.
But yeah, it might be clearer to rename all the Outreachy files with
names like Outreachy-Winter-21-22-Microprojects to avoid such
confusion, as I think the round number is not used much anymore by
anyone.
From: Christian Couder <hidden> Date: 2021-09-29 14:18:58
Hi Taylor and all,
On Tue, Sep 21, 2021 at 11:26 PM Taylor Blau [off-list ref] wrote:
quoted
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
It looks like the deadline was extended to September 29th at 4pm UTC. So
we have a little less than an extra week. The below link is still the
right place to submit proposals:
https://www.outreachy.org/communities/cfp/git/
So the deadline for mentors to submit projects has been extended again
to Wednesday, October 6 at 4pm UTC.
We still have only one project ("Unify ref-filter formats with other
pretty formats", that ZheNing and me are willing to co-mentor)
submitted though.
I plan to submit another project that I will be willing to (co-)mentor
before the deadline.
It's confirmed that GitLab will sponsor one intern.
Best,
Christian.
From: Taylor Blau <hidden> Date: 2021-09-29 17:34:12
On Wed, Sep 29, 2021 at 04:18:43PM +0200, Christian Couder wrote:
Hi Taylor and all,
On Tue, Sep 21, 2021 at 11:26 PM Taylor Blau [off-list ref] wrote:
quoted
quoted
The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.
It looks like the deadline was extended to September 29th at 4pm UTC. So
we have a little less than an extra week. The below link is still the
right place to submit proposals:
https://www.outreachy.org/communities/cfp/git/
So the deadline for mentors to submit projects has been extended again
to Wednesday, October 6 at 4pm UTC.
Thanks for mentioning. I got an email from Sage announcing this
yesterday, but neglected to share it here.
We still have only one project ("Unify ref-filter formats with other
pretty formats", that ZheNing and me are willing to co-mentor)
submitted though.
I plan to submit and mentor a project myself. (I'm thinking that I'll do
a grab-bag of bitmap-related items that I'd like to see implemented, but
that may be too open-ended for a successful Outreachy project).
GitHub is planning on sponsoring an intern, too, but I haven't finalized
the paperwork.
Thanks,
Taylor
From: Taylor Blau <hidden> Date: 2021-09-29 20:30:52
On Wed, Sep 29, 2021 at 01:34:08PM -0400, Taylor Blau wrote:
quoted
We still have only one project ("Unify ref-filter formats with other
pretty formats", that ZheNing and me are willing to co-mentor)
submitted though.
I plan to submit and mentor a project myself. (I'm thinking that I'll do
a grab-bag of bitmap-related items that I'd like to see implemented, but
that may be too open-ended for a successful Outreachy project).
I think (open-ended as it may be) that I'll be able to provide the most
guidance for a bitmap-related project. I submitted that as a intern
project, which anybody logged in through the Outreachy site can view
here:
https://www.outreachy.org/apply/project-selection/#git
Thanks,
Taylor