Re: Unable to rebase

Re: Unable to rebase

[Barros Pena, Belen]

On 29/01/2014 19:28, "Lerner, Dave" <dave.lerner@windriver.com> wrote:

>Hi Alex, Belen
>
>After Alex's push upstream and a local rebase, it seems that I will have
>to go through a third major rebase effort.
>
>I would like my next push to be quickly added upstream so that I don't
>have to churn on rebasing once again.

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.

Cheers

Belén

>
>Thanks,
>Dave 

Re: Unable to rebase

[Richard Purdie]

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.

Cheers,

Richard

Re: Unable to rebase

[Barros Pena, Belen]

On 30/01/2014 10:42, "Richard Purdie" <richard.purdie@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
>

Re: Unable to rebase

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Dave,

I'm gonna try to make the rebase painless, with a new toaster/master push.

I am aware of this rebase work, so I'm suggesting that any minor fixes can
be open as bugs instead of holding up the review process.

So I propose that we do the merging today, since you'll ping me in the
morning your time anyway.

Does this sound ok to you ?

Alex


On Thu, Jan 30, 2014 at 10:23 AM, Barros Pena, Belen <
belen.barros.pena@intel.com> wrote:

>
>
> On 29/01/2014 19:28, "Lerner, Dave" <dave.lerner@windriver.com> wrote:
>
> >Hi Alex, Belen
> >
> >After Alex's push upstream and a local rebase, it seems that I will have
> >to go through a third major rebase effort.
> >
> >I would like my next push to be quickly added upstream so that I don't
> >have to churn on rebasing once again.
>
> 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.
>
> Cheers
>
> Belén
>
> >
> >Thanks,
> >Dave
>
>


-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 2691 bytes --]