Satyam Zode:
> As far as my research till now is concerned. Brief timeline looks like:
> Design and Experiment:
> 1)  During the application screening:(March 26 - April 22)
>  1.1) Acquaint myself with diffoscope and research about proposed features.
>  1.2) Get hands-on experience with diffoscope.
>  1.3) Set up the development environment.
>  1.4) Track changes to the project roadmap in a publicly accessible document.
>  1.5) Design relevant project design and discuss project design with a
> community.
> 2) Community Bonding Period: (April 23 - May 10)
>   2.1) Interact with the community and exchange information related to
> project design and working of diffoscope in different conditions.
>   2.2) Finalizing design and documenting same in the project design wiki.
>   2.3) Learning more about Debian community.

During that period I think it would be worthwhile to review packages and
if there's one you see an easy fix, submit patches. That way you would
get better insights on the various issues and diffoscope limitations.

> Implementation:
> Official coding period.
> 3) Week 1 - 2 (May 27 - June 9):
>   - Work on  "Allow users to ignore arbitrary differences" part.
>   - Work simultaneously on unreproducible packages.

How much time are you going to give to the community so they can review
your proposed user interfaces?

> 4) Week 3 - 4 (June 10 - June 22):
>   - Work on Parallel processing part.
>   - Work simultaneously on unreproducible packages.

This is unlikely to work. Implementing parallel processing requires
deep focus because it's also about adding missing locks and
understanding subtle concurrency issues.

How much experience do you have with concurrent programming?
I think you underevaluate how hard this is to get right. To the very
least you shoud be entirely focused on this and not fixing packages at
the same time.

> ------------------------------- Mid-Term Evaluations
> --------------------------------
> 5) Week 5 - 7 (June 23 - July 13):
>    - Finish remaining work
>    - Start working on fuzzy matching algorithm.
> 6) Week 8 - 10 (July 14 - August 3):
>   - Finish fuzzy matching algorithm implementation.
>   - Work on new file-format comparators.

diffosope already supports fuzzy matching via TLSH. It's implemented and
works nicely. But it only does inside a container. That means it will
not notice when you compare foo.gz and foo.xz that foo might actually be
the same file. Three weeks for that feels like too much.

>  7) Week 11 (August 4 - August 13):
>   - Write tests for implemented features and comparators.

Big no here. Tests should be written prior or during the development of
the various features. While the code coverage has never been 100%, at
least the basics should be covered. So please refine the timeline by
making enough room to write tests during the development.

>   - keep working on unreproducible Debian packages.
> Documentation:
>  8)  Week 12 (August 15 - August 22): Suggested pencils down date
>   - Code refactoring.
>   - Finish documentation.

What kind of code refactoring are you thinking about?

What kind of documentation are you thinking about? Like tests, user
documentation should be written at the same time or maybe prior as the
actual features.

Sorry if this starts to feel annoying, but I'd like to avoid us making
mistakes that I've seen several times in the past with other GSoC.

Lunar                                .''`.                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 

Attachment: signature.asc
Description: Digital signature

Reproducible-builds mailing list

Reply via email to