On Mon, Jan 23, 2012 at 8:33 PM, 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. > > 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?
If there is a process like that in place I'll gladly participate on the arches I am working on, notably the ag71xx, and perhaps one day guruplug and x86 and kvm. I do try to test things thoroughly - sometimes too thoroughly, I have something of a backlog. My principal critique of this workflow is that I tend to view svn as part of the problem to a large extent. If I do a patch in my own (git) tree to test with, I invariably have to rebase that tree when it comes down from svn. as I am frequently offline, not being able to do a 'svn log' is the second deal-killer for me, for svn usage. I can see what you propose as being an incremental improvement on what currently exists, and can live with it, however. A second, large problem (in my mind), is that I would like to find a process for getting stuff upstream into the mainline kernel. The latest patch set for the 71xx is something like 84 files and 120+ patches, and most of that is stuff that is unchanged for the past year. Most of what I worked on last quarter got developed in the net-next git tree, and backported and then tested on cerowrt. > > - Felix > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
