Karl O. Pinc wrote:
On 12/10/2009 04:39:57 AM, Samuli Seppänen wrote:
David Sommerseth ha scritto:
I believe James have received several patches in the past from
people on
the mailing list - or directly.
They will either include patches into their own source
trees, or
kick them back to be reworked or cancelled completely.
Patches which are accepted will then be sent to James for a final
review
and inclusion. If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was
rejected
and how to make it more acceptable for inclusion. If James can
take
the
time to bring this discussion on the mailing list directly himself
in
these cases, that would bring the needed transparency. Further, it
should hopefully not happen too often, as James' "inner circle"
should
already have made sure it is suitable for inclusion.
Via public discussion. Who wants to submit a patch when it
just disappears without comment. Public discussion has been
sorely lacking in the past.
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.)
Another topic which is needed to be included is documentation.
This
would be to organise the documentation and make sure all features
are
documented, review documentation to make sure it works as expected
etc,
etc. This part do not necessarily require any coding skills at
all.
However, it _could_ be a requirement that all patches be submitted
with documentation. If not, I can't see how you'd want to
include any functional changes without also having documentation
so somebody else would have to be gotten to document the patch.
This is obviously up to whomever reviews the patches.
What I do see as much more urgent is actually a better distributed
VCS/RCS. I believe SVN is used now - but I don't recall where I
found
the URL for it (and I have lost now, I believe). There's also a
rather
outdated CVS tree on sourceforge.net. This needs to be cleaned up,
and
a publicly available source tree must be made available.
David Sommerseth
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.
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.
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.
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.
What's the real policy regards the SVN repository and
what are the concerns that have driven this policy?
I wanted to respond to some of the points brought up, as they are good
points.
First of all, the patch policy: fundamentally, we have to balance two
conflicting goals:
One the one hand people expect OpenVPN to be rock-solid in both
stability and security. In order to maintain this standard of quality,
there needs to be a rigorous process of patch vetting. On the other
hand, as an open source project, OpenVPN needs to be transparent and
open to contributions from the community.
It can be a challenge to balance these goals. And certainly in the
lead-up to the release of 2.1 there was a long period of time that we
had to lean strongly towards (1) to ensure that 2.1 final would be solid.
I think it's great that Samuli Seppänen has come forward to serve as the
OpenVPN Community Manager -- one of our key goals here is to create a
community structure around the patch discussion and approval process
that removes myself as a bottleneck.
Re: the SVN repository.
The policy on the SVN repository is the same as that of most open source
projects: the repository is world-readable, and writable by trusted
members of the development team.
The repository change history is fully transparent. You can use this
command to see every commit made to the repository since the OpenVPN
project inception in 2002.
svn log http://svn.openvpn.net/projects/openvpn/branches/BETA21
(note that now that 2.1 is final, this branch will be renamed to
http://svn.openvpn.net/projects/openvpn/trunk in the near future)
James
