+1 DIGY On Mon, Feb 28, 2011 at 10:29 AM, Troy Howard <thowar...@gmail.com> wrote:
> +1 to all suggestions. Hudkins is my new favourite word. ;) > > One quick concern I have, is how much of the things listed are already > available on the Apache hudson server? A lot of this is .NET specific, so > unlikely that it will already be available. We'll have to request that ASF > Infra team install these tools for us, and they may not agree, or there > might be licensing issues, etc.. Not sure. I'd start the conversation with > them now to suss this out. > > Specifically some thoughts: > > - FxCop/StyleCop/NCover/NDepend are a basics which should be viewed as a > necessity for any serious .NET project > - I love SandCastle and was about to bring that up on the list. We could > keep rolling with NDoc. Either way. > - I love Gallio/MbUnit/Moq... nunit not so much, but again, either would be > fine. > - Mono is going to be a requirement moving forward > - Project structure was being discussed on the LUCENENET-377 thread. For > the binary release, I used a structure similar to what you were describing, > and the topic of applying that structure to trunk came up. This is something > that we should discuss in detail before applying to trunk (my work was in a > branch). We need to make sure directory structure remains relatively static, > however, current structure needs a lot of improvement.. So now is a good > time to change. > > Digy suggested: > > \build > \contrib > \core > \core\Lucene.Net > \core\Test > \demo > > ... and in the recent binary release, I used a root \bin and \doc in the > same way you suggested. > > > As a combination of ideas, how about: > > Build Files: > > \build > \build\VS2008 > \build\VS2010 > > > Source Projects: > > \src > \src\contrib > \src\core > \src\demo > \src\contrib\<project-name> > \src\core\<project-name> > \src\demo\<project-name> > > > Test Projects: > > \test > \test\contrib > \test\core > \test\demo > \test\contrib\<project-name> > \test\core\<project-name> > \test\demo\<project-name> > > > Product Documentation: > > \doc > \doc\contrib > \doc\core > \doc\demo > \doc\contrib\<project-name> > \doc\core\<project-name> > \doc\demo\<project-name> > > > Third-Party Dependencies: > > \lib > \lib\<vendor> > \lib\<vendor>\<product> > \lib\<vendor>\<product>\<version> > > > Binary Builds: > > \bin > \bin\contrib > \bin\core > \bin\demo > \bin\contrib\<project-name> > \bin\core\<project-name> > \bin\demo\<project-name> > > > Thanks, > Troy > > > > On Sun, Feb 27, 2011 at 11:10 PM, Michael Herndon <mhern...@o19s.com>wrote: > >> So the CI choices for Apache are the following: >> >> >> - Buildbot <http://ci.apache.org/#buildbot> >> - Continuum <http://ci.apache.org/#continuum> >> - Gump <http://ci.apache.org/#gump> >> - Hudson <http://ci.apache.org/#hudson> >> >> There is a current discussion on the build list about moving with the name >> shift of hudson to jenkins. >> >> My vote is to go with hudkins [?] because it has been successfully used >> for .net projects in the past and has plugins to help support that. Nothing >> personal against python, but there seems to be more material on integration >> .net builds inside of Hudson. >> >> I've also used Hudson in the past so I can vouch that it does a decent >> job. (This was a while ago, so I can only hope the number of plugins and >> integration points have increased). >> >> I'm going to do a bit more reading on the apache mailing list for builds >> to see if there is an actual windows slave for hudson/jenkins (which shall >> henceforth be called hudkins on this list, well at least by me). >> >> Obviously the first priority will be getting a build set up and starting >> simple. However to spark discussion and future planning: Here is a list of >> other things to include or think about for the build process long term. >> >> * fxcop - (this will probably need customized rules for strict java port >> version) >> * stylecop - (same) >> * sandcastle - (building xml comments into documentation). >> * sandcastle help file builder - (SHFB) >> * code coverage tool - possibly seeing if we can get a code coverage tool >> (possibly ncover as they used to give a free license to os projects), >> * code metrics tool - (i.e. cyclomatic complexity, ndepend used to do the >> same thing as ncover, thus worth investigating). >> * gallio test runner vs nunit. (gallio is testing automation tool capable >> of running various testing frameworks and tools including nunit). >> * extended msbuild tasks. >> * mono build. >> * project structure for the build. ** >> * insert _____ any other suggestions here. >> >> I'll volunteer myself for the boring job of fixing up xml comments so >> there is some meat and code examples inside xml comments so >> the documentation generates more than just text and method signatures with >> type information. >> >> After some discussion in the list and unless there is show stopper or >> killer reason not to go with hudkins. I'll notate the decision the jira and >> start putting notes in the wiki about the CI. >> >> notes: >> ----------------- >> ** a common project structure/format or some variant there of, which might >> be more intuitive for people that have worked on other foss projects. >> trunk|root >> /src (source) >> /lib|vendor (dependencies) >> /tests (test code) >> /docs (documentation, architechture, diagrams, notes, etc) >> /bin (executables - bat, exe, cmd files, etc) >> root documents (licenses,readme,etc) >> >> - Michael >> >> >> >> >
