Hi Dominique, On Mon, Aug 7, 2023 at 1:12 PM Dominique Pellé <dominique.pe...@gmail.com> wrote: > > Yegappan Lakshmanan wrote: > > > Hi all, > > > > I am listing the tasks that Bram used to do for developing and maintaining > > Vim below (as far I can remember): > > > > 1. Developing fixes for Vim crash reports including the analysis of > > fuzzy test files. > > 2. Addressing reported security vulnerabilities including those reported > > in https://huntr.dev/repos/vim/vim. I think various Linux > > distribution maintainers report these issues directly to Bram. > > 3. Fixing Coverity warnings reported in > > https://scan.coverity.com/projects/vim > > 4. Fixing CI build breakages including ASAN errors. > > 5. Create patches based on pull requests from Vim contributors > > (including updating the patches to match the Vim coding style and > > perform minor refactoring). > > 6. Developing major new features (e.g. Vim9 script, virtual text, etc.) > > 7. Reproducing the reported issues and developing fixes for those > > issues. > > 8. Improving the test infrastructure. For example, he recently > > incorporated coding style checks and the support for syntax > > highlighting checks. > > 9. Incorporating the runtime file updates (e.g. syntax files, file > > types, etc.) > > 10. Updating the Vim documentation based on discussions and pull > > requests. > > 11. Maintaining the todo.txt file to track the roadmap for features and > > fixes. > > 12. Responding to questions and discussions in the Vim-dev mailing list. > > 13. Updating the vim.org website with news. > > 14. Preparing and making Vim releases (maybe once a year). > > > > Regards, > > Yegappan > > Thanks Yegappan for this list. > > About point #2 i.e. "Addressing reported security > vulnerabilities including those reported in https://huntr.dev/repos/vim/vim"; > I never looked at this, as I thought only Bram had > access to bug reported there for security reasons. > But if I can have access (?) I would be interested in: > - minimizing crash fuzzing POC > - and attempting to fix them >
I am able to view all the reports and the discussions. Are you able to view them? > > About point #9 i.e. "Incorporating the runtime file updates" > I've always found it odd that some changes were split into > a commit in src and another commit later in runtime. It > often caused confusion, with PR author asking "part of > my change was not included?!" and the response being > "it will be in the next runtime update". Perhaps that's > something worth revisiting? > Yes. I think we should move the PR model for the runtime file updates. Regards, Yegappan > In fact, this happened to my last PR at > https://github.com/vim/vim/pull/12544/files > where only part of it was merged and the > remaining part was meant to be in the next > runtime update, which sadly never happened. > I'll create a PR when I have time for what went > missing. > > There might also be other unrelated changes > which were pending in the next runtime update > that never happened. Often Bram responded > with "I'll include it" when people reported > corrections to the docs for example. > > Regards > Dominique > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7kxatPYJDCCo4wE2LW8PTSUjcbEZWX2_FDuC6bR4nfKKA%40mail.gmail.com.
