Re: [GSoC] Re: Info: git log --oneline improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 24, 2018 at 4:15 AM Christian Couder
<christian.couder@xxxxxxxxx>
wrote:

> Hi,

> On Sat, Mar 24, 2018 at 9:41 AM, Pratik Karki <predatoramigo@xxxxxxxxx>
wrote:
> >
> > Hi Christian and Johannes,
> >
> > Though I sent a mail earlier, saying I would like to submit another
> > proposal, I am now skeptical on re-writing another proposal as you
> > guys are only available mentor for GSoC

Is there a place/email where I can read up on the git log --oneline
improvements? I use the --oneline flag a lot and would be interested
in hearing what you plan there.

> Well Stefan Beller wrote in


https://public-inbox.org/git/CAGZ79kax5Hip1wP3U60im__Dm0GvH8nNd+ByxG5OxMXrRkRvdQ@xxxxxxxxxxxxxx/

> that he would be ok to co-mentor, but I am not sure which projects he
> would be ok to co-mentor. I just Cc'ed him so he can tell us more.

I would be happy to co mentor any project by prioritizing some
review time on it.

Regarding rewriting shell scripts in C,
there have been GSoC students in the previous years, which may help you
understand the scope of the project better.

     git clone --mirror https://public-inbox.org/git
     git clone https://git.kernel.org/pub/scm/git/git.git/

and search via "git log --author=" for
Paul Tan, who converted git-am and git-pull into C
or Prathamesh Chavan, who rewrote git-submodule
to be in C, but the result is not upstream (yet).

I think there are more shell to C conversions, but I was involved
with these 2, hence giving these examples.

> > and I believe Git doesn't
> > select more than 2 proposals.

> Yeah, because mentoring is a lot of work, and doesn't always work out
> as well as we would expect, (mostly because it is difficult to explain
> to new contributors that review cycles for significant patch series
> take a lot more time than they could imagine), so not many people
> volunteer to mentor or co-mentor.

I agree on this. Mentoring takes some time as well.
The coding part is the easy part, the communication part with
the community is the harder part.

For example the Git community is spread across all time zones.
So if you want to give everyone the opportunity to give input to
your patches you want to wait 2 hours.

The community consists of people with diverse backgrounds, e.g.
some work on Git in their spare time on the weekends [only]. Others
work on it as their job [so it is rather a Mon-Fri activity]; others glance
at the mailing list in the lunch break or in the evenings.

These timing issues are not the hardest part,
but the easiest to explain shortly. ;)

> I still hope though that over time some former GSoC student will
> become (co-)mentors as this happens quite often in other projects that
> participates in the GSoC.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux