On Mon, 23 Jan 2012 20:33:31 +0100, Felix Fietkau <n...@openwrt.org> wrote:
As you've probably noticed, we've had issues keeping up with the workload of incoming patches. There is quite a bit of work involved in taking care of incoming patches, not just review. Patches need to be compile tested, ideally also runtime tested, and checked for dependency issues. Most of the time, this work is left up to the limited number of people that have SVN access. People often complain that it's hard to get involved, because it takes a long time to get SVN access, and the rules for that may not always be clear.
Even most of the core developers still think the way you've said, when the commit policy mandates runtime testing on multiple platforms. I rather not comment on some of the work people done with their commit access here.
In my opinion, the main issue is not that we don't give out SVN access fast enough, it's that people consider SVN access necessary for contributing in the first place. If we change the way patches are accepted to no longer depend on that, it becomes much easier for people to start. To be able to do that properly, it is important that patches still get reviewed and tested, but we can decentralize this work to split it up among a bigger group. One way to do this would be to have a group of people - with or without SVN access - maintaining a git tree with proposed changes to /trunk or /packages. This tree should be frequently rebased to latest SVN. This allows any developer with SVN access to spend a few minutes a day looking over the tree, giving it a quick sanity check, and then flushing all changes into SVN. With proper care by the tree maintainers, author attribution and review annotations can be easily put into the commit messages to ensure that they are preserved during the commit to SVN. With such a tree, the typical lifetime of a patch could look somewhat like this: - User proposes a patch on the list. - Core developer does a superficial review on patchwork, assigns it to the patch team, possibly with comments on what to test or look out for - Somebody from the patch team picks up the patch, tests it, ACKs it. - Patch gets added to the proposed-changes tree. - A developer with SVN access flushes the proposed-changes tree into SVN. One nice thing about this workflow is that aside from a few scripts to simplify dealing with constantly rebased git trees, we have all the tools we need to implement this. Does this proposal make sense? Do we have any volunteers that are willing to organize and take care of maintaining the tree and compile testing and reviewing the incoming changes?
I thought we have a patch team for at least a year now? Imre _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
