Re: To save or not to save

["Zeeshan Ali (Khattak)" <zeeshanak gnome org>]

On Mon, Nov 19, 2012 at 12:47 PM, Daniel P. Berrange
<berrange redhat com> wrote:
> On Fri, Nov 16, 2012 at 03:55:11PM +0200, Zeeshan Ali (Khattak) wrote:
>> On Fri, Nov 16, 2012 at 2:15 PM, Lucas Meneghel Rodrigues
>> <lmr redhat com> wrote:
>> > On 11/15/2012 03:49 PM, Zeeshan Ali (Khattak) wrote:
>> >>
>> >> Mostly just thinking aloud here (hence this email rather than patches
>> >> on bz)! Ideas?
>> >
>> >
>> > I was wondering why you guys use this workflow rather than the most common
>> > 'patches to mailing list' approach... Wouldn't be more beneficial to have
>> > the patches sent to the ML?
>>
>> Thats a big debate and I have never seen anyone getting convinced
>> either way around. :) To each his own I guess, both approaches has its
>> advantages and disadvantages. The main advantages of bz to me are:
>>
>> * you can easily track status of the patches at both patch level and
>> issue/bug/topic-level.
>> * you can easily setup dependencies
>> * Get nice reports and even graphs of whats been happening with the project
>>
>> git-bz makes working with bz pretty convenient and the issues people
>> have with bz are usually bugs/improvements in bz software that are
>> fixable, not exactly problems with the approach of using bz itself.
>
> The single most important part of patch submission process is the actual
> code review. More specifically the abilities wrt quoting parts of the
> submitted patch, giving inline comments on its issues,

That is very much possible with splinter. There is some bugs i think
related to that but as i said, bugs can be fixed. Not at all a problem
with the approach.

> and the ability of
> others to follow these replies in a threaded manner.

For the conversations on one patch, that works pretty well with
splinter. The conversation "breaks" once you submit a patch to
obselete a another but I don't think that is very bad since patches
are still on the same bug and can easily be tracked through the
comments. I have to do that all the time: Oh elmarco submitted a new
version of the patch, hold on a min! what were my comments on the
previous one.

> This is where BZ
> really falls flat, even for regular bug reporting conversations. Tracking
> status / dependencies / reports are all nice things to do,

Thats where we have different tastes. Tracking status / dependencies /
reports are not just nice but pretty essential IMO, a lot more
important than having all versions of patches and all comments/replies
on it in one thread.

> but they are
> ultimately secondary to the task of doing code review.

Code reviews are very much possible with bugzilla. We've been doing
that in gnome for a while now.

> The use of mailing
> lists optimizes for the most important aspects, and BZs advantages cannot
> anywhere near make up for its shortcomings in this area.

You are entitled to your opinions of course. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124