1. Unfortunately, the tests are not currently passing. I have been working
on getting them running again, but it will require more work yet, especially
those for appenders I am not familiar with.
2. Some of the tests need to run as admin because of the rights they
require. I think the appropriate API pages should be updated to indicate
this (for example EventLogAppender).
3. Ideally, additional tests should be written. The coverage is not as
extensive as it should be. For example, there are no tests for the IPv6
issues I have run into even though fixes were checked in. I am willing to
add tests.
4. We should also prioritize existing issues and get a small number of
blockers into the next release.

Lastly, and probably most importantly

5. We need the help of the existing team. As far as I can tell, Ron
Grabowski is the last active member.

Rob Prouse

-----Original Message-----
From: Patrick Earl [mailto:[email protected]] 
Sent: Thursday, August 05, 2010 2:14 PM
To: Log4NET Dev
Subject: Re: Client Profile Proposal

It seems like there's demand and people willing to make it happen.
What are the steps we need to take to make a release?

Here are some obvious ones...

1.  Build under all supported frameworks.
2.  Run tests under all supported frameworks.
3.  Update version number.
4.  Distribute packages.

        Patrick Earl

On Thu, Aug 5, 2010 at 8:17 AM, Roy Chastain <[email protected]> wrote:
> Patrick and Rob,
> I too would love to see progress in log4Net.  I currently make use of
> log4Net in over 10 commercial products.  While I don't need the Client
> Profile (as yet), I would certainly like to see a release with all the
> current fixes included targeting the 2.0 framework.  I too agree we
> should drop the 1.x framework and the CF going forward and should
> include the Client Profile as a target AFTER creating a stable release
> with the current fixes applied.  Just to through something else into the
> works.  Has anyone thought about a SilverLight version?  (Think Windows
> Mobile 7 and SilverLight outside the browser.)
>
> As yet, I have not seen any issues running log4Net in 4.0 frame
> applications on Server 2008 and Windows 7 etc.  I know that other people
> have reported issues, but they never have described the problems.  I
> only use three spenders (rolling, console and smtp) so it could be the
> other spenders have multi-framework issues.
>
> I have some time that I can spend helping update and test, but I have no
> skills whatsoever concerning the use of the version control system etc.
> The one time I tried to pull down a fix that I did (and still) need,
> things failed horribly.
>
> Bottom line, I am willing to be involved, but do know really know how to
> be involved.
>
> ----------------------------------------------------------------------
> Roy Chastain
>
>
>
>
> -----Original Message-----
> From: Rob Prouse [mailto:[email protected]]
> Sent: Thursday, August 05, 2010 09:33
> To: 'Log4NET Dev'
> Subject: RE: Client Profile Proposal
>
> Patrick,
>
> I second your request. I would also like to target the client profile,
> but can't.
>
> I have been talking offline with Ron Grabowski about kick starting
> development on log4net and getting another release out. Our company
> makes extensive use of log4net and some issues that have shown up with
> newer versions of Windows and of .NET have been causing problems for us.
> Log4net is an important project for many people, but I am seeing more
> and more people grumbling that it is dead. If our company was evaluating
> log4net today, we wouldn't touch it because of the lack of activity.
>
> Ron is busy and can't respond often, but he did list some concerns about
> a new release. Currently, log4net supports .NET 1.0, 1.1, 2.0, Compact
> Framework and a couple of versions of Mono. Developing and testing new
> releases for all of those platforms is time consuming. Personally, I
> think we should drop support for everything and just compile .NET 2.0
> and the latest version of Mono. I could also be convinced to maintain
> support for CF if anyone is actually using it, but even Microsoft has
> dropped support for it in VS2010. Anyone still developing on older
> versions of the framework can stick with the current version of log4net.
>
> Like you, I have offered to help out. I have been working away at fixing
> bugs that are important to me and have submitted one patch directly to
> Ron and attached some to issues. I admit though that I am taking it slow
> because I am seeing very little response and patches aren't much use if
> they don't get applied.
>
> Rob Prouse
>
> -----Original Message-----
> From: Patrick Earl [mailto:[email protected]]
> Sent: Thursday, August 05, 2010 5:13 AM
> To: [email protected]
> Subject: Client Profile Proposal
>
> Greetings.
>
> There have been a number of requests for client profile support for
> log4net.  Unfortunately no action has been taken so far.  This is
> causing some consternation in the NHibernate world at the moment.
> There is significant desire for a client profile version of NHibernate,
> but the dependency on log4net is preventing that right now.
>
> I have something of a plee / proposal to make.  I would be happy to do
> the work to eliminate the compile time dependency on System.Web using
> the following technique (or really any technique acceptable to the
> log4net team):
>
> 1.  Use fast forms of reflection to access the appropriate System.Web
> members.
> 2.  Don't split into multiple assemblies.  Obviously splitting would
> cause significant breakage for the next release and since it's easy to
> avoid, it should be avoided.
> 3.  Ensure there are zero breaking changes for all platforms supported
> by log4net.
>
> Unfortunately, to solve this conundrum, we are dependent on an updated
> release of log4net.  Is there any way we can get a release out the door
> with the code that would be provided to support the client profile?
>
> It's been a very long time since the last release.  Is additional
> assistance needed to make the release happen?
>
> Looking forward to some forward motion. :)
>
>         Patrick Earl
>
>

Reply via email to