[Toaster] Unable to rebase

[Barros Pena, Belen]

On 30/01/2014 10:42, "Richard Purdie" <richard.purdie at linuxfoundation.org>
wrote:

>On Thu, 2014-01-30 at 10:23 +0000, Barros Pena, Belen wrote:
>> I'll try to speed up the review process. The problem I have is that, in
>>my
>> experience, it pays off to fix as many issues as possible before merging
>> to a master branch (toaster/master in our case). The moment code is
>>merged
>> to master, it seems to become necessary to raise issues using the bug
>> tracking system, which results in the number of issues ballooning up. I
>> don't have a problem with that, but people having to fix the issues
>>might
>> find it difficult to decide what to do first: fixing problems from
>> previous features or tackling new features.
>> 
>> I am copying everybody because this is very much a process problem: it
>> would be good to hear what everybody else thinks.
>
>FWIW, my take on this is that:
>
>There is no hard requirement to have a bug open against an issue in
>master. In particular, if you find an issue and have a fix which gets
>sent out quickly, there is no point in taking the process overhead of
>opening the bug only to close it again.
>
>Equally, if there is a bug found in master and you don't have an
>immediate fix, we do prefer to open bugs to ensure the issue does not
>get forgotten about.

This makes sense, but it requires knowledge of how long it will take to
fix the problem. Developers know that. Me, well, I'm afraid I don't, since
I don't fix them myself. Also, I need to keep track of things being done
by several developers simultaneously. Without some kind of formal help
(i.e. a bug tracking system) that becomes an impossible task.

If it's any consolation, this is not a trivial problem. Nobody really
knows how to handle the design review process in the context of open
source development. The only solution I've found to work well is working
very closely with developers to get issues raised and fixed before
submitting patches to be merged. This requires willingness to co-operate
and a lot of patience on the developers' side. Building GUIs is an
iterative process: it will be never be right on the first try, it won't be
right on the second try either. It's just the nature of the work. I wish I
had a magic bullet for this, but I guess that if I did I would be going
around the world telling everybody about it instead of building Toaster ;)

I am happy to organise review calls instead of giving feedback in writing:
that might speed up things.

If anybody else has any other suggestions, let me know.

Belén

>
>Cheers,
>
>Richard
>