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
prev parent 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).