> > > Right, and that's really fundamental, because then the user can tell you
> > > "look, this commit doesn't work for me" instead of just "this kernel
> > > doesn't work for me" and now you need to spend *your* time on trying to
> > > figure out which commit may be at fault.
> > >
> > > So speaking of benefits, I really prefer to avoid spending my time on
> > > such things. :-)
> >
> > The toss-up is between splitting the patch-set up and *maybe* spending
> > time on debugging in the small chance of this occurring OR
> > *definitely* spending time creating immutable branches and sending out
> > pull-requests in the *hope* that all the other Maintainers involved
> > are diligent enough to merge it in order to avoid conflicts during
> > merge time.
> >
> > In the circles I spend time in ("we"), the former is the favourite.
>
> This certainly depends on the complexity. For a small patchset,
> merging in a shot is often a safer option. That is, when all parties
> agree, you can just apply all patches to your branch -- that's all.
> Other parties can simply pull this from your branch if needed. Of
> course, the branch needs to be immutable for that, but usually it's no
> big problem. (Ideally speaking, all the published branches should be
> persistent in anyway.)
>
> IIUC, it's the way Andy and Rafael suggested in the thread, and also
> seen in many other subsystems occasionally.
>
> > Until this point (and from this point going forward) we have taken the
> > decision that the default is to take individual patches through their
> > own trees. The only time this differs (unless other arrangements are
> > made e.g. PATCH 3/3) is when there are; build, merge or API
> > dependencies between them. The same stance is taken with
> > driver/platform data and driver/other driver.
> >
> > Let me put one of the issues into context:
> >
> > For those reading along that do not know, Multi-Functional Devices are
> > usually single pieces of silicon which provide many functions
> > (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
> > Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
> > etc etc). The driver which sits in drivers/mfd acts as the parent
> > device and registers its children which live in their own subsystems.
> >
> > Almost all of the patch-sets I receive touch multiple subsystems.
> > Moreover, when the recently described dependencies occur, it is
> > usually I who creates the immutable branches and sends out the
> > pull-requests.
> >
> > If I had to go through the immutable branch/pull-request process for
> > every patch-set I receive, there would be very little time to conduct
> > duties pertaining to my proper job. Ergo, why we apply our own
> > patches, unless there is a good reason (already described) to apply
> > others too.
>
> Hm, I never thought that creating an immutable branch were so
> difficult. Isn't it just a simple branch-off either from the certain
> upstream point (final release or rc) or from your stable branch?
You'd be surprised.
When applying patches, I normally apply them to a mail folder for
further processing. This works great for patches that are applied to
my main branch, but this does not work for immutable branches. These
have to be applied on their own, thus need a 'special' or at least an
empty folder.
- Checkout a new branch based on the same (or earlier, but I always
use the same) commit as the main branch.
- Apply the patches in the normal way, only this time you usually need
to interactively rebase and 'reword' them to add any missing
Acks/Reviewed-bys.
- Tag and sign the branch with a suitable tag name and tag
description.
- Push branch and tag
- Create pull-request text
- Send a formatted email with the pull-request text.
This process is quite a lot more involved than simply applying
relevant patches to your main branch, and as I say, if this was
required for all patch-sets I am sent or involved in, it would really
eat into my day.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
