well, I'm not prepared to pass commit procedures, I'm awaiting for
Samuli response whether or not he can handle those if I will send
patches directly to him
Well, if the patches would be 100% perfect all the time I probably would
not mind relaying them to the list. However, in that case you c
Hi,
On Mon, May 02, 2016 at 04:25:26PM +0500, ?? wrote:
> the point is "if there were PR ... and some friendly developers behaviour",
> so that issue wouldn't get lost "in mailing list archives"
>
> currently, it was definitely lost. nobody knows where it is
Of course I know
Hi,
On Mon, May 02, 2016 at 04:23:40PM +0500, ?? wrote:
> and, there's no point in having variables uninitialized actually. you
> depend on vary strange issues like OS decision to initialize them with NULL
> or whatever.
Well, there's a C standard, and that *requires* variabl
HI,
On Mon, May 2, 2016 at 11:38 AM, Илья Шипицин wrote:
> it is already running at "coverity_scan" branch:
> https://travis-ci.org/OpenVPN/openvpn/builds/120718429
>
> so, it definitely good
Well, "it seems to work" is one thing, but a review should also cover
whether some change or addition is
the point is "if there were PR ... and some friendly developers behaviour",
so that issue wouldn't get lost "in mailing list archives"
currently, it was definitely lost. nobody knows where it is
2016-05-02 16:17 GMT+05:00 Gert Doering :
> Hi,
>
> On Mon, May 02, 2016 at 04:14:23PM +0500, ???
ok, we are running 1000+ users installation, just couple of them
experienced that behaviour.
and, after I investigated it in details, I came to uninitilized variable
(which by chance was "almost always" initialized with NULL)
from that point of view, 2 out of 1000 is almost nothing and I could te
Hi,
On Mon, May 02, 2016 at 04:14:23PM +0500, ?? wrote:
> I was very disapointed with what happened to my report in mailing list. So,
> I will not send anything to list until things will change. Or I will ask
> Samuli to do so.
If I remember right, you got a clear response th
ok, I sent to list bug report, it was somewhere on windows 8.1 beta.
somehow, uninitialized variables were initialized with garbage (it was
fixed to NULL in windows 8.1 release)
bug is there
https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/error.c#L458
if std_redir is defined, so orig_
Hi,
On Mon, May 02, 2016 at 03:58:25PM +0500, ?? wrote:
> well, I'm not prepared to pass commit procedures, I'm awaiting for Samuli
> response whether or not he can handle those if I will send patches directly
> to him
Feel free to use PRs to *discuss* patches (I already agre
well, I'm not prepared to pass commit procedures, I'm awaiting for Samuli
response whether or not he can handle those if I will send patches directly
to him
2016-05-02 15:56 GMT+05:00 Gert Doering :
> Hi,
>
> On Mon, May 02, 2016 at 03:54:46PM +0500, ?? wrote:
> > there's not
Hi,
On Mon, May 02, 2016 at 03:54:46PM +0500, ?? wrote:
> there's nothing to be afraid of.
>
> http://doc.gitlab.com/ee/workflow/importing/import_projects_from_github.html
>
> we can export all issues, pr, whatever from github to gitlab if github will
> decide to follow code
Hi,
On Mon, May 02, 2016 at 03:51:06PM +0500, ?? wrote:
> if we would have been using PR, anyone would be able to have a look at
> single place and find opened PRs.
And what will he or she learn from that?
> can you find unmerged patches ?
Yes. (But it does not really matt
there's nothing to be afraid of.
http://doc.gitlab.com/ee/workflow/importing/import_projects_from_github.html
we can export all issues, pr, whatever from github to gitlab if github will
decide to follow code.google.com
2016-05-02 15:09 GMT+05:00 Gert Doering :
> Hi,
>
> On Mon, May 02, 2016 at
if we would have been using PR, anyone would be able to have a look at
single place and find opened PRs.
can you find unmerged patches ?
2016-05-02 15:46 GMT+05:00 Gert Doering :
> Hi
>
> On Mon, May 02, 2016 at 03:19:54PM +0500, ?? wrote:
> > when using mailing list there's
Hi
On Mon, May 02, 2016 at 03:19:54PM +0500, ?? wrote:
> when using mailing list there's no way to clearly determine what was done
> and needs to pay attention to.
>
> and people get disappointed "I sent a patch and nothing happened"
>
> how that is supposed to work in maili
when using mailing list there's no way to clearly determine what was done
and needs to pay attention to.
and people get disappointed "I sent a patch and nothing happened"
how that is supposed to work in mailing list paradigma?
2016-05-02 15:09 GMT+05:00 Gert Doering :
> Hi,
>
> On Mon, May 02,
Hi,
On Mon, May 02, 2016 at 02:55:52PM +0500, ?? wrote:
> sf.net mailing list can go away as well.
> I do not see why relying on sf.net is any better than relying on github.com
It isn't. Thus, we do not rely on sf.net - the mailing list archive
is referenced only at gmane.o
sf.net mailing list can go away as well.
I do not see why relying on sf.net is any better than relying on github.com
2016-05-02 14:47 GMT+05:00 Gert Doering :
> Hi,
>
> On Mon, May 02, 2016 at 12:02:37PM +0300, Samuli Seppänen wrote:
> > At minimum we should clearly state why we prefer email pat
Hi,
On Mon, May 02, 2016 at 12:02:37PM +0300, Samuli Seppänen wrote:
> At minimum we should clearly state why we prefer email patches
> over GitHub PRs. Then revisit the arguments every now and then, and
> adapt as necessary.
"Our workflow relies on public availability of patch and ACK, referen
it is already running at "coverity_scan" branch:
https://travis-ci.org/OpenVPN/openvpn/builds/120718429
so, it definitely good
however, I would add (to make build running on ubuntu trusty)
sudo: required
dist: trusty
2016-05-02 13:59 GMT+05:00 Samuli Seppänen :
>
> On Mon, May 2, 2016 at 9:44
It seems, patches are often lost "somewhere in mailing list archives"
Indeed, because we've been unable to process them in time. And there is
no fully automated system to show what the patch status is.
I still have no idea why this way of distributing patches is prefferable
over native git
On Mon, May 2, 2016 at 9:44 AM, Samuli Seppänen wrote:
1) add travis-ci support (there are few tests in "t" and we can run
cppcheck)
I assume cppcheck produces the same results regardless of the
OS/distribution it is running on. If this is the case, then we should
add cppcheck tests to Tra
It seems, patches are often lost "somewhere in mailing list archives"
I still have no idea why this way of distributing patches is prefferable
over native github PRs
2 мая 2016 г. 12:55 пользователь "Steffan Karger"
написал:
On Mon, May 2, 2016 at 9:44 AM, Samuli Seppänen wrote:
>
>> 1) add tra
On Mon, May 2, 2016 at 9:44 AM, Samuli Seppänen wrote:
>
>> 1) add travis-ci support (there are few tests in "t" and we can run
>> cppcheck)
>
> I assume cppcheck produces the same results regardless of the
> OS/distribution it is running on. If this is the case, then we should
> add cppcheck test
I can prepare .travis.yml for openvpn, however, I'm not prepared for "pack
your commit so and so... We are short on time to merge it"
Is it ok if I send .travis.yml to you? Can you proceed with commit/review
procedure?
2 мая 2016 г. 12:44 пользователь "Samuli Seppänen"
написал:
Hello,
>
> I jus
Hello,
I just run cppcheck and ...
[src/openvpnserv/interactive.c:601]: (error) Memory pointed to by
'addr_row' is freed twice.
[src/openvpnserv/interactive.c:700]: (error) Memory pointed to by
'fwd_row' is freed twice.
[src/openvpnserv/interactive.c:1329]: (error) Common realloc mistake:
'han
Hello,
I just run cppcheck and ...
[src/openvpnserv/interactive.c:601]: (error) Memory pointed to by
'addr_row' is freed twice.
[src/openvpnserv/interactive.c:700]: (error) Memory pointed to by 'fwd_row'
is freed twice.
[src/openvpnserv/interactive.c:1329]: (error) Common realloc mistake:
'handle
27 matches
Mail list logo
