On Sun, Mar 11, 2012 at 12:09:39PM -0400, Paul Gortmaker wrote: > On Sun, Mar 11, 2012 at 8:48 AM, Mark Brown > > On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote: > >> This is caused by commit 19694b5ea1d3 which just appeared in today's next > >> tree exposing another implicit device.h user. Just a quick note that I'll > >> take care of it by adding regmap.c to the below commit. > > relied on here. You've gone and deleted that inclusion without CCing > > the patch to the subsystem and now you're sending a fix again without a > > CC to either me or the relevant list, and without even a mention in the > > subject line. > We are talking about a trivial fix here, and the deletion was one of about > fifty similar one-line deletions in include/linux, of which many files don't > even have clear owners. So, while I can appreciate you wanting a CC, > it just wasn't practical in this case in my opinion. The above doesn't just apply to the original patch, it applies even more strongly to the followup patch where none of the above issues apply. Honestly I do think that if you made at least some effort to let subsytem maintainers know about all this header reorganisation you're doing you'd introduce a lot less breakage, it's hardly surprising that people keep on developing with the headers they can see. > > In order to avoid bisection breakage I've applied one of the several > > fixes for this that were sent to me today, please drop your change. > I don't see how this avoids any bisection breakage -- you've now introduced > a dependency that wasn't there before -- i.e. I would have to make sure > your change is present before my changes get pulled. In any case I can > just ensure I have the exact same change as you and it will make sure > my series remains bisectable. It will be fine, there's no dependency. If regmap is merged first there's obviously no issue as it doesn't have your header faffing in. If regmap is merged second then the branch that gets pulled will have Stephen's change applied to it before it gets Linus' tree so no commit will exist where we've only got your commit which introduces the problem and no fix. On the other hand an incremental fix in your tree only means that if your tree is merged second there will be at least one commit which is broken. This applies to any fixups for the fallout from your changes, except in very rare circumstances adding the extra includes is always going to be safe in any tree and this means that people working in the tree can see what's going to be happening, making things less error prone. > > This stuff would go a lot more smoothly if you were to at least let > > people know when you make changes, especially when issues introduced by > > your changes get noticed. > I've worked to get at least three different regulator regression fixes in, > None of those were related to any changes I made. You were on the > to/CC of those fixes, and I even made changes as you requested. My > point is that I do my best to follow implicit and explicit processes. If > you've somehow come to conclude otherwise, I'm sorry to hear that. If you'd CCed me when you noticed the additional breakage from your change or you'd written followups to the people submitting fixes normally which said something like "This is due to more header reorganisations I've done, I've fixed it on my branch see X for details" things would've worked better. As it is I was seeing fixes from people which made no sense given the recent activity in the tree plus followups from you which had no content other than links (which isn't good practice) to a message which itself just references git changes things by hash (which is quite bad, commit IDs aren't directly legible and can change) and had to faff around with the logs to figure out what you'd done.
Attachment:
signature.asc
Description: Digital signature
