Hi all, > My personal feeling based is that we should probably focus the ACK > system to high-risk patches, e.g. > > - patches touching critical parts of the code (rationale: better safe > than sorry) > - patches from new contributors (rationale: fix stylistic issues and > errors, ensure usefulness, educate) I might add that James wanted to mandate a review on all patches - or at least those that have capability to create security issues. That said, we could probably use a "experimental/testing" tree to host patches/patchsets that make sense, but have not yet been properly reviewed. This would have a couple of nice benefits compared to working with stable master + external trees/patches:
- We could (easily) run build/connectivity tests against this "experimental" tree using our build farm - We could build snapshot binary packages based on this tree, and publish them using apt/yum/website This would allow patches to be reviewed by developers_and_ (easily) tested by users at the same time. The stable tree would still be the basis for official releases, and would pull stuff from "experimental" as it matures. Does this make sense? >> >> Question3: When patch series is merged into tree? >> >> General note: In no way do I see the fast responsive of >> submit-ack-commit a goal! It can take week or a month, depending on >> need/complexity/quality. The goal is to merge mature patchsets that we >> feel comfortable with. If it takes time for the patchset to be polished, that's fine. However, if improving patch throughput helps making releases more often, I think it's worth the effort; most people will be running the latest stable, so getting the code to that phase a.s.a.p. helps to get the bugs ironed out. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
