Staging tree for AM335x platforms
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. 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). 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. Regards, Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Staging tree for AM335x platforms
Hi, * Jason Kridner jkrid...@beagleboard.org [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 :) 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. 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.. 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 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? 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 Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Staging tree for AM335x platforms
On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren t...@atomide.com wrote: Hi, * Jason Kridner jkrid...@beagleboard.org [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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
