You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Roy Chastain <Ro...@roychastain.org> on 2011/08/12 18:29:21 UTC
Moving forward with updates, builds and versions
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
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by Tasos Vogiatzoglou <tv...@gmail.com>.
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 <Ro...@roychastain.org> 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:bodewig@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 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
>
RE: Moving forward with updates, builds and versions
Posted by Roy Chastain <Ro...@roychastain.org>.
>> 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:bodewig@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 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
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
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 +0000
> 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
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Dominik Psenner wrote:
> On 08/13/2011 06:34 AM, Stefan Bodewig wrote:
>>> 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.
> Sure thing. Can we place some other comments somewhere so that others
> can find out that there's a repository they could actually work on?
We could do so, but right now I'd be happy if we could get to work
within the existing processes - patch attached to JIRA, commit to svn -
any time soon.
I'd really hope there will be lots of "others" but so far I'm not
convinced we'll be overwhelmed by new contributors. I'd love to be
proven wrong.
> I'm afraid I don't have the time to actually hack on log4net.
See ;-)
> But I could help with what I'm good at: lever some of the major data
> migration work to smooth the way for others that need a repository.
Many thanks for that.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
On 08/13/2011 06:34 AM, Stefan Bodewig wrote:
>> 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.
Sure thing. Can we place some other comments somewhere so that others
can find out that there's a repository they could actually work on?
I'm afraid I don't have the time to actually hack on log4net. But I
could help with what I'm good at: lever some of the major data migration
work to smooth the way for others that need a repository.
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
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
Posted by Dominik Psenner <dp...@gmail.com>.
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 #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
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 +0000
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 #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Stefan Bodewig wrote:
> svn is pretty similar to TFS
The version control part of TFS that is.
There are differences but both have similar (limited) support for merge
tracking, perform branching in the file-system space (i.e. copy a trunk
dir to a branches/X_Y_Z dir) and both are typical instances of a
centralized version control system and share quite a few concepts.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-15, Dominik Psenner wrote:
> On 08/15/2011 11:39 AM, Stefan Bodewig wrote:
>> If we get back on track with regular releases the occasional trunk
>> breakage will be OK as people won't be forced to use arbitrary trunk
>> revisions.
> No, it is not OK at all. IMHO every recorded history should be a
> monolithic working library. Only if you do that you make sure that every
> release is just fine because if you don't, people will make errors and
> people will forget some thing or the other.
Here we'll have to agree that we disagree. I will make errors, trunk
will occasionally be broken. We have a mailing list that receives
notifications of all changes that went into svn and my fellow committers
review my changes. We have a CI system (well, not really in the case of
log4net, this will be fixed sooner or later) that will call me off it I
break things in a way it can detect. We do all we can to ensure trunk
works as well as possible but it is bleeding edge code.
Not that we'd guarentee our releases work any better.
The real solution is to have more releases to get bugfixes out quicker.
> "Ok, I'm done with it, for now I commit it and tomorrow I'll fix the
> special case".
This is rare, and if it happens I leave a comment in source code and
likely even a failing but skipped unit test. YMMV.
> If patches don't get revised, it results exactly in the situation we
> have in log4net right now:
I never said patches wouldn't be revised, at least I hope I never said
so. They must just get revised after I have committed them The "commit
then review" model is working well among many projects.
Only very few ASF project follow the alternative "review then commit"
model - Tomcat and httpd do so for their "stable" branches. For this we
do have tools like reviewboad at the ASF but I've never used it.
> 101 revisions since the last release and nobody knows whether those
> "fixes" do really fix the issues or those revisions are safe to include
> in the next release because there are no unit tests. I don't think
> that's funny.
No it isn't, fortunately it isn't all that bad as many changes comes
with unit tests or are directly connected to JIRA tickets and most
changes are pretty small - this is from my cursory look, you may have
looked closer than myeself.
If anything it points out that we may want to diff currennt trunk
against the latest released code just to be sure we actually know what
type of changes we are pushing out.
The reason that "nobody knows" is neither svn nor JIRA nor the way you
or I or anybody else who is willing to help the project now wants to
work, though.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
On 08/15/2011 11:39 AM, Stefan Bodewig wrote:
> If we get back on track with regular releases the occasional trunk
> breakage will be OK as people won't be forced to use arbitrary trunk
> revisions.
No, it is not OK at all. IMHO every recorded history should be a
monolithic working library. Only if you do that you make sure that every
release is just fine because if you don't, people will make errors and
people will forget some thing or the other.
"Ok, I'm done with it, for now I commit it and tomorrow I'll fix the
special case".
If patches don't get revised, it results exactly in the situation we
have in log4net right now:
101 revisions since the last release and nobody knows whether those
"fixes" do really fix the issues or those revisions are safe to include
in the next release because there are no unit tests. I don't think
that's funny.
If there's the risk that your logging dll crashes a software responsible
to do your money transfers just because some patch was included that
shouldn't have been, the fun ends for sure.
Well, maybe I'm overdoing it a little but IMHO a library that is well
spread should be developed "safe".
>> Indeed the history how a single patch evolves is not at ASF, but since
>> patches should be sent to the mailing list
>
> Nope. JIRA.
Then the medium to transfer a patch is JIRA and not the mailing list.
Doesn't change much, does it? :-)
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-15, Dominik Psenner wrote:
> On 08/15/2011 07:26 AM, Stefan Bodewig wrote:
>> I think it is important for us all, that we do have a single place with
>> the code to discuss - and once we have enough people with write access
>> it won't be necessary to think about any other place than svn for this.
>> The "hg or git clone of svn" model works very well for the odd case of
>> people who want to contribute larger patches but don't have write access
>> themselves - which should be the exception.
> And it makes sense in cases where people work together on a bugfix
> without the need of spamming the svn log with stuff that doesn't work.
That's what I meant when I said the approach allows contributors to have
the advantage of revision control while developing the patch.
Most of our patches aren't really that big, though. There won't be much
back-and-forth. svn logs of failed attempts do provide some value as
well, BTW.
If there is anything bigger to develop, a svn branch can work as well -
contrary to popular belief, svn does support branching and merge
tracking and it isn't all bad. Note, the ASF has used and survived CVS
before. ;-)
> Right now the most useful log4net that people use is the svn trunk. We
> shouldn't break it!
If we get back on track with regular releases the occasional trunk
breakage will be OK as people won't be forced to use arbitrary trunk
revisions.
> Indeed the history how a single patch evolves is not at ASF, but since
> patches should be sent to the mailing list
Nope. JIRA.
> and discussed there (mbox extension) it is not that far from ASF at
> all.
> Please correct me if I'm wrong.
No, you are not wrong per se. But for simple cases it is more complex
than what I'd do otherwise.
Looking through your explanations how to review certain patches I
thought the old fashioned way would be way easier for anybody with svn
write access.
My typical workflow for any other ASF project is
* read the bug report and the attached patch
* if it looks reasonable, apply the patch to my local working copy of
svn trunk (that's patch -p0 < patchfile).
* rebuild the tests, run them and watch them fail
* rebuild main code base, rebuild the test, run all tests and watch them
pass
* commit
Of course this is an oversimolification and I may very well stop at
"read the patch". And TBH many times I drop the patch, apply only the
tests and write a different fix myself - and even more often there is no
test and no patch at all. In the case of no patch and no tests it
doesn't matter that the only repo I have is svn.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
On 08/15/2011 07:26 AM, Stefan Bodewig wrote:
> I think it is important for us all, that we do have a single place with
> the code to discuss - and once we have enough people with write access
> it won't be necessary to think about any other place than svn for this.
>
> The "hg or git clone of svn" model works very well for the odd case of
> people who want to contribute larger patches but don't have write access
> themselves - which should be the exception.
And it makes sense in cases where people work together on a bugfix
without the need of spamming the svn log with stuff that doesn't work.
Right now the most useful log4net that people use is the svn trunk. We
shouldn't break it!
Indeed the history how a single patch evolves is not at ASF, but since
patches should be sent to the mailing list (patchbomb extension) and
discussed there (mbox extension) it is not that far from ASF at all.
Please correct me if I'm wrong.
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-15, Curt Arnold wrote:
> Code development at the ASF should be done in the open and not in a
> private branch that unveiled to the community (has happened in the
> past) as that basically prevents anyone else from influencing the work
> while in process.
To be fair, this is not what Dominik suggested. The mercurial branches
would be in the open just as the svn tree is and it would be even more
inclusive in a way as everybody could create a branch of his/her own
with write access immediately.
> Code should go into the SVN as it is developed so there can be
> feedback, etc. Which someones means there will be code that was bad,
> buggy, undesirable, etc, but that always can be undone.
I think it is important for us all, that we do have a single place with
the code to discuss - and once we have enough people with write access
it won't be necessary to think about any other place than svn for this.
The "hg or git clone of svn" model works very well for the odd case of
people who want to contribute larger patches but don't have write access
themselves - which should be the exception.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Curt Arnold <ca...@apache.org>.
I currently have commit rights and I'm working the process right now to add additional help though the process takes a certain amount of time. Expect an announcement on Wednesday.
Code development at the ASF should be done in the open and not in a private branch that unveiled to the community (has happened in the past) as that basically prevents anyone else from influencing the work while in process. Code should go into the SVN as it is developed so there can be feedback, etc. Which someones means there will be code that was bad, buggy, undesirable, etc, but that always can be undone. The essential aspect that a committer is to ensure is that the code is either his own independent work or there is a clear record of an intent to contribute by the original author (typically in a JIRA bug report or an email on a archived mailing list). It is not a wonderful thing to break a build etc, but that is not a huge thing in the big picture.
I'm going to try to commit some of the JIRA issues that were recently commented upon.
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
I forgot to say that this workflow works just great even for the time we
have no write privileges on the SVN repository. The changesets will be
stuck at "log4net-crew", waiting there to be pushed to the svn repository.
Best regards
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-14, Dominik Psenner wrote:
> sorry for the late response. This sunny sunday took me for a trip into
> the mountains. :-) See the inlines below.
I live further up north in Germany (guessing from your name) so it
hasn't been as sunny around here 8-(
>> The normal state of an ASF project is that all people who contribute
>> code on a regular basis have write access - if they want it.
> I would not advise to commit to the ASF SVN repository directly. Changes
> put into SVN are carved into stone and immutable FOREVER. Mercurial
> allows a more flexible way for working on things. Just read this mail to
> the end to get there. :-)
I did, and I'm sorry that won't happen as it simply is not the way ASF
projects operate. Immutable history actually is an asset.
One thing I've noticed when following github projects and similar
constructs has been that they have a hard time building a real
community. Too much focus is put on code and branches and not much on
agreeing how to move forward and actually collaborating. It is too easy
to simply create your own branch, go off and say "I know better" rather
than search for a compromise. Yes, I am oversimplifying and
generalizing here.
The ASF model forces all people working on the project to build
consensus on what goes into the project. This helps to have a real
community behind the code base - *the* code base as there is only one.
And a community rather than a few single devs who know better is what
makes a project sustainable and allows it to survive if the original
devs go away.
I really do appreciate what you've set up and I do understand the model
you describe has advantages and disadvantages over how the ASF works
traditionally, but it is at odds with the ideals of the ASFs in some
areas.
> You may ask yourself how we can discuss on a changeset if the others
> don't know about it? Mercurial offers some very convenient ways to share
> information between developers. One is to publish the information in a
> repository so that others can pull that information into their local
> clone (that's how mercurial works after all) or the other way would be
> to mail a patch to this list so that others can import it and comment on it.
See, we prefer to discuss on the mailing list - not in JIRA and not in
code via patches. Discussions in plain English (or what people like me
consider English ;-) are easier to follow when you want to revisit them
five years later. Yes, this happens. The "why did we decide to use X
instead of Y" questions do come up.
>> The normal process is that a committer resolves the JIRA issue once the
>> code is in svn. Sometimes the user who opened the issue will close it
>> after the fix has been verified but this is truely optional.
> Yes. Right now we can only comment on issues, which is obviously not
> enough to be productive. We should contact some people @ JIRA so that at
> least one of us gets write privileges to the repository and
> administrative privileges to the bugtracker ASAP.
This is on the way.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
Hi Stefan and Roy,
sorry for the late response. This sunny sunday took me for a trip into
the mountains. :-) See the inlines below.
> The normal state of an ASF project is that all people who contribute
> code on a regular basis have write access - if they want it.
I would not advise to commit to the ASF SVN repository directly. Changes
put into SVN are carved into stone and immutable FOREVER. Mercurial
allows a more flexible way for working on things. Just read this mail to
the end to get there. :-)
I know this may be a bit much information and it could feel like "uoh,
what the heck does this guy mean - do I have to learn all these
things?", but it's not really complicated and the learning curve should
be exponential. So I get straight to the next topic:
> But once the people who would be working "in connected mode" in a
> distributed VCS have been doing it for long enough that the existing
> committers have gained enough trust the whole thing won't be necessary
> any longer. The people who stick around long enough will get write
> access to svn sooner or later.
The main goal is to keep the SVN trunk stable and safe in every
revision. Since the SVN repository history is immutable, this means that
only revised and "good" patches are put there.
Therefore I would like to propose a different workflow that works just
great when working in a team. Think of "log4net", "log4net-crew" and
"log4net-developer" as repositories. The "log4net-developer" repository
will actually exist for every developer and maybe even multiple times if
one developer works on more than one issue. The flow of data is basically:
log4net <--> log4net-crew --> log4net-developer
^ |
| v
apply patch <-- discuss patch
What does that mean for us? Each developer has a local clone
(log4net-developer) of the repository log4net-crew and works on that
clone to fix an issue. The changesets produced there can then be
discussed by other developers and once - let's say - more than half of
the developers agree on how things are done, the patch is applied to
log4net-crew and subsequently put back into the log4net SVN @ apache.
You may ask yourself how we can discuss on a changeset if the others
don't know about it? Mercurial offers some very convenient ways to share
information between developers. One is to publish the information in a
repository so that others can pull that information into their local
clone (that's how mercurial works after all) or the other way would be
to mail a patch to this list so that others can import it and comment on it.
One could export a patch and then send it manually to this list:
$ hg export rev > patch.diff
Or he can use the patchbomb extension that does exactly this in a oneliner:
$ hg email rev
Now other developers can import the patch manually:
$ hg import patch.diff
or use again an extension called Mbox that does the reverse operation of
Patchbomb in a oneliner:
$ hg mimport
Finally the other developer revises the changesets and provides feedback
on the mailing list. Once every on agrees it is really easy to put the
changes to the log4net-crew repository:
$ hg push log4net-crew
And from the crew repository, whoever has write privileges on the svn,
can do:
$ hg pull log4net-crew
$ hg push log4net
Obviously I stripped some information on how one has to set up things,
but rest assured that I'm going to provide that information if you ask
for it.
Last but not least I want to mention some useful links. The most
interesting things should be written down here (without the chapter
about Fabric):
http://www.satchmoproject.com/blog/2010/feb/27/satchmo-workflow/
and more general information on mercurial can be found here:
http://mercurial.selenic.com/wiki/QuickStart
But that wiki contains also more information. For example the
installation and usage of extensions that this kind of workflow need are
well documented there:
http://mercurial.selenic.com/wiki/RebaseExtension
http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/MboxExtension
http://mercurial.selenic.com/wiki/PatchbombExtension
And there's a more than useful windows client called TortoiseHG
(http://tortoisehg.bitbucket.org/) that eases the commandline hacking
with a nice userinterface (even mq, patchbomb and other things).
Feel free to ask if you feel you need to!
> The normal process is that a committer resolves the JIRA issue once the
> code is in svn. Sometimes the user who opened the issue will close it
> after the fix has been verified but this is truely optional.
Yes. Right now we can only comment on issues, which is obviously not
enough to be productive. We should contact some people @ JIRA so that at
least one of us gets write privileges to the repository and
administrative privileges to the bugtracker ASAP.
Best regards,
D.
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Roy Chastain wrote:
> My immediate takeaway is that by using a distributed VCS we have the
> capabilities that I am more used to in that we are working "connected"
> instead of "disconnected" with the connection blocker being someone who
> can commit in SVN on ASF.
Yes, BUT.
But once the people who would be working "in connected mode" in a
distributed VCS have been doing it for long enough that the existing
committers have gained enough trust the whole thing won't be necessary
any longer. The people who stick around long enough will get write
access to svn sooner or later.
The normal state of an ASF project is that all people who contribute
code on a regular basis have write access - if they want it.
> Is how do we track what we are doing so that the correct info gets into
> JIRA or is that the committers job to fix JIRA as he/she commit our
> code?
The normal process is that a committer resolves the JIRA issue once the
code is in svn. Sometimes the user who opened the issue will close it
after the fix has been verified but this is truely optional.
Stefan
RE: Moving forward with updates, builds and versions
Posted by Roy Chastain <Ro...@roychastain.org>.
Thanks Stefan.
My immediate takeaway is that by using a distributed VCS we have the
capabilities that I am more used to in that we are working "connected"
instead of "disconnected" with the connection blocker being someone who
can commit in SVN on ASF.
Once we agree we have something that fits together, we throw it over the
wall to committer and hope they get to it in a reasonable timeframe.
If I got this right, it sounds like a good thing, so I need more
instructions/pointers as to where to even start.
Question:
Is how do we track what we are doing so that the correct info gets into
JIRA or is that the committers job to fix JIRA as he/she commit our
code?
----------------------------------------------------------------------
Roy Chastain
-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Saturday, August 13, 2011 11:18
To: log4net-dev@logging.apache.org
Subject: Re: Moving forward with updates, builds and versions
On 2011-08-13, Roy Chastain wrote:
>>> Who are those people? Maybe they should comment on this?
> I am one of those people. At this point I have minimal (if any)
> understanding of the actual patch insertion process, but given I don't
> have write privileges that is okay. I also have minimal/no
> understanding of how to apply patches that are not "committed" to
> something I am building. (I know I need to read the manual.) I have
> no allegiance to SVN other than I know I will face it again in the
> future.
I'll leave the distributed VCS part to Dominik as I think he's more
experienced in that area than myself (I'm a long time darcs user with
some git sprinkled in but have never used hg or Bitbucket myself).
Let me try to address the current process. My I assume you are familiar
with TFS?
svn is pretty similar to TFS with the major exception being that by
default the svn server doesn't track who has checked out what - all your
checkouts are local only. This also means "shared checkout" is the
default, it is possible to lock files but this is frowned upon. In the
eleven+ years I've been working on ASF code bases I've had less than 20
merge conflicts that I needed to resolve - in reality it is very rare
that two developers touch the same code at the same time. Commit early
and commit often.
I am a command line guy so I apply a patch by using the GNU patch
command from my Cygwin installation. Unfortunately I'm not familiar
with any alternatives to that.
The process is "download the patch from JIRA", "apply it to your working
copy", "build and test" and finally "commit".
> I thought it was a duplication of effort, but Stefan seems to think it
> may have merit, so what is the merit?
[once I was ready I realized I did talk about the DVCS part as well,
sorry. Dominik, please point out where I'm wrong or fill in what I've
forgotten to say.]
Basically using a site like Bitbucket allows others to have a public
workspace they have write access to. This gives those others the
advantage of revision control while they develop a feature/fix and gives
log4net devs the ability to say "no, don't do it that way, take a
different route" and play back and forth until all sides are satisfied.
Basing such a workspace on a read-only clone of the "master" svn tree
means that this public workspace can be kept in sync with log4net's
current code. The distributes VCSes are all pretty good at merging and
tracking what they have already merged.
Bitbucket, github, launchpad and similar sites make it easy to ship
patches from one workspace to another if they are related. Say Dominik
had prepared some code change in a workspace and he's ready then he can
ask the maintainer of a Bitbucket copy of log4net's svn tree to pull in
a certain set of changes - and the infrstructure will perform all
necessary merge steps if the request is accepted. A bridge from hg to
svn exists that would make it easy to then send the same changes to the
svn tree.
So what Dominik suggests is to enable a different workflow that is
proven and works well for people who are used to these tools. This
alternative is more agile and more interactive - several people could be
working together on a changeset that is going fix a given bug or
implement a given feature - than the "central source tree", "patches in
issue tracker", "committer as gateway" process we usually employ.
Stefan
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-13, Roy Chastain wrote:
>>> Who are those people? Maybe they should comment on this?
> I am one of those people. At this point I have minimal (if any)
> understanding of the actual patch insertion process, but given I don't
> have write privileges that is okay. I also have minimal/no
> understanding of how to apply patches that are not "committed" to
> something I am building. (I know I need to read the manual.) I have
> no allegiance to SVN other than I know I will face it again in the
> future.
I'll leave the distributed VCS part to Dominik as I think he's more
experienced in that area than myself (I'm a long time darcs user with
some git sprinkled in but have never used hg or Bitbucket myself).
Let me try to address the current process. My I assume you are familiar
with TFS?
svn is pretty similar to TFS with the major exception being that by
default the svn server doesn't track who has checked out what - all your
checkouts are local only. This also means "shared checkout" is the
default, it is possible to lock files but this is frowned upon. In the
eleven+ years I've been working on ASF code bases I've had less than 20
merge conflicts that I needed to resolve - in reality it is very rare
that two developers touch the same code at the same time. Commit early
and commit often.
I am a command line guy so I apply a patch by using the GNU patch
command from my Cygwin installation. Unfortunately I'm not familiar
with any alternatives to that.
The process is "download the patch from JIRA", "apply it to your working
copy", "build and test" and finally "commit".
> I thought it was a duplication of effort, but Stefan seems to think it
> may have merit, so what is the merit?
[once I was ready I realized I did talk about the DVCS part as well,
sorry. Dominik, please point out where I'm wrong or fill in what I've
forgotten to say.]
Basically using a site like Bitbucket allows others to have a public
workspace they have write access to. This gives those others the
advantage of revision control while they develop a feature/fix and gives
log4net devs the ability to say "no, don't do it that way, take a
different route" and play back and forth until all sides are satisfied.
Basing such a workspace on a read-only clone of the "master" svn tree
means that this public workspace can be kept in sync with log4net's
current code. The distributes VCSes are all pretty good at merging and
tracking what they have already merged.
Bitbucket, github, launchpad and similar sites make it easy to ship
patches from one workspace to another if they are related. Say Dominik
had prepared some code change in a workspace and he's ready then he can
ask the maintainer of a Bitbucket copy of log4net's svn tree to pull in
a certain set of changes - and the infrstructure will perform all
necessary merge steps if the request is accepted. A bridge from hg to
svn exists that would make it easy to then send the same changes to the
svn tree.
So what Dominik suggests is to enable a different workflow that is
proven and works well for people who are used to these tools. This
alternative is more agile and more interactive - several people could be
working together on a changeset that is going fix a given bug or
implement a given feature - than the "central source tree", "patches in
issue tracker", "committer as gateway" process we usually employ.
Stefan
RE: Moving forward with updates, builds and versions
Posted by Roy Chastain <Ro...@roychastain.org>.
>> Who are those people? Maybe they should comment on this?
I am one of those people. At this point I have minimal (if any)
understanding of the actual patch insertion process, but given I don't
have write privileges that is okay. I also have minimal/no
understanding of how to apply patches that are not "committed" to
something I am building. (I know I need to read the manual.) I have no
allegiance to SVN other than I know I will face it again in the future.
What are the advantages (and disadvantages) to what Dominik is
proposing? I have never dealt with BitBucket or any of the other items
mentioned. To be honest, when I first read the description, my eyes
started rolling as my brain said what is all this? I thought it was a
duplication of effort, but Stefan seems to think it may have merit, so
what is the merit?
Dominik, please understand that no insult is intended in any of my
comments above. They all stem from my lack of knowledge of the tools in
this space and mostly likely show my ignorance.
----------------------------------------------------------------------
Roy Chastain
-----Original Message-----
From: Dominik Psenner [mailto:dpsenner@gmail.com]
Sent: Saturday, August 13, 2011 03:56
To: log4net-dev@logging.apache.org
Subject: Re: Moving forward with updates, builds and versions
On 08/13/2011 06:30 AM, Stefan Bodewig wrote:
> We do have a read-only git version at git://git.apache.org/log4net.git
> <http://git.apache.org/log4net.git/> mirrored at github as well
> <https://github.com/apache/log4net>
Didn't know that. :-) Since that repository is read-only, it is not
exactly a great help for whoever wants to hack on log4net now.
>
> 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.
If they're new to svn, it would actually be no great effort to learn
another tool.
>
> 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).
Who are those people? Maybe they should comment on this?
Re: Moving forward with updates, builds and versions
Posted by Dominik Psenner <dp...@gmail.com>.
On 08/13/2011 06:30 AM, Stefan Bodewig wrote:
> We do have a read-only git version at git://git.apache.org/log4net.git
> <http://git.apache.org/log4net.git/> mirrored at github as well
> <https://github.com/apache/log4net>
Didn't know that. :-) Since that repository is read-only, it is not
exactly a great help for whoever wants to hack on log4net now.
>
> 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.
If they're new to svn, it would actually be no great effort to learn
another tool.
>
> 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).
Who are those people? Maybe they should comment on this?
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
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
<http://git.apache.org/log4net.git/> mirrored at github as well
<https://github.com/apache/log4net>
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
Posted by Dominik Psenner <dp...@gmail.com>.
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 #
##########################################################
Re: Moving forward with updates, builds and versions
Posted by Stefan Bodewig <bo...@apache.org>.
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