git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Hariom verma <hariom18599@gmail.com>
To: Zhang Yi <18994118902@163.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com
Subject: Re: [GSOC] [PROPOSAL v1] Draft of proposal for "Unify ref-filter formats with other pretty formats"
Date: Wed, 29 Mar 2023 17:53:24 +0530	[thread overview]
Message-ID: <CA+CkUQ_7BDmX73epbAaUsz3fXaNcHXR4H6xQ-nyGV81YAYRbcQ@mail.gmail.com> (raw)
In-Reply-To: <4cb30507.79cd.18728e9ee58.Coremail.18994118902@163.com>

Hi

On Tue, Mar 28, 2023 at 9:20 PM Zhang Yi <18994118902@163.com> wrote:
>
> Hi, there is a my first versoin of proposal for "Unify ref-filter formats with other
> pretty formats". There may be many backwards. I'm ready for the correction.
>
> Thanks for your attention.
>
> * Unify ref-filter formats with other pretty formats
>
> * Personal Information
>
> Full name: Zhang Yi
>
> E-mail: 18994118902@163.com
> Tel: (+86)18994118902
>
> Education: Wuhan University of Technology (China)
> Major: Computer engineering
> Year: First-year postgraduate student
>
> Github: https://github.com/zhanyi22333

Okay.

> * Synopsis
>
> Git has at least four implements to format command output, which makes chaos and
> hinder improvement of code quality.
>
> Aim to unify the different implementations to format output for different
> commands, we want to transform pretty into ref-filter formatting logic. According
> In the present situation, I need to add more ref-filter atoms to replace
> pretty.
>
> In my mind, there are 6 steps logically:
> 1. Check and find a pretty atom which has no substitute in ref-filter.
> 2. Add reasonable test scripts and maybe documents in advance.
> 3. Build a ref-filter atom and its arguments to replace a pretty atom.
> 4. Make a translation between pretty formats and ref-filter arguments.
> 5. Modify the pretty code to ref-filter logic.
> 6. Recheck documents and run test scripts.

I would like to see more details here. Maybe you can explain every
step you mentioned in detail.
You can also include how much work has been done and what's left.

> * Benefits to Community
>
> I'm willing to stay around after the project. By that time, I will be in my
> second year without classes. And my tutor has an open mind about my request to
> invovle in an open source project by now. Consider the subjective and objective
> conditions, I think there is a high possibility that I will stay around.

s/invovle/involve
s/Consider/Considering

> Particularly, I wish to be a co-mentor if I have the ability. There may be some
> difficulties. But what I learn from my finite experience is that you should not
> refuse something positive just because of the difficulties in the mind. The
> fresh new job may be difficult, but it can show me the possibilities of the
> world, which means change my mind.
>
> What's more, I tried to persuade a schoolmate who I think is kind of obsessed
> with technology to take part in an open source community for both self-growth and
> companion. And I failed, because he thinks it is hard.  It's always hard to
> change Others' deep-rooted ideas by word. But I think the actions speak louder
> than words. Maybe after the project, I can change the minds of people around me
> about joining an open source community. There may be no visual benefits to the
> community of git but should be beneficial to the whole open source community.

s/community of git/Git Community

> * Microproject
>
> t9700: modernize test scripts [1]
>
> The microproject patches have been merged. The merge info is as below:
>
> commit 8760a2b3c63478e8766b7ff45d798bd1be47f52d
> Merge: a2d2b5229e 509d3f5103
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Tue Feb 28 16:38:47 2023 -0800
>
>     Merge branch 'zy/t9700-style'
>
>     Test style fixes.
>
>     * zy/t9700-style:
>       t9700: modernize test scripts

Great.

> * Plan
>
> ** Deliverables
>
> 1. Documents.
> 2. Test scripts.
> 3. Modified ref-filter.
>    3.1.  New atom and arguments
>    3.2. New functions like foo_atom_parser, grab_foo
>    3.3. modified functions like grab_values and static struct.
> 4. Modified pretty which is plugged in by ref-filter.
>
> ** Timeline and feasibility
>
> It seems impossible for me to estimate the time consumed. The idea page [2]
> shows the expected time is between 175 hours and 350 hours. So I checked the
> timeline of GSOC, It shows that the official code time starts from 05-29 to
> 08-28 and can be extended to 11-06. After that I check my class schedule.
> The conclusion is as below:
>
> 1. now~06-05: around 2~3 classes every week. It is easy to cover the time
> project needs.
> 2. 06-05~06-30: There are many classes on workdays. Hope I can take classes with
> flexibility.
> 3.  After 06-30: This semester is finished.
>
> I think it is a bit time-limited if I follow the official timeline. It seems
> necessary to do some work in advance.

Can you merge "Deliverables" and "Timeline"?
Please make a detailed timeline. It can be weekly or monthly depending on you.

> * Related work
>
> The blog by Hariom Verma shows the outline of the work.[3]
>
> This proposal draft benefits from Nsengiyumva Wilberforce’s recent work [4]
> much. Thanks.

Maybe it's a good idea to include what you grasped from related work.
A brief synopsis?

> * Biograhical information
>
> It is always funny to recall that I first learned about Linux in a stimulated
> hacker game in my fresh year in college. After that, I tried to teach myself
> Linux and started to know open source projects. Overcome many difficulties and I
> finally know something shallow about Linux. As a side effect, I am more
> enthusiastic and better at programming compared with my schoolmates. But the
> period of stagnation came, I began to write some meaningless projects for school
> tasks and repeated myself without progress. The best out of the worst, I touched
> excellent open source software during the time, such as vim, emacs, visual
> studio code, Qt, VLC and, of course, git. Near the end of my junior year, I read
> an article about learning by contributing to an open source project by a geek
> in the community of emacs. Almost at the same time, I knew the GSOC and preferred
> to take part in git. But it was near the start date of my plan for postgraduate
> qualifying examination. So I just postponed the stuff for GSOC.  Luckily, I
> passed the examination. After I got used to life as a postgraduate student, I
> felt the motivation to progress again. Then I tried to contribute for git. Now I
> just finish a micro project, which seems trivial. But it really let me have a
> deeper understanding of open source and free software and more motivation to
> contribute. I hope I can stay a long time here before being involved with other
> interesting projects since the quality is more important than the quantity.
> I know it seems a bit stubborn to believe that contributing will lead to
> progress, which is also influenced by my learning attitude. But without action,
> I can not verify the belief.  Sooat least I will try to contribute for one year.
> After that, I hope I can have a better understanding.
>
> Sorry, the above text may be messing. In short, I will try to contribute for
> git for at least one year.
>
> * Closing remarks
>
> Thanks for Christian Couder's help.
>
> [1] https://lore.kernel.org/git/20230222040745.1511205-1-18994118902@163.com/
> [2] https://git.github.io/SoC-2023-Ideas/
> [3] https://harry-hov.github.io/blogs/posts/the-final-report
> [4] https://lore.kernel.org/git/pull.1452.git.1672102523902.gitgitgadget@gmail.com/

Thank you for your proposal. I left a few comments.

Regards,
Hariom

      reply	other threads:[~2023-03-29 12:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 15:50 [GSOC] [PROPOSAL v1] Draft of proposal for "Unify ref-filter formats with other pretty formats" Zhang Yi
2023-03-29 12:23 ` Hariom verma [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+CkUQ_7BDmX73epbAaUsz3fXaNcHXR4H6xQ-nyGV81YAYRbcQ@mail.gmail.com \
    --to=hariom18599@gmail.com \
    --cc=18994118902@163.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).