Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-13, Dominik Psenner wrote:

> On 08/12/2011 10:46 PM, Dominik Psenner wrote:
>> I actually just cloned the apache svn and am currently pushing the
>> changes to a bitbucket repository here:

>> https://bitbucket.org/NachbarsLumpi/log4net

> FWIW, I managed to apply some of the patches that were submitted into a
> fork of the just created log4net clone:

> https://bitbucket.org/NachbarsLumpi/log4net-patches/changesets

> For now they're just placed on top of the svn revisions that those
> patches apply to.

Great.

> For each of them we have to:

>  * see if the patches are not fixed already
>  * see if they fit into the current latest tip (trunk)
>  * revise if they include sane changes
>  * determine if they should be included in the upcoming release

If you do any of these, could you note it as a comment inside the
corresponding JIRA tickets?  This would reduce the chance of people
duplicating work.

Thanks!

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Dominik Psenner wrote:

> The operation could take some time. Once it is done, there should be 553
> changesets. The last would be:

> changeset:   553:7f145743e63e
> tag: tip
> user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
> date:Wed Oct 13 03:26:57 2010 +
> summary: Additional fix for LOG4NET-59 to ensure correct call to
> System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

Yes, this should be the current trunk version.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Dominik Psenner wrote:

> On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
>> Short term we'll be slowed down by the fact that there are only very few
>> people with write access to the source tree, of course.

> Could the short term development be done in a remote repository,
> likewise hg hosted on bitbucket?

We do have a read-only git version at git://git.apache.org/log4net.git
 mirrored at github as well


Given that svn is new to some of the people who raised their hand to
help I'm a bit reluctant to add yet another tool new to them to the mix
(and throw in something like git-svn or hg-svn on top of that).  Combine
that with the change in philosophy a distributed VCS brings.

> One would not need to have write access to the original source and can
> still work versioned. If one keeps a strict linear history (no
> merges), one should also be able to push changes back to the svn
> repository.

I agree this would work and would be willing to give it a try with
people who want to work that way.  But this really depends on the people
who will actually do the commit to svn (which I currently can't do
myself either).

Thanks for setting up the hg mirror.

   Stefan

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 10:46 PM, Dominik Psenner wrote:
> I actually just cloned the apache svn and am currently pushing the
> changes to a bitbucket repository here:
> 
> https://bitbucket.org/NachbarsLumpi/log4net

FWIW, I managed to apply some of the patches that were submitted into a
fork of the just created log4net clone:

https://bitbucket.org/NachbarsLumpi/log4net-patches/changesets

For now they're just placed on top of the svn revisions that those
patches apply to. For each of them we have to:

 * see if the patches are not fixed already
 * see if they fit into the current latest tip (trunk)
 * revise if they include sane changes
 * determine if they should be included in the upcoming release

Best regards
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 10:30 PM, Dominik Psenner wrote:
> On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
>> Short term we'll be slowed down by the fact that there are only very few
>> people with write access to the source tree, of course.
> 
> Could the short term development be done in a remote repository,
> likewise hg hosted on bitbucket? One would not need to have write access
> to the original source and can still work versioned. If one keeps a
> strict linear history (no merges), one should also be able to push
> changes back to the svn repository.

I actually just cloned the apache svn and am currently pushing the
changes to a bitbucket repository here:

https://bitbucket.org/NachbarsLumpi/log4net

The operation could take some time. Once it is done, there should be 553
changesets. The last would be:

changeset:   553:7f145743e63e
tag: tip
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

Best regards
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
> Short term we'll be slowed down by the fact that there are only very few
> people with write access to the source tree, of course.

Could the short term development be done in a remote repository,
likewise hg hosted on bitbucket? One would not need to have write access
to the original source and can still work versioned. If one keeps a
strict linear history (no merges), one should also be able to push
changes back to the svn repository.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Tasos Vogiatzoglou wrote:

> I had submitted a patch about building log4net for 2010 (.NET 4 Client
> profile and .NET 4) which also fixes an issue in the UdpAppender.

> https://issues.apache.org/jira/browse/LOG4NET-296

There are a few indentation changes and the rest should be straight
forward to apply.  I may give a NAnt build for client profile a try at
one point.  NAnt doesn't specifically mention it would support the
client profile as target, though.

