On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Hi, > > * Jason Kridner <jkridner@xxxxxxxxxxxxxxx> [110921 10:56]: >> Tony, >> >> I'm looking at creating a public repository to hold patches not yet in >> shape for inclusion in linux-omap (if not personally, then someone at >> TI that meets the below charter). I know there can be concern that >> this becomes a distraction if we start pulling in community patches. >> It seems it needs to be coupled with reworking systems for acceptance >> upstream, but we'd like for there to be something where community >> members can generate patches against while we are in the process of >> cleaning up the underlying platform bits. > > OK cool. > >> Do you have any recommendations or guidelines that should be followed >> regarding anything about such a public repository? Recommendations >> and guidelines can include, but not be limited to, where the >> repository should live, where patches and pull requests should be >> submitted, what types of patches should be accepted and what state >> they should be in, when should it be rebased, who is suitable to >> maintain this repository and what should be used for managing patch >> status (ie. patchwork and which patchwork). > > Well in general the thing to watch out for is once you create a tree > it becomes a complete mess in about three months. Or else it just > becomes a graveyard of unmergeable patches :) I'm not going to advertise a tree here and on the beagle list until I'm confident I can stick with it a couple of years consistently. I like to keep some labels on old stuff, but I would commit to having it rebased frequently and tested in an automated fashion. > > So keeping that in mind, ideally your tree would be just a daily merge > of various driver developers branches. And then try to set up things > where the responsibility of merging code upstream is on the drivers > developers. Trying to merge other people's patches upstream is not > scalable. Understood. I'd be looking for contributors to show some commitment or drop their patches. I'm sure there will be a certain amount of fire-and-forget patches coming from people that I'll want to try to push for them, but I'll try to shed the cruft frequently. > > Other than that, you should be able to base it on some recent mainline > tag and pick in some queued up patches as needed. > >> If this doesn't sound useful to you, then please feel free to shut me >> down on this. The goal is to help and it is understood that >> contributions to the infrastructure (dev tree, pwr mgmt, etc.) are >> required to be productive. > > That totally sounds usable to me :) Assuming you can figure out some > way to address the comments above. > > For helping with contributions, I can think of a few places where > help is badly needed: > > 1. Remove dependencies in mainline kernel that block merging > > Maybe you can isolate some issues in mainline kernel that cause > you problems merging your patches upstream? If so, whatever is > needed should be done to patch away those dependencies. At least > PM patches fit into this category.. Makes sense. > > 2. Merge all am335x/beagle clone board-*.c files together > > This would help a lot when we start converting drivers to use > device tree as it reduces the number of board-*.c files Sounds like a good task and something I can tackle. I got some push-back on this from internal developers, but I think I can start merging some of it myself and send some code to ask advice on how to make it most maintainable. > > 3. Help with device tree conversion of device drivers > > Which drivers do most am335x and beagle clones use? Maybe > you can help converting those drivers to use device tree? USB, GPIO, I2C and SPI are most critical from my perspective. I need to figure out which of those already have some owners pushing them ahead. > Sure some drivers depend on regulator framework conversion and > the device tree omap_device glue layer, but there are already > patches being posted for those Great. I guess it makes sense for this tree to include those patches and hopefully the thrash when they change won't be unbearable. I won't know until I start doing it. :-) > > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
