Re: [PATCH lttng-ust] Add trace instrumentation for some pthread functions.

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Stefan Seefeld (stefan_seefeld@mentor.com) wrote:
> On 08/07/2013 12:12 PM, Mathieu Desnoyers wrote:
> 
> > The difference with pthread instrumentation is that it's really a new
> > feature in every possible sense of the term: new kind of library
> > functions are instrumented, new problems may arise, new files are added,
> > new shared objects are added. This is exactly what we don't want to add
> > during rc.
> 
> I fully agree.
> 
> > Please note that as soon as you get my acked-by, you can consider this
> > patch accepted. It's just that we don't have the staging branches to
> > keep them around, nor the manpower to maintain a 3rd branch in parallel
> > with the current stable+rc.
> > 
> > Thoughts ?
> 
> I understand if it makes things easier for you as maintainer if you ask
> contributors to do the rebase before their (approved) patches are to be
> merged. But your wording seemed to suggest that I should resend the
> actual patch, not regenerate it after rebasing to a future master, which
> confused me as in that case I'd need to keep around a free-floating
> patch that is neither version-controlled nor archived.

I'm OK with contributors rebasing a patch before resubmission, of
course. However, if the rebase required any change at all to the patch,
the "acked-by" tags should be removed, and the fact that it's been
accepted and then rebased (with changes) should be pointed out in the
changelog, ideally with a quick summary of the changes required for the
rebase. This should make the merge process quick and straightforward,
without risks of us missing an issue introduced by the rebase.

Does it make sense ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com