Is the one line fix in IPAddressConvert all that is needed for
UdpAppender?  If so we could do with conditional compilation here (use
GetHostByName for frameworks prior to 2.0 and GetHostEntry  for
framework 2.0+) and push that into 1.2.11.

Stefan

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Roy Chastain wrote:

>> Have you got an environment where you can build the 1.x and compact
>> framework assemblies (right now I don't)?

> I could at one point a few years back, but probably not now.

The same is true for my own environment.

> I was referring more to just being able to get the source from the
> tree.  (For me getting anything SubVersion related working is a BIG
> step). :-)

Congrats, then. 8-)

> That was part my question about duplicating effort.  If changes need
> to be made to get an environment that supports building, there is no
> need for multiple people to tackle it at once.

This is true, but at least for the next release we'll need one
accessible for the release manager.

> In the past I converted the zipped source to VS 2010 keeping the 2.0
> framework target and made that work, but I did not work on tests etc.,
> so I don't know how valid my efforts were.

So far I still don't want to use VS at all but stick with the NAnt
build.  I'm not familiar enough with the express editions - does anybody
know whether VS 2010 Express supports setting the compilation target to
2.0?  We can't expect contributors to own one of the non-free editions.

>> just as an alternative distribution in addition to one signed with
>> the new non-secret key?

> Yes, both versions.  I think that is necessary to keep the 3rd party
> people running until they have time to switch to the new non-secret key.

OK, then we agree.

>> Otherwise 1.2.11 is long overdue anyway

> Yes, I agree, that is way I was suggesting doing the "minimum" which is
> basically integrating the currently supplied/tested/gold fixes and
> features (such as the log file renaming feature-fix).  Feature requests
> and fixes that need work go into the 4.0 build tree (and the refactored
> 3.5 build tree which was my step 4).  This approach should allow for an
> "easy" (not hardly) production of the 1.2.11 that would be a drop in for
> anyone on 1.2.10 with the fixes/features that have been tested.

Yes.

> Maybe we have to revisit the bug/feature list and produce 1.2.12 with
> the next round before going on to 2.0 tree with less frameworks.  Once
> we do the 2.0 tree the 1.2.xx tree is frozen and we have less to
> maintain because we do not have to worry about 1.0, 1.1, compact etc.
> To sum up this paragraph, we produce a new stable long life span
> product (1.2.11 or 1.2.12) that people who do not wish to/cannot move
> forward can use for a long time to come.

Sounds good to me.

Stefan

Re: Moving forward with updates, builds and versions

[Tasos Vogiatzoglou]

Roy,

I had submitted a patch about building log4net for 2010 (.NET 4 Client
profile and .NET 4) which also fixes an issue in the UdpAppender.

https://issues.apache.org/jira/browse/LOG4NET-296

I'd be really glad to see this working and I could help in any direction needed.

Regards
Tasos Vogiatzoglou



