Satyam Zode: > I have written project proposal (application) for the same. I kindly > request you to review the application [1]. I need your valuable > feedback and suggestions. I will consider it to improve an > application. > [1]: https://wiki.debian.org/SummerOfCode2016/StudentApplications/SatyamZode
Thanks for your application. I much appreciated that it's done before the deadline. I also like you being clear of your other commitments. I think it would have been fine application for last summer, but we've made significant progress on several fronts since, therefore I'm not convinced that there's much work left in the tasks your propose. I think it would be better to aim with more precise tasks, e.g. toolchain software you'll be improving to solve classes of issues, or at leas an outline the features you intend to add to strip-nondeterminism or diffoscope. (If you feel you're part of the reproducible builds team and disagree with my comments, please say so!) If you look at packages identified as leaving timestamps in gzip headers, you'll see that most of them already have patches, and the ones who don't are affected with other issues: https://tests.reproducible-builds.org/issues/unstable/timestamps_in_gzip_headers_issue.html These other issues probably deter maintainers' motivation to fix the problems with gzip timestamps. Almost all packages with varying mtimes in data.tar or control.tar have patches or have been fixed through toolchain improvements: https://tests.reproducible-builds.org/issues/unstable/varying_mtimes_in_data_tar_gz_or_control_tar_gz_issue.html It feels quite suboptimal to highlight user and groups in tarballs as separate issues as I think all are affected by other tarball related issues. They should be fixed at the same time: https://tests.reproducible-builds.org/issues/unstable/users_and_groups_in_tarball_issue.html Regarding timestamps due to C pre-processor macros, Dhole is waiting for GCC patch window to open again—which will be in April, IIRC. So unless you intend to work on adding support for SOURCE_DATE_EPOCH in clang, I'm not sure there's much work left on this issue. I believe that fixing the 400+ packages individually should not be undertaken if we can avoid it. https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01402.html https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros Emmanuel Bourg has been working and fixing almost all Java-related issues in the course of the past year. I expect he'll probably work on this fixing locale related javadoc issue in a near future. I guess you could coordinate with him to write the necessary patches, though. https://tests.reproducible-builds.org/issues/unstable/locale_in_documentation_generated_by_javadoc_issue.html These quick evaluations leave me the feeling that your proposed schedule is currently not adequate with actual needs of the reproducible builds effort. This probably means that progress can be made on making more visible areas that actually require work… -- Lunar .''`. [email protected] : :Ⓐ : # apt-get install anarchism `. `'` `-
signature.asc
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
