Hi Nicholas,

We can always use a good lurkers and contributors :). You could
definitely keep an eye on what happening on GitHub (OpenVPN forks and/or
pull requests) and keep us updated on interesting changes. The last time
I looked there was ~1 pull request per month. It possible that there are
also forks with some useful changes.

Just to make this clear... I'm not suggesting we actually start merging
the pull requests. That's something we decided against earlier. What I'm
suggesting is that we keep them enabled and (let Nicholas) forward the
authors to the proper developer channels. In this context a pull request
is an expression of an _intent_ - "I'd like to have my code merged in
OpenVPN". If the authors can express this intent a very lightweight
fashion I'm all for it.

Once we know someone wants their code merged, we can say "Hey, we
noticed you wanted to get this code to OpenVPN. Could you send your
patch to openvpn-devel?". It's much more difficult to say "Nah, too much
bureaucracy involved" when asked directly, than when one is looking at
our developer docs in the Wiki. With some luck we can lure more active
developers to openvpn-devel and #openvpn-devel.

Samuli

> Do you need a middle man to monitor github and forword patches to the
> devel mailing list along with commenting back and forth between
> github?  I'm not well versed in compiled languages but I am no
> stranger to basic code review and developer interactions.
>
> I'd volunteer if you need someone to do this.  I'm a long time lurker,
> user, and contributor to EasyRSA.
>
> Apologize for the top post. Currently mobile.
>
> On Aug 20, 2013 5:04 AM, "David Sommerseth"
> <openvpn.l...@topphemmelig.net <mailto:openvpn.l...@topphemmelig.net>>
> wrote:
>
>     On 20/08/13 11:29, Gert Doering wrote:
>     > Hi,
>     >
>     > On Tue, Aug 20, 2013 at 12:01:33PM +0300, Samuli Seppänen wrote:
>     >>> We've had questions on #openvpn-devel about pull request 7,
>     which was the
>     >>> first time (on request *7*) that anyone was taking note that
>     we offer
>     >>> pull requests at all - so there's 7 pull requests out there
>     that are ignored.
>     >> Well, we don't have the manpower to look at Trac bug reporting,
>     and we
>     >> still don't disable bug reporting, do we? :)
>     >
>     > This is a problem, indeed.  But it's not an argument for adding
>     yet another
>     > queue that we don't look at.
>
>     In addition, we don't have "competing" alternatives to bug tracking on
>     the table.  And we need bug tracking, unfortunately.
>
>     >> Anyways, I can keep an eye on the pull requests and if something
>     >> interesting pops up, I can forward those people to
>     openvpn-devel. Or, if
>     >> we really want to disable pull requests, we should monitor the
>     OpenVPN
>     >> forks in GitHub for something interesting, and encourage people
>     to push
>     >> their stuff to main development line.
>     >
>     > I've never understood the hype around github, tbh.  If you see
>     value in
>     > adding to your workload, feel free to - but really, evidence
>     speaks against
>     > enabling pull requests.
>
>     +1
>
>     > Also, Dazo and I won't actually *use* git-pull to fetch those,
>     so one
>     > of the big reasons why you would want that ("to enable git
>     pull") wouldn't
>     > apply anyway.  We have agreed on a workflow how to integrate
>     patches, and
>     > "pull" is not part of it.  "git am" and "git push" are...
>
>     Even James sends patches to the mailing list for review nowadays,
>     so we
>     don't even do git pull from his repos.
>
>     We've settled a long time ago that we wanted to review patches on
>     the ML
>     to keep track of the process in a distributed manner (reviews are not
>     stored in a single server or with a single provider).
>
>     Github can have some kind of review as well, but is doing it in a
>     centralised manner.  And it would require us to write new scripts to
>     automate git pulls as well - to get those extra review lines we add to
>     the commit logs.  And if Github disappears, changes URL schema or
>     similar things, we've lost the references to the review.  On the
>     mailing
>     list, there is at least the Message-ID which is unique enough to even
>     use in google searches.  Nothing is really lost if gmane.org
>     <http://gmane.org> or
>     sourceforge.net <http://sourceforge.net> shuts down.
>
>
>     --
>     kind regards,
>
>     David Sommerseth
>
>
>     
> ------------------------------------------------------------------------------
>     Introducing Performance Central, a new site from SourceForge and
>     AppDynamics. Performance Central is your source for news, insights,
>     analysis and resources for efficient Application Performance
>     Management.
>     Visit us today!
>     
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Openvpn-devel mailing list
>     Openvpn-devel@lists.sourceforge.net
>     <mailto:Openvpn-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>


Reply via email to