grub-devel
[Top][All Lists]
Advanced

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

Re: GNU GRUB maintenance


From: Konrad Rzeszutek Wilk
Subject: Re: GNU GRUB maintenance
Date: Fri, 09 Oct 2015 20:30:01 -0400
User-agent: K-9 Mail for Android

On October 9, 2015 8:14:39 AM EDT, "Vladimir 'φ-coder/phcoder' Serbinenko" 
<address@hidden> wrote:
>On 08.10.2015 21:34, Konrad Rzeszutek Wilk wrote:
>> On October 8, 2015 10:52:25 AM EDT, Andrei Borzenkov
><address@hidden> wrote:
>>> On Thu, Oct 8, 2015 at 12:14 AM, Vladimir 'φ-coder/phcoder'
>Serbinenko
>>> <address@hidden> 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
>address@hidden
>https://lists.gnu.org/mailman/listinfo/grub-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]