On October 9, 2015 8:14:39 AM EDT, "Vladimir 'φ-coder/phcoder' Serbinenko" <phco...@gmail.com> wrote: >On 08.10.2015 21:34, Konrad Rzeszutek Wilk wrote: >> On October 8, 2015 10:52:25 AM EDT, Andrei Borzenkov ><arvidj...@gmail.com> wrote: >>> On Thu, Oct 8, 2015 at 12:14 AM, Vladimir 'φ-coder/phcoder' >Serbinenko >>> <phco...@gmail.com> wrote: >>>> Hello, all. I'm sorry for not being available to do enough >>> maintenance >>>> for GRUB in last time but I was overbooked. Yet there is a good >news. >>> At >>>> Google there is a 20% project and GRUB has been approved as 20% >>> project >>>> for me. The goal is to have 2.02 released before the end of this >>> year. >>>> Other than the raw lack of time there is another issue which makes >>>> maintenance difficult: inefficient VCS. >>> >>> VCS is actually OK. The project of size Linux kernel seems to work >>> well using pull request e-mails. The disadvantages are >>> >>> - contributors must have repository available via Internet >> >> >> That is quite easy nowadays. And you can always ask for signed tags >if you are worried about repos being subverted. >> >>> - contributors are trusted to actually submit pull request for >branch >>> that was reviewed >> >> >> <blinks> >> >> It is a disadvantage to trust people!? >> >> >>> - it needs to be done locally and pushed >> >> >> Or you can have different maintainers pushing the patches in if they >are Acked or Reviewed. >> >> Meaning the committee does not have to be the same person who >reviews/acks it. >> >>> >>>> It requires >me >>> or someone with >>>> privileges manually copy the patch. What other systems would be ok? >>> It >>>> obviously has to be a free software and hosted on free >>> software-friendly >>>> hosting. It also has to have an efficient 1-click merge (so that >>> someone >>>> with privileges can get any patch submitted to the system merged in >>>> couple of clicks). >>>> >>>> >> >> Clicks? That sounds like a GUI thing. And it sounds like you need to >have an admin to set it up, patch it occasionally, deal with spammers, >etc. >> >> What is wrong with the old mechanism of emails. >> >It takes too much effort to: >a) Track if there are any unresolved issues
Isn't that the job of the folks submitting the patches? >b) It takes non-trivial amount of effort to commit once it's reviewed: >you need to copy patch from mail client to git, do commit, copy >description and so on Huh? 'git am' takes your patches in mbox format and commits them in. With description and all. I just save the emails from the mail client and then apply them all in one go with 'git am -s'. >c) No integration with continuous testing systems There is no continuous testing at all now. But if you want - the 0-day build system picks up emails posted on LKML and compiles them to at least test that are compilable. > > > >------------------------------------------------------------------------ > >_______________________________________________ >Grub-devel mailing list >Grub-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