On Fri, Aug 12, 2011 at 8:40 PM, Roy Chastain  wrote:
>>> Have you got an environment where you can build the 1.x and compact
> framework assemblies (right now I don't)?
> I could at one point a few years back, but probably not now.  I was
> referring more to just being able to get the source from the tree.  (For
> me getting anything SubVersion related working is a BIG step). :-)  That
> was part my question about duplicating effort.  If changes need to be
> made to get an environment that supports building, there is no need for
> multiple people to tackle it at once.
>
> In the past I converted the zipped source to VS 2010 keeping the 2.0
> framework target and made that work, but I did not work on tests etc.,
> so I don't know how valid my efforts were.
>
>>> just as an alternative distribution in addition to one signed with
> the new non-secret key?
> Yes, both versions.  I think that is necessary to keep the 3rd party
> people running until they have time to switch to the new non-secret key.
>
>>> Otherwise 1.2.11 is long overdue anyway
> Yes, I agree, that is way I was suggesting doing the "minimum" which is
> basically integrating the currently supplied/tested/gold fixes and
> features (such as the log file renaming feature-fix).  Feature requests
> and fixes that need work go into the 4.0 build tree (and the refactored
> 3.5 build tree which was my step 4).  This approach should allow for an
> "easy" (not hardly) production of the 1.2.11 that would be a drop in for
> anyone on 1.2.10 with the fixes/features that have been tested.  Maybe
> we have to revisit the bug/feature list and produce 1.2.12 with the next
> round before going on to 2.0 tree with less frameworks.  Once we do the
> 2.0 tree the 1.2.xx tree is frozen and we have less to maintain because
> we do not have to worry about 1.0, 1.1, compact etc.  To sum up this
> paragraph, we produce a new stable long life span product (1.2.11 or
> 1.2.12) that people who do not wish to/cannot move forward can use for a
> long time to come.
>
>>> How would that be different from the first step - except that we'd
> distribute fewer
>>> assemblies in the binary distribution?  Do you plan to remove all
> 1.0/1.1 specific code
>>> and the conditional compilations for NET 2.0 so that this release
> actually used different >> source code?
> Yes, fewer assemblies in the distribution.  No great effort to be
> expended in removing the old code, but if you happen to be in the area,
> you could delete it just to clean up the code base, and we certainly
> would not have to worry about it breaking.
> We may not need this step.  Again a poll question "Does anyone need
> xx,xy,xz... framework support?"  If not, we skip it and move to the 4.0
> or 3.5 tree as dictated by the poll.
>
> --
> Roy Chastain
>
>
>
>
> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: Friday, August 12, 2011 13:20
> To: log4net-dev@logging.apache.org
> Subject: Re: Moving forward with updates, builds and versions
>
> On 2011-08-12, Roy Chastain wrote:
>
>> I have finally gotten an environment allows me to get source etc.
>
> Great.
>
> Have you got an environemt where you can build the 1.x and compact
> framework assemblies (right now I don't)?  SSCLI?
>
>> My questions are of the following types
>> 1) - Do we have a plan?
>
> Not yet.  8-)
>
> Your list matches my ideas pretty well.
>
>> 2) - How do we prevent duplication of effort?
>
> This list, wiki, JIRA.  Right now it doesn't look to me as if we had so
> many people that we could lose track.
>
> Short term we'll be slowed down by the fact that there are only very few
> people with write access to the source tree, of course.
>
>> 3) - Someone mentioned a poll.  I would be glad to setup a survey on
>> my SharePoint site.
>
> Thanks.
>
>> I have seen the discussions on public vs. private signing key.  I
>> second the idea of switching to a publicly usable key, but maintain
>> the private key for a "release" build so that the 3rd party vendors
>> have something to reference.  I am sure that some of them will require
>
>> strongly names assemblies.
>
> You mean you'd still want to use a secret key for "release" in either
> case or just as an alternative distribution in addition to one signed
> with the new non-secret key?
>
>> I have seen the discussion on our first steps, but I have not observed
>
>> a consensus.  I would lay out the following as our steps.
>> 1) - Produce the 1.2.11 build with all currently available fixes.
>> Signed with the old key and all the current platforms.
>
> +1
>
> I'd suggest we triage JIRA to see whether 

RE: Moving forward with updates, builds and versions

[Roy Chastain]

>> Have you got an environment where you can build the 1.x and compact
framework assemblies (right now I don't)?
I could at one point a few years back, but probably not now.  I was
referring more to just being able to get the source from the tree.  (For
me getting anything SubVersion related working is a BIG step). :-)  That
was part my question about duplicating effort.  If changes need to be
made to get an environment that supports building, there is no need for
multiple people to tackle it at once.

In the past I converted the zipped source to VS 2010 keeping the 2.0
framework target and made that work, but I did not work on tests etc.,
so I don't know how valid my efforts were.

>> just as an alternative distribution in addition to one signed with
the new non-secret key?
Yes, both versions.  I think that is necessary to keep the 3rd party
people running until they have time to switch to the new non-secret key.

>> Otherwise 1.2.11 is long overdue anyway
Yes, I agree, that is way I was suggesting doing the "minimum" which is
basically integrating the currently supplied/tested/gold fixes and
features (such as the log file renaming feature-fix).  Feature requests
and fixes that need work go into the 4.0 build tree (and the refactored
3.5 build tree which was my step 4).  This approach should allow for an
"easy" (not hardly) production of the 1.2.11 that would be a drop in for
anyone on 1.2.10 with the fixes/features that have been tested.  Maybe
we have to revisit the bug/feature list and produce 1.2.12 with the next
round before going on to 2.0 tree with less frameworks.  Once we do the
2.0 tree the 1.2.xx tree is frozen and we have less to maintain because
we do not have to worry about 1.0, 1.1, compact etc.  To sum up this
paragraph, we produce a new stable long life span product (1.2.11 or
1.2.12) that people who do not wish to/cannot move forward can use for a
long time to come.

