[GSOC] [PROPOSAL v3] Draft of proposal for "Unify ref-filter formats with other pretty formats"

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

 



Thanks for Christian Couder's comments. I realize that I should have a deeper
understanding of this project. So I have tried related commands and read related
documents.

Improvement vs v2:
1. A re-designed plan.
2. Put section "Estimated Timeline" next to "Steps".
3. Add parts about works of Nsengiyumva Wilberforce.
4. Fix some spell mistakes.

There seems no time left for a cycle of re-draft. Could I submit this proposal?

Thanks for all comments.

* Unify ref-filter formats with other pretty formats

* Personal Information

Full name: Zhang Yi

E-mail: 18994118902@xxxxxxx
Tel: (+86)18994118902

Education: Wuhan University of Technology (China)
Major: Computer engineering 
Year: First-year postgraduate student

Github: https://github.com/zhanyi22333

*  Synopsis

** Motivation

Git has different 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
to the present situation, I may need to add more ref-filter atoms to replace
pretty. After all pretty atoms have corresponding atoms in ref-filter, we still
need to reuse ref-filter in pretty. To promise the backward compatibility, it is
better to translate a pretty formatting string to a ref-filter formatting string,
then use ref-filter's functions to complete the formatting process.


** Previous Work

  - `git for-each-ref`, `git branch` and `git tag` formats into the
ref-filter formats:

done by Karthik Nayak (GSoC 2015)

  -  `git cat-file` formats and the ref-filter formats:

started by Olga Telezhnaya (Outreachy 2017-2018),
continued by ZheNing Hu (GSoC 2021),
but still not finished due to tricky performance issues.

  - ref-filter formats and pretty formats:

tarted by Hariom Verma (GSoC 2020)
continued a bit by Jaydeep Das. (GSoC 2022)
Nsengiyumva Wilberforce continued to work on this during the time of Outreachy
and after Outreachy with persistence. His work on the "signature" atom
should be mostly over when the GSoC starts. (Outreachy 2022-2023)

Here are links to their blogs or works.
- Olga Telezhnaya: Here are Olga Telezhnaya's detailed and helpful blogs.[1]
- ZheNing Hu: There are a lot of patches which are concluded in his final
blog [2]
- Hariom Verma: There are also a lot of patches which are concluded in his final
blog [3]
- Jaydeep Das: Patch: gpg-interface: add function for converting trust level to
string [4]
- Nsengiyumva Wilberforce:Patch: ref-filter: add new atom "signature" atom [5]

** What is left

Since the work of "signature" atoms will be finished by Nsengiyumva Wilberforce,
There may be some other atoms left for ref-filter formats and pretty formats.
After I checked the documents of pretty and ref-filter, I found that the '%w' in
pretty seems has no substitute in ref-filter. And the '%m' placeholder may also
need a substitute.

** Steps

1. Try best to understand related code. It is necessary to understand the way
ref-filter works. Since the work of adding signature atom by Nsengiyumva 
Wilberforce is strongly related and latest, I think I should pay great attention.
What's more, I may need to understand how align atom works because '%w' has a
range influence and it is better to have the power to control the scale of range
with the help of "%end".
2. Add a file name which is a substitute for '%w'. The code should pass tests and
has related documents.
3. Add a file name which is a substitute for '%m'. The code should pass tests and
has related documents.
4. Recheck the correspondence between the atoms of pretty and ref-filter. There
should be none left.
5.  Work on reusing ref-filter logic in pretty, which looks like a huge project.
I need to have a good understanding on previous works about what should and
shouldn't. It seems a bit earlier for me to think about it.
(Hope I can get to this step)

** Estimated Timeline

The official GSOC code time starts from 05-29 to 08-28, which is 13 weeks.
The period from 06-05 to 06~30 is near the end of the semester. There are many
classes for me. So I guess I may not be productive during this period.
I think it is a bit time-limited if I follow the official timeline. It seems
necessary to do some work in advance.

1. Preparatory work:
 Period:
  04-01 ~ 05-28
  About 8 weeks
 Tasks:
   1. Trying to understand the formatting logic behind pretty and ref-filter.
   2. Make some trial changes to help understanding.
   3. Understand the work of Nsengiyumva Wilberforce.
   4. Figure out the way align atom works.

2. Add a new field name.
 Period:
  05-29 ~ 07-07 (include inactive period)
  Week 1~6
  6 weeks
 Tasks:
  Based on the preparatory work, write a new field name for 'w' placeholder in
  pretty. It should pass tests and be well-documented.
 Deliverables:
    A new field name for 'w' placeholder in pretty.
    Test scripts.
    Added documents.

