You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Dominik Psenner <dp...@apache.org> on 2018/01/08 21:44:58 UTC
[log4net] release 2.0.9
Hi,
quite some time passed by since we last made a release and there are a few
issues that have been fixed and should be shipped as part of a release. So
this is my call for help.
There are a few things on the to do list:
- check jira for issues that can be closed as won't fix
- check jira for issues that make sense to be part of the next release and
qualify as "easily fixed"
- check jira for issues that have been resolved and where "fixed version"
is not 2.0.9
- check the tests against the netstandard-1.3 target; looks like they've
not been run by the build scripts during the last release and I've a bad
feeling there might be dragons. Ideally we finish the build pipeline to get
a better feeling
- prepare the codebase for a release
- properly test the release
- make the release
Please note that this checklist might not be complete at all.
There are also a few things that I absolutely see not ready for 2.0.9:
- add support for the netstandard-2.0 target; the way how netstandard-2.0
target was added drops the tests for netstandard-1.3 and that's far from
how it should be
At the moment I've little to no spare time to get all this work done and do
the release. Is there someone out there who offers his/her help?
Best regards
--
Dominik Psenner
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
On 28 Jan 2018 11:43 a.m., "Stefan Bodewig" <bo...@apache.org> wrote:
On 2018-01-21, Dominik Psenner wrote:
> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of FileStream state that FileShare.None is the only
>> thing that works on Unix at all, all other options get translated to
>> "share freely" internally. Unfortunately I haven't seen this
>> documented for .NET Standard in any place so far.
> So we could do FileShare.None when we detect that we run on
> linux. What do you think?
If that works as expected then you'd be unable to "tail" a logfile. This
is most likely not what people want. TBH I don't know whether there is a
way to make locking work "properly" for .NET Core on Linux at all.
I would be surprised if file locking was forgot in the netstandard-1.3 api.
I stumbled upon this https://github.com/dotnet/corefx/issues/5964 but have
no possibility to do cross platform testing in this moment. This is on my
task list now.
For the 2.0.9 release I am inclined to live with the problem and cut the
release the same way 2.0.8 has been created. The situation is not worse
than it has been before and we do have some important fixes in the
develop branch.
There are indeed important things queued that need to get out. So far the
issue is not a blocker but to me it is something that needs to be fixed or
left out from the api. I would like to avoid in the future situations where
the api and documentation indicate a usecase that is broken for good. But
maybe the codebase grew for too long and needs a good bunch of refactor
with all the different targets. #if are no longer an option to me. Should
we duplicate the codebase for the different targets that differ the most?
Has the time come for a log4net.standard and log4net.mono?
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-21, Dominik Psenner wrote:
> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of FileStream state that FileShare.None is the only
>> thing that works on Unix at all, all other options get translated to
>> "share freely" internally. Unfortunately I haven't seen this
>> documented for .NET Standard in any place so far.
> So we could do FileShare.None when we detect that we run on
> linux. What do you think?
If that works as expected then you'd be unable to "tail" a logfile. This
is most likely not what people want. TBH I don't know whether there is a
way to make locking work "properly" for .NET Core on Linux at all.
For the 2.0.9 release I am inclined to live with the problem and cut the
release the same way 2.0.8 has been created. The situation is not worse
than it has been before and we do have some important fixes in the
develop branch.
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bo...@apache.org> wrote:
On 2018-01-20, Dominik Psenner wrote:
> I have looked at the assert that fails. For one there's a comment on it
> saying that "on linux locking seems to not behave as one would expect".
> Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
> that this all comes from my memory and there might be an error here or
> there. It however indicates a long known but badly documented issue
related
> to how log4net behaves on linux.
Maybe, yes. See the other thread for my investigation so far. The github
issue I've linked and the source code for the Unix implementation of
FileStream state that FileShare.None is the only thing that works on
Unix at all, all other options get translated to "share freely"
internally. Unfortunately I haven't seen this documented for .NET
Standard in any place so far.
So we could do FileShare.None when we detect that we run on linux. What do
you think?
> I really have a bad feeling to release something like that now that
> netstandard has become a supported framework and therefore log4net will
> most likely run more on linux machines.
I understand this, but as far as locking of files goes there isn't
anything we can do.
> How about if we configure ci to run our tests for both netstandard and
mono
> on linux and windows?
I'm not sure we've got Windows slaves running either Mono or .NET
Standard (and if so, probably not 1.x). Maybe the Windows slaves can run
Docker themselves, then we might be able to use the "dotnet" Windows
server images available from dockerhub.
We can start small and work us through the ranks one by one.
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-20, Dominik Psenner wrote:
> I have looked at the assert that fails. For one there's a comment on it
> saying that "on linux locking seems to not behave as one would expect".
> Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
> that this all comes from my memory and there might be an error here or
> there. It however indicates a long known but badly documented issue related
> to how log4net behaves on linux.
Maybe, yes. See the other thread for my investigation so far. The github
issue I've linked and the source code for the Unix implementation of
FileStream state that FileShare.None is the only thing that works on
Unix at all, all other options get translated to "share freely"
internally. Unfortunately I haven't seen this documented for .NET
Standard in any place so far.
> I really have a bad feeling to release something like that now that
> netstandard has become a supported framework and therefore log4net will
> most likely run more on linux machines.
I understand this, but as far as locking of files goes there isn't
anything we can do.
> How about if we configure ci to run our tests for both netstandard and mono
> on linux and windows?
I'm not sure we've got Windows slaves running either Mono or .NET
Standard (and if so, probably not 1.x). Maybe the Windows slaves can run
Docker themselves, then we might be able to use the "dotnet" Windows
server images available from dockerhub.
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
On 20 Jan 2018 9:29 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> Building .NET 2.0 (not standard or core, good old .NET framework) was
>> broken.
> I see. I wonder why the build worked on ci.
because there is no build step for compile-net-2.0 :-)
I'll try to add one.
> Btw, have you noticed that the head of develop failed in ci? I'm
> currently on my phone only and therefore cant figure out why.
The build ends with
,----
| Could not update commit status, please check if your scan credentials
belong to a member of the organization or a collaborator of the repository
and repo:status scope is selected
I believe this is a warning message of the Jenkins github plugin and it can
be ignored for now. It means that jenkins github plugin was unable to store
the build outcome to the github page. I believe there is already an infra
ticket for this. It would still be good to double check.
|
| ERROR: script returned exit code 1
| Finished: FAILURE
`----
That's the generic error message that always shows up when the build fails.
I have no idea what this means.
>> Not sure what "all targetted" frameworks means. The quote above is from
>> running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
>> tested this by changing into the log4net.tests dir and running "dotnet
>> test".
> That's roughly what the runtests-netstandard-1.3 target does, too.
Then maybe my fear that the test pass on Windows but fail on Linux is
warranted. In any case it doesn't necessarily need to stop us from
building the 2.0.9 release as the test used to pass on my Windows bix
and they still do.
I have looked at the assert that fails. For one there's a comment on it
saying that "on linux locking seems to not behave as one would expect".
Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
that this all comes from my memory and there might be an error here or
there. It however indicates a long known but badly documented issue related
to how log4net behaves on linux.
I really have a bad feeling to release something like that now that
netstandard has become a supported framework and therefore log4net will
most likely run more on linux machines.
How about if we configure ci to run our tests for both netstandard and mono
on linux and windows?
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> Building .NET 2.0 (not standard or core, good old .NET framework) was
>> broken.
> I see. I wonder why the build worked on ci.
because there is no build step for compile-net-2.0 :-)
I'll try to add one.
> Btw, have you noticed that the head of develop failed in ci? I'm
> currently on my phone only and therefore cant figure out why.
The build ends with
,----
| Could not update commit status, please check if your scan credentials belong to a member of the organization or a collaborator of the repository and repo:status scope is selected
|
| ERROR: script returned exit code 1
| Finished: FAILURE
`----
I have no idea what this means.
>> Not sure what "all targetted" frameworks means. The quote above is from
>> running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
>> tested this by changing into the log4net.tests dir and running "dotnet
>> test".
> That's roughly what the runtests-netstandard-1.3 target does, too.
Then maybe my fear that the test pass on Windows but fail on Linux is
warranted. In any case it doesn't necessarily need to stop us from
building the 2.0.9 release as the test used to pass on my Windows bix
and they still do.
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> On 2018-01-15, Dominik Psenner wrote:
>
>>> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>>>> There still are lots of version conflicts that we probably want to
>>>> reolve first. Unfortunately I have no clue how to resolve them
correctly
>>>> so that we figure out the minimal versions required to make things work
>>>> on .NET Standard 1.3.
>>> That's great news. Please try the feature/cd-pipeline branch, there I
>>> may have already fixed all of this. But since this does not work on CI
>>> it's not yet merged into develop.
>> After merging the fix to the NAnt build so that .NET 2.0 compilation
>> works I've been able to build that branch. The test result on Windows:
>> ,----
>> | NUnit Adapter 3.9.0.0: Test execution complete
>> |
>> | Total tests: 91. Passed: 85. Failed: 0. Skipped: 6.
>> | Test Run Successful.
>> | Test execution time: 3.8648 Seconds
>> `----
>
>> So it seems the test errors you see in CI don't happen on my Win7 build
>> VM.
> The .net 2.0 tests should not be broken, as far as I am aware of. Do you
> mean netstandard-2.0?
https://github.com/apache/logging-log4net/commit/
c9b9382bdae5c745d4b26fe32425fbbf0b0dfd7c#diff-482325462bbb88c7212c1b047c5da7
39
Building .NET 2.0 (not standard or core, good old .NET framework) was
broken.
I see. I wonder why the build worked on ci. Btw, have you noticed that the
head of develop failed in ci? I'm currently on my phone only and therefore
cant figure out why.
> CI does fail with testing netstandard1.3, which would be the target
> runtests-netstandard-1.3. Were you able to run the tests against all
> targetted frameworks?
Not sure what "all targetted" frameworks means. The quote above is from
running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
tested this by changing into the log4net.tests dir and running "dotnet
test".
That's roughly what the runtests-netstandard-1.3 target does, too.
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>> On 2018-01-15, Dominik Psenner wrote:
>
>>> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>>>> There still are lots of version conflicts that we probably want to
>>>> reolve first. Unfortunately I have no clue how to resolve them correctly
>>>> so that we figure out the minimal versions required to make things work
>>>> on .NET Standard 1.3.
>>> That's great news. Please try the feature/cd-pipeline branch, there I
>>> may have already fixed all of this. But since this does not work on CI
>>> it's not yet merged into develop.
>> After merging the fix to the NAnt build so that .NET 2.0 compilation
>> works I've been able to build that branch. The test result on Windows:
>> ,----
>> | NUnit Adapter 3.9.0.0: Test execution complete
>> |
>> | Total tests: 91. Passed: 85. Failed: 0. Skipped: 6.
>> | Test Run Successful.
>> | Test execution time: 3.8648 Seconds
>> `----
>
>> So it seems the test errors you see in CI don't happen on my Win7 build
>> VM.
> The .net 2.0 tests should not be broken, as far as I am aware of. Do you
> mean netstandard-2.0?
https://github.com/apache/logging-log4net/commit/c9b9382bdae5c745d4b26fe32425fbbf0b0dfd7c#diff-482325462bbb88c7212c1b047c5da739
Building .NET 2.0 (not standard or core, good old .NET framework) was
broken.
> CI does fail with testing netstandard1.3, which would be the target
> runtests-netstandard-1.3. Were you able to run the tests against all
> targetted frameworks?
Not sure what "all targetted" frameworks means. The quote above is from
running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
tested this by changing into the log4net.tests dir and running "dotnet
test".
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
On 2018-01-15, Dominik Psenner wrote:
> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>> Hi
>> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
>> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
>> able to deal with the csproj files (2.0.8 has been using json projects
>> with .NET Core 1.0 preview3).
>> After some tweaks I am able to build a distribution if this is the route
>> we want to go.
>> After upgrading some dependencies and adding a few others "dotnet test"
>> passes for me on Windows.
>> There still are lots of version conflicts that we probably want to
>> reolve first. Unfortunately I have no clue how to resolve them correctly
>> so that we figure out the minimal versions required to make things work
>> on .NET Standard 1.3.
> That's great news. Please try the feature/cd-pipeline branch, there I
> may have already fixed all of this. But since this does not work on CI
> it's not yet merged into develop.
After merging the fix to the NAnt build so that .NET 2.0 compilation
works I've been able to build that branch. The test result on Windows:
,----
| NUnit Adapter 3.9.0.0: Test execution complete
|
| Total tests: 91. Passed: 85. Failed: 0. Skipped: 6.
| Test Run Successful.
| Test execution time: 3.8648 Seconds
`----
So it seems the test errors you see in CI don't happen on my Win7 build
VM.
The .net 2.0 tests should not be broken, as far as I am aware of. Do you
mean netstandard-2.0?
CI does fail with testing netstandard1.3, which would be the target
runtests-netstandard-1.3. Were you able to run the tests against all
targetted frameworks?
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-15, Dominik Psenner wrote:
> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
>> Hi
>> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
>> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
>> able to deal with the csproj files (2.0.8 has been using json projects
>> with .NET Core 1.0 preview3).
>> After some tweaks I am able to build a distribution if this is the route
>> we want to go.
>> After upgrading some dependencies and adding a few others "dotnet test"
>> passes for me on Windows.
>> There still are lots of version conflicts that we probably want to
>> reolve first. Unfortunately I have no clue how to resolve them correctly
>> so that we figure out the minimal versions required to make things work
>> on .NET Standard 1.3.
> That's great news. Please try the feature/cd-pipeline branch, there I
> may have already fixed all of this. But since this does not work on CI
> it's not yet merged into develop.
After merging the fix to the NAnt build so that .NET 2.0 compilation
works I've been able to build that branch. The test result on Windows:
,----
| NUnit Adapter 3.9.0.0: Test execution complete
|
| Total tests: 91. Passed: 85. Failed: 0. Skipped: 6.
| Test Run Successful.
| Test execution time: 3.8648 Seconds
`----
So it seems the test errors you see in CI don't happen on my Win7 build
VM.
>> I don't see netstandard 2.0 support at all? Are you talking about
>> something you would have tackled if time allowed?
> There's another feature branch for this and an issue that tracks the
> progress.
Ah, I see. Let's focus on getting 2.0.9 out without that first.
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
2018-01-15 10:22 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
> Hi
>
> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
> able to deal with the csproj files (2.0.8 has been using json projects
> with .NET Core 1.0 preview3).
>
> After some tweaks I am able to build a distribution if this is the route
> we want to go.
>
> After upgrading some dependencies and adding a few others "dotnet test"
> passes for me on Windows.
>
> There still are lots of version conflicts that we probably want to
> reolve first. Unfortunately I have no clue how to resolve them correctly
> so that we figure out the minimal versions required to make things work
> on .NET Standard 1.3.
>
That's great news. Please try the feature/cd-pipeline branch, there I may
have
already fixed all of this. But since this does not work on CI it's not yet
merged
into develop.
>
> On 2018-01-08, Dominik Psenner wrote:
>
> > There are also a few things that I absolutely see not ready for 2.0.9:
>
> > - add support for the netstandard-2.0 target; the way how netstandard-2.0
> > target was added drops the tests for netstandard-1.3 and that's far from
> > how it should be
>
> I don't see netstandard 2.0 support at all? Are you talking about
> something you would have tackled if time allowed?
>
There's another feature branch for this and an issue that tracks the
progress.
>
> > At the moment I've little to no spare time to get all this work done
> > and do the release. Is there someone out there who offers his/her
> > help?
>
> I'm willing to help with experiments and procedural stuff but probably
> won't find the time to contribute much beyond that.
>
That's already a lot! Thanks for looking at it.
--
Dominik Psenner
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
Hi
by now I've dusted off the old VM that I used to build 2.0.8 (at leat
the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
able to deal with the csproj files (2.0.8 has been using json projects
with .NET Core 1.0 preview3).
After some tweaks I am able to build a distribution if this is the route
we want to go.
After upgrading some dependencies and adding a few others "dotnet test"
passes for me on Windows.
There still are lots of version conflicts that we probably want to
reolve first. Unfortunately I have no clue how to resolve them correctly
so that we figure out the minimal versions required to make things work
on .NET Standard 1.3.
On 2018-01-08, Dominik Psenner wrote:
> There are also a few things that I absolutely see not ready for 2.0.9:
> - add support for the netstandard-2.0 target; the way how netstandard-2.0
> target was added drops the tests for netstandard-1.3 and that's far from
> how it should be
I don't see netstandard 2.0 support at all? Are you talking about
something you would have tackled if time allowed?
> At the moment I've little to no spare time to get all this work done
> and do the release. Is there someone out there who offers his/her
> help?
I'm willing to help with experiments and procedural stuff but probably
won't find the time to contribute much beyond that.
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@gmail.com>.
2018-01-13 16:40 GMT+01:00 Stefan Bodewig <bo...@apache.org>:
> On 2018-01-12, Dominik Psenner wrote:
>
> > I'm working on LOG4NET-566, hoping that we can get a release build
> > from our CI.
>
> CI won't be able to create the oldkey binaries unless we are willing to
> make the old key public (which defeats the reason why the new key was
> introduced in the first place.
>
That's not necessarily true. There are ways to inject confidential
information
into the CI pipeline. Still, everyone having access to the jenkins
configuration
may get hold of the private key, though. We still have to option to not
build the
old key binaries any longer or build them manually and add them to the
release
during the release process.
>
> > The build currently gets stuck because of an unknown reason. It would
> > be great to get some help on finding out why the heck the
> > netstandard-1.3 tests behave as they do here:
>
> Currently I'm not able to build .NET Standard 1.3 at all, I'll need to
> create a new VM for that, I guess.
The zoo of infrastructure needed to build a log4net release is insane.
> All my .NET Standard builds have
> happened on Windows in the past, maybe the issue you see is specific to
> Linux?
>
If that's the case, the situation is even worse than I hoped it would be.
This would
mean that the log4net binaries that should support netstandard-1.3 do not
work as
they should when run on linux. We probably should run the netstandard tests
both on windows and linux to know more. The jenkins pipeline allows us to
do so.
It is a matter of adding a new stage to the build pipeline.
--
Dominik Psenner
Re: [log4net] release 2.0.9
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-01-12, Dominik Psenner wrote:
> I'm working on LOG4NET-566, hoping that we can get a release build
> from our CI.
CI won't be able to create the oldkey binaries unless we are willing to
make the old key public (which defeats the reason why the new key was
introduced in the first place.
> The build currently gets stuck because of an unknown reason. It would
> be great to get some help on finding out why the heck the
> netstandard-1.3 tests behave as they do here:
Currently I'm not able to build .NET Standard 1.3 at all, I'll need to
create a new VM for that, I guess. All my .NET Standard builds have
happened on Windows in the past, maybe the issue you see is specific to
Linux?
Stefan
Re: [log4net] release 2.0.9
Posted by Dominik Psenner <dp...@apache.org>.
I'm working on LOG4NET-566, hoping that we can get a release build from
our CI. The build currently gets stuck because of an unknown reason. It
would be great to get some help on finding out why the heck the
netstandard-1.3 tests behave as they do here:
https://builds.apache.org/job/logging-log4net/job/feature%252Fcd-pipeline/189/console
There are failing tests and the test process somehow gets stuck and is
only killed by the 4 hour timeout of the build pipeline.
On 2018-01-08 22:44, Dominik Psenner wrote:
> Hi,
>
> quite some time passed by since we last made a release and there are a few
> issues that have been fixed and should be shipped as part of a release. So
> this is my call for help.
>
> There are a few things on the to do list:
>
> - check jira for issues that can be closed as won't fix
> - check jira for issues that make sense to be part of the next release and
> qualify as "easily fixed"
> - check jira for issues that have been resolved and where "fixed version"
> is not 2.0.9
> - check the tests against the netstandard-1.3 target; looks like they've
> not been run by the build scripts during the last release and I've a bad
> feeling there might be dragons. Ideally we finish the build pipeline to get
> a better feeling
> - prepare the codebase for a release
> - properly test the release
> - make the release
>
> Please note that this checklist might not be complete at all.
>
> There are also a few things that I absolutely see not ready for 2.0.9:
>
> - add support for the netstandard-2.0 target; the way how netstandard-2.0
> target was added drops the tests for netstandard-1.3 and that's far from
> how it should be
>
> At the moment I've little to no spare time to get all this work done and do
> the release. Is there someone out there who offers his/her help?
>
> Best regards