> Via public discussion. Who wants to submit a patch when it > just disappears without comment. Public discussion has been > sorely lacking in the past. > I can't comment on how patches have been handled in the past, but not discussing and including them is a sure way to demotivate people. >>> Even >>> >> patches >> >>> these people write themselves should be posted to the openvpn-devel >>> >> list >> >>> (or other another more suitable one). That way, more eyes can pay >>> attention and raise awareness if something seems to be wrong or >>> >> needs to >> >>> be discussed. >>> > > Absolutely. Public discussion of all submitted patches is essential. > > When you can commit to public discussion of submitted patches > then I'll re-send at least one. (Something very minor.) > I agree that all developers should be treated equal and use the same tools for their work. I don't personally like when people do things behind my back. Especially when the actions affects me somehow or when it's clear I could have provided useful feedback. In the long run this behavior leads to mistrust - "them" and "us" mentality. This is harmful in any social relations, not just in OSS projects. >> The SVN repository URL's are here: >> >> http://www.openvpn.net/index.php/open-source/documentation/ >> miscellaneous/subversion-repository.html >> >> I checked the logs and last update in 2.1 branch was from 2009-11-20, >> so >> it's probably 100% up-to-date. I agree with you for the most part. >> Beaker sounds interesting, as I guess OpenVPN probably lends itself >> well >> to automated testing. >> > > Are you saying that there has been no development on OpenVPN since > 2009-11-20, approximately 20 days ago? That seems a long time > for James to have done no work on the code or documentation. > I have to admit I do not know. I do know that James is swamped with work and hence is unable to pay enough attention to the project. This is something I'll be discussing with him. And the primary reason I initiated this discussion. I'll try to help him out of his deadlock situation which is hurting everybody. > A public revision control repository means that the public gets > to see all the changes as they are committed. It does not mean > that we get to see the code only at arbitrary release points. > Agreed. However, if you take a look at the SVN logs each atomic change (not just release points) is listed. > There are 2 reasons for this. The first is trust and transparency. > We want to see where the code is going as it gets there so > we can make our plans. The second is to assist the people who > review submitted patches. Submitted patches should, by > strong preference, be against the very latest version > of the code. This keeps merge conflicts, and related bugs, > to a minimum and makes the job of reviewing patches much > easier. > I agree. Discussing and merging patches in a timely manner is essential. As is an up-to-date development tree. > If you don't have a public version of the latest development > code you can't be said to be running an open project. > > FWIW using a good (rather than merely adequate) revision control > system makes it much easier to keep the very latest code > on-line and still perform regression tests, keep separate > code branches for feature development, and so forth. > Any suggestion which VCS would do the best job?
> What's the real policy regards the SVN repository and > what are the concerns that have driven this policy? > I'd guess the decision was not driven by any conscious policy. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc
