Moving Forward
Hi all, it seems that so far we agree that the very next steps should be * release 1.2.11 ASAP. This should be current trunk plus all known good patches from JIRA that won't make it impossible to build for 1.0 or compact framework. I think it may be possible to provide client profile versions of this as well. * poll users which target platforms are actually needed. Am I correct with this? If so I think the major pieces of work for 1.2.11 release will be (1) setting up a build environment on anybody's machine that is suitable for a release build. (2) wade through all 160+ open tickets, look for good patches and assign them to 1.2.11. Anything that is not too urgent or doesn't contain a test should be pushed to a later release IMHO. Curt, can you create some more versions I JIRA (I don't have karma for this), I'd propose 1.2.MAINTENANCE to collect just what looks like a reasonable future patch but shouldn't go into 1.2.11 immediately. I volunteer to work on (1) but likely won't have any tangible results before in about three to four weeks. (2) could be done by all of us - at least those with the required permissions. Stefan
Re: Moving forward with updates, builds and versions
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 # ## signature.asc Description: OpenPGP digital signature
Re: Moving forward with updates, builds and versions
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
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 # ## signature.asc Description: OpenPGP digital signature
Re: Moving forward with updates, builds and versions
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
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. signature.asc Description: OpenPGP digital signature
Re: Moving forward with updates, builds and versions
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 # ## signature.asc Description: OpenPGP digital signature
Re: Moving forward with updates, builds and versions
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
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? signature.asc Description: OpenPGP digital signature
RE: Moving forward with updates, builds and versions
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:dpsen...@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
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
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
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
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:bode...@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
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
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
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
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 assemblies in the binary distribution
Re: Moving forward with updates, builds and versions
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
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
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
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
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
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
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
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