grub-devel
[Top][All Lists]
Advanced

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

Re: GNU GRUB maintenance


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: GNU GRUB maintenance
Date: Fri, 9 Oct 2015 14:14:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.2.0

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
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
c) No integration with continous testing systems

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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