On Thu, Oct 08, 2015 at 09:04:06AM +1000, Dave Airlie wrote: > On 8 October 2015 at 01:15, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > Hi everyone, > > > > Lately I've noticed that a bunch of trivial patches have been posted > > across all drivers. We've also encountered situations in the past where > > (relatively trivial) subsystem-wide changes have been made but it ended > > up being very difficult to get patches merged (often because they had > > inter-dependencies and nobody felt responsible for merging them). Often > > Dave has been the last resort for this kind of patches. A side-effect > > has been that it often takes a lot of time for such patches to get > > merged (if at all) and they usually don't end up in linux-next and > > therefore see little testing before they are applied. > > > > To remedy that situation I'd like to propose the addition of a tree to > > keep track of these kinds of patches. Note that the target here are > > trivial patches, such as coding style fixes, fixes for build warnings > > or errors, subsystem-wide API changes, etc. It also targets mostly the > > drivers that don't have a branch that feeds into linux-next. Patches > > against drivers that already feed into linux-next should go through the > > corresponding trees. One reasonable exception for this, in my opinion, > > are subsystem-wide changes, because applying them via different trees > > usually ends up being messy. > > > > I pushed a branch[0] with a set of patches that I've picked up from > > patchwork and which seemed to match the above criteria. I've also Cc'ed > > a bunch of people (mostly a subset of what get_maintainer.pl reported > > for the patches in the branch). > > > > Before going any further with this I'd like to get some feedback on the > > idea. Dave, do you think this is a good idea and would you be willing to > > give this a try? > > I'm not going to object, I'm not sure trivial covers a lot of these > patches though. > > I generally don't go nuts picking up the trivial patches on a weekly basis, as I > don't think they generally need that much attention, a number of the things > in your tree for example are things I've merged into -fixes instead, or I'm > waiting to see if driver maintainers pick them up themselves. Determining what's a candidate for the trivial tree is one of the things that I'm most uncertain about. Given what you say above there's a lot of potential for conflicts in linux-next if both of us end up picking up the same patches. I certainly wouldn't want to step on your toes or make your job any more difficult. But it seems that such a trivial tree would do just that, so it doesn't sound like a really helpful addition. > It would be nice if more driver maintainers had trees feeding into drm-next > or sent me drm-next pull requests no matter how small on a more regular basis > esp after -rc2/3. That I completely second. One of the primary goals of having a trivial tree is to get patches into linux-next more quickly. This is especially useful, in my opinion, for things that fix up trivial build warnings or similar, so that we have a fast way for such patches to get into linux- next and avoid needless duplication of effort by people trying again and again to fix warnings in linux-next. > So I probably wouldn't to a pull req from that tree, but it might be something > I'd cherry-pick from if I remember instead of using patchwork. > > At least in theory I'm the last line of maintainer for the non-ARM drivers > (i.e. qxl, mgag200, etc), I don't really want to be last person in line for SoC > drivers as I'm not really knowledgeable enough, and for SoCs I'm pretty > much at the stage where only pull requests from someone who cares will generally > make me merge patches. The thing that worries me most about this is that it's going to derail into me becoming a defacto maintainer for unmaintained drivers. That's not something I'm willing to sign up for because I simply don't have the time to do it. I'd like it to be very clear that the existence of such a tree doesn't exempt maintainers from caring about the patches. I fully agree that we need more trees properly feeding into linux-next, hence why I proposed as a first step to add MAINTAINERS entries for drivers that lack one. The second primary goal is to coordinate subsystem-wide changes. That could be done without this tree using ad-hoc branches. Granted, it'd become somewhat more complicated to feed it into linux-next, but one solution to that would be to take it through an existing tree. > but hey lets give this a go and see if it helps, if you have the time! Coordinating which patches go where is probably going to be the most difficult part. Any suggestions? Perhaps the simplest would be to base that tree onto drm-fixes and drm-next so that patches can automatically filter out with a rebase. But that means that it would need to be fairly often rebased for it to be effective. Maybe just using IRC, email or even patchwork would be equally effective. Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