>> How would that be different from the first step - except that we'd
distribute fewer
>> assemblies in the binary distribution?  Do you plan to remove all
1.0/1.1 specific code
>> and the conditional compilations for NET 2.0 so that this release
actually used different >> source code?
Yes, fewer assemblies in the distribution.  No great effort to be
expended in removing the old code, but if you happen to be in the area,
you could delete it just to clean up the code base, and we certainly
would not have to worry about it breaking.
We may not need this step.  Again a poll question "Does anyone need
xx,xy,xz... framework support?"  If not, we skip it and move to the 4.0
or 3.5 tree as dictated by the poll.

--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Friday, August 12, 2011 13:20
To: log4net-dev@logging.apache.org
Subject: Re: Moving forward with updates, builds and versions

On 2011-08-12, Roy Chastain wrote:

> I have finally gotten an environment allows me to get source etc.

Great.

Have you got an environemt where you can build the 1.x and compact
framework assemblies (right now I don't)?  SSCLI?

> My questions are of the following types
> 1) - Do we have a plan?

Not yet.  8-)

Your list matches my ideas pretty well.

> 2) - How do we prevent duplication of effort?

This list, wiki, JIRA.  Right now it doesn't look to me as if we had so
many people that we could lose track.

Short term we'll be slowed down by the fact that there are only very few
people with write access to the source tree, of course.

> 3) - Someone mentioned a poll.  I would be glad to setup a survey on 
> my SharePoint site.

Thanks.

> I have seen the discussions on public vs. private signing key.  I 
> second the idea of switching to a publicly usable key, but maintain 
> the private key for a "release" build so that the 3rd party vendors 
> have something to reference.  I am sure that some of them will require

> strongly names assemblies.

You mean you'd still want to use a secret key for "release" in either
case or just as an alternative distribution in addition to one signed
with the new non-secret key?

> I have seen the discussion on our first steps, but I have not observed

> a consensus.  I would lay out the following as our steps.
> 1) - Produce the 1.2.11 build with all currently available fixes.
> Signed with the old key and all the current platforms.

+1

I'd suggest we triage JIRA to see whether there are any open issues that
(1) are bugs and not feature requests, (2) come with tests that fail and
(3) come with a patch that makes the test pass.  If there are any such
issues they could go into 1.2.11 IMHO.  Otherwise 1.2.11 is long overdue
anyway.

> 2) - Move to a 2.0 build tree that drops support for .NET 1.0, 1.1, 
> Compact etc.  Produce a release with the same fixes as the 1.2.11 
> build and sign with the old private key.

How would that be different from the first step - except that we'd
distribute fewer 

Re: Moving forward with updates, builds and versions

[Stefan Bodewig]

On 2011-08-12, Roy Chastain wrote:

> I have finally gotten an environment allows me to get source etc.

Great.

Have you got an environemt where you can build the 1.x and compact
framework assemblies (right now I don't)?  SSCLI?

> My questions are of the following types
> 1) - Do we have a plan?

Not yet.  8-)

Your list matches my ideas pretty well.

> 2) - How do we prevent duplication of effort?

This list, wiki, JIRA.  Right now it doesn't look to me as if we had so
many people that we could lose track.

Short term we'll be slowed down by the fact that there are only very few
people with write access to the source tree, of course.

> 3) - Someone mentioned a poll.  I would be glad to setup a survey on my
> SharePoint site.

Thanks.

> I have seen the discussions on public vs. private signing key.  I second
> the idea of switching to a publicly usable key, but maintain the private
> key for a "release" build so that the 3rd party vendors have something
> to reference.  I am sure that some of them will require strongly names
> assemblies.

You mean you'd still want to use a secret key for "release" in either
case or just as an alternative distribution in addition to one signed
with the new non-secret key?

> I have seen the discussion on our first steps, but I have not observed a
> consensus.  I would lay out the following as our steps.
> 1) - Produce the 1.2.11 build with all currently available fixes.
> Signed with the old key and all the current platforms.

