On Monday 23 Jan 2012 21:18:48 Outback Dingo wrote: > On Mon, Jan 23, 2012 at 2: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? > > > > - Felix > > Ive done what I can for packages... Im capable of devoting more time, > and becoming more involved, So Id be willing to volunteer >
ditto on that - I'd consider packages to be typically low-risk anyway; most of the time it's either something brand new or a version bump, so count me in. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