3. Active code period 1
 Period:
  07-10 ~ 07-28
  Week 7~9
  3 weeks
 Tasks:
  Work on a new filed name to replace 'm' placeholder. Also it need to pass
  tests and be well-documented.
 Deliverables:
    A new field name for 'm' placeholder in pretty.
    Test scripts.
    Added documents.

4. Finishing touches
 Period:
  07-31 ~ 08-26
  Week 10~13
  4 weeks
 Tasks:
  If the previous estimate is over-optimistic, it is time for fault-tolerant.In
  the best condition, I should finish the two new field names. After that, I will
  recheck the correspondence between the atoms of pretty and ref-filter. If
  all preparatory work is done, I will put effort on reusing ref-filter logic in
  pretty.

* 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
involve in an open source project by now. Considering the subjective and
objective conditions, I think there is a high possibility that I will stay
around.

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. A
fresh new job may be difficult, but it can show me the possibilities of the
world, which means changing 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
Git Community but should be beneficial to the whole open source community.

* Microproject

t9700: modernize test scripts [6]

The microproject patches have been merged. The merge info is as below:

commit 8760a2b3c63478e8766b7ff45d798bd1be47f52d
Merge: a2d2b5229e 509d3f5103
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date:   Tue Feb 28 16:38:47 2023 -0800

    Merge branch 'zy/t9700-style'

    Test style fixes.

    * zy/t9700-style:
      t9700: modernize test scripts



* Grasp from related work

** From Hariom Verma's blog
Walking through the blogs of Hariom Verma, I find many things useful.

*** Debugging

An extremely informative(step-by-step) debugging guide by Christian. [7]

*** 11 questions for understanding someone's work. [8]

1. What was the goal of each patch?
2. which approach did she took to achieve the goal?
3. what were the goals of the patch series?
4. which approach did she took to achieve the goals?
5. what was the goal of her previous patch series?
6. what was the general direction her patch series were going?
7. why did she took that direction?
8. are there ways to continue in the same direction?
9. are there ways to achieve similar goals?
10. how were her goals similar and different from the goals in my proposal?
11. is it possible to use the same approach?

*** Else

There are many details about his work progress. I can refer to them when I am in
similar situations.

** From ZheNing Hu's blog

*** Time analyzing

Use performance testing tools to analyze the time-consuming steps of
`git cat-file --batch`.

 Using Google's `gperftools`:
1. Add the link parameter `-lprofiler` in `config.mak`: `CFLAGS += -lprofiler`.
2. `make`.
3. Use `CPUPROFILE=/tmp/prof.out /<path>/git cat-file --batch-check
--batch-all-objects`
to run the git and general `prof.out`, which contains the results of
performance analysis.
4. Use `pprof --text /<path>/git /tmp/prof.out` to display the result
in the terminal.

*** About Github CI

"GitHub-Travis CI hints" in Documentation/SubmittingPatches

*** Else

He also writes his process of debugging and optimization in detail. It's worth
deepening into when I need them.

This proposal draft benefits from the works of predecessors much. Thanks.

** From Olga Telezhnaia's blog

1. There is potential emotional problems related to remote works.
2. It may be a good idea to try different ways of communication.
3. I should learn needed expertise. For example, I should learn more about shell
scripts.
4. The plan may change from time to time. But I should talk about it with mentors
every 2-3 weeks to focus on the final goal and middle steps.

* 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 finished 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 here a long time 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

It seems blogs will help much for later work. I think It worth rebuilding my
blog site on github.

Thanks for Christian Couder's and Hariom Verma's help.


[1] https://medium.com/@olyatelezhnaya
[2] https://public-inbox.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@xxxxxxxxxxxxxx/
[3] https://harry-hov.github.io/blogs/posts/the-final-report
[4] https://public-inbox.org/git/pull.1281.git.1657202265048.gitgitgadget@xxxxxxxxx/
[5] https://public-inbox.org/git/pull.1452.git.1672102523902.gitgitgadget@xxxxxxxxx/#t
[6] https://lore.kernel.org/git/20230222040745.1511205-1-18994118902@xxxxxxx/
[7] https://public-inbox.org/git/CAP8UFD3Bd4Af1XZ00VyuHnQs=MFrdUufKeePO1tyedWoReRjwQ@xxxxxxxxxxxxxx/
[8] https://harry-hov.github.io/blogs/posts/week1-the-ten-questions




[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