+1

I'd suggest we triage JIRA to see whether there are any open issues that
(1) are bugs and not feature requests, (2) come with tests that fail and
(3) come with a patch that makes the test pass.  If there are any such
issues they could go into 1.2.11 IMHO.  Otherwise 1.2.11 is long overdue
anyway.

> 2) - Move to a 2.0 build tree that drops support for .NET 1.0, 1.1,
> Compact etc.  Produce a release with the same fixes as the 1.2.11 build
> and sign with the old private key.

How would that be different from the first step - except that we'd
distribute fewer assemblies in the binary distribution?  Do you plan to
remove all 1.0/1.1 specific code and the conditional compilations for
NET 2.0 so that this release actually used different source code?

> 3) - Start the 4.0 build tree (match the framework level) which targets
> the 4.0 Framework and is refactored so that it can run with a Client
> only framework when the non-Client support namespaces are not required
> by the application or requested appender.  (2 DLLs).  This gets signed
> with the private key and the new public key (2 distribution packages.)
> This version will support 4.0 and up only.

Totally agreed that this is needed.

I'd poll for 3.5 support as well.

> (MONO if needed??)

Mono is at the 4.0 level in many things and not even at 3.5 in others.
For the things log4net currently uses it should work fine AFAICT.

> 4) - Apply the same refactoring to the 2.0 build tree to allow targeting
> the 3.5 Client install.  (I believe this is a lower priority than the
> 4.0 simply because I do not believe that many people have attempted
> deployment with the 3.5 client set.  (I could easily be wrong.)

Should have read to the end before I started typing ;-)

I'd prioritize your steps 3 and 4 with the help of a poll among users to
see how urgently 3.5 support is needed.  I agree I have seen way more
questions about 4.0 than 3.5, though.

Stefan

Moving forward with updates, builds and versions

[Roy Chastain]

I have finally gotten an environment allows me to get source etc.
My questions are of the following types
1) - Do we have a plan?
2) - How do we prevent duplication of effort?
3) - Someone mentioned a poll.  I would be glad to setup a survey on my
SharePoint site. I hope the points below are a starting point for
developing the questions to put into the survey. 

I have seen the discussions on public vs. private signing key.  I second
the idea of switching to a publicly usable key, but maintain the private
key for a "release" build so that the 3rd party vendors have something
to reference.  I am sure that some of them will require strongly names
assemblies.

I have seen the discussion on our first steps, but I have not observed a
consensus.  I would lay out the following as our steps.
1) - Produce the 1.2.11 build with all currently available fixes.
Signed with the old key and all the current platforms.

2) - Move to a 2.0 build tree that drops support for .NET 1.0, 1.1,
Compact etc.  Produce a release with the same fixes as the 1.2.11 build
and sign with the old private key.

3) - Start the 4.0 build tree (match the framework level) which targets
the 4.0 Framework and is refactored so that it can run with a Client
only framework when the non-Client support namespaces are not required
by the application or requested appender.  (2 DLLs).  This gets signed
with the private key and the new public key (2 distribution packages.)
This version will support 4.0 and up only.  (MONO if needed??)

4) - Apply the same refactoring to the 2.0 build tree to allow targeting
the 3.5 Client install.  (I believe this is a lower priority than the
4.0 simply because I do not believe that many people have attempted
deployment with the 3.5 client set.  (I could easily be wrong.)

--
Roy Chastain

Build/Release instructions?

[Stefan Bodewig]

Hi,

I've checked out trunk and tried to build it and run tests using NAnt on
both my $work Win7 machine and my private Linux box.  I opened a few
JIRA tickets on the way.

Is there any document that I have missed on what I'm expected to have
installed if I want to do a full build that would be needed for a
release?

Right now the only framework I have installed is 4.0 (alongside VS2010
which I deliberately do not use to build log4net) and so NAnt only
builds the net/2.0 and net/3.5 assemblies.  I may be able to arrange
something for the older frameworks and compact versions at work (can't
promise anything, though) but would need to know what to install.

On the Mono side using Ubuntu and the Mono Project PPA works OK but I
get more than 50 failed unit tests - as opposed to the about ten failed
tests I get on Windows using MS .NET.  What are the expectations for
Mono support?

Stefan