Messages in this thread | | | Date | Tue, 2 Mar 2010 11:01:37 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 00/15] oprofile fixes and updates for v2.6.34 |
| |
* Robert Richter <robert.richter@amd.com> wrote:
> On 27.02.10 10:03:31, Ingo Molnar wrote: > > Hm, the perf_event.c bits conflict quite heavily with pending changes in > > tip:perf/core. > > > > So to not hold up the oprofile changes for v2.6.34 i've pulled the core > > oprofile changes for v2.6.34 into tip:oprofile (up to cfc9c0b, if that is fine > > with you), and mind reworking the last 3 patches against perf/core? > > Ingo & Peter, > > I have a rebased version containing also a merge from: > > tip/oprofile -> tip/perf/core > > Please pull again from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git core
Pulled, thanks Robert!
> > On a related note, wrt. your ongoing work for perf IBS support. The following > > patch by Peter: > > > > f22f54f: perf_events, x86: Split PMU definitions into separate files > > Yes, the patches went also upstream on Friday. Will update my current patch > stack now. Maybe it would have been better to first integrate all pending > patches before doing that split. Conflict resolution is a pain for moving > code. But anyway, it is supposed to go upstream and I will rebase my > patches.
The way to do it is to not keep that many pending patches in the first place. There are always 'pending patches' - if we waited for them to drain then we could never do cleanups.
Peter, Arnaldo, Frederic and all the other perf developers sync their patches with perf/core very frequently and push these bits to me. This has various advantages:
- breakages are discovered quickly and can be mitigated before more harm is done.
- patch review is a lot more gradual (and a lot less taxing) as well.
- other people can get interested and jump in and help you out.
- design mistakes/disagreements can also be hashed out before too much work is invested into a particular direction.
- as a maintainer i can see progress and can see problem areas. This makes it much easier to judge and plan a new topic's upstream integration schedule. It's not tucked away in some tree, with a large stream of patches showing up at once.
i.e. it's all variations of the 'release early, release often' Linux mantra.
So if you have a significant amount of pending patches then you are doing something wrong. Please consider adapting your workflow and please get any pending pieces to us in small, reviewable pieces.
That's especially true of large, intrusive features: for example the IBS bits could be moved into perf/core gradually, in a series of clean steps, even if they are not functional yet.
Thanks,
Ingo
| |