lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <>
Subject Re: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1 Release (take 2)
Date Wed, 25 Jan 2012 19:15:13 GMT
verified tests pass and checksums match.

so +1

@P, I remember that thread.  Those guys stay busy though and devopt
mentality is different than a devs.

Our needs probably exceed what the svn CMS is meant for due to
documentation.  I am curious if infra allows for or would allow us to throw
up a static mono/ mvc in the future just so that we could dog food
 the site with search using Lucene.Net and then have it index certain pages
or sites (wiki, tutorials, static site, docs).   We'll probably need to dig
out our CMS options again and weight against short term and long term

On Wed, Jan 25, 2012 at 12:31 PM, Prescott Nasser <>wrote:

> You know even making a small change to the website like updating the news
> takes like 30 minutes to run now because of all the files. Its absolutely
> ridiculous.
> I got chided by the CMS group, yet when asked how do we put documentation
> online with the new system there were crickets.
> Sent from my Windows Phone
> ________________________________
> From: Michael Herndon
> Sent: 1/25/2012 8:26 AM
> To:
> Cc:
> Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene-2.9.4g-incubating-RC1
> Release (take 2)
> I was not able to download the binaries till this morning.  The wiki was
> also having issues.
> I ran rat on the the released source, that seems fine. did a compare on src
> zip and the tag. it matches.
> The only things I saw are nit picks.
> in the ReadMe the link should point to its respective tag instead of RC3
> for just 2_9_4
> be
> when releasing the source in the future, we should either include a script
> that pulls the lib for the developers who want to compile from source
> inside a tag when the project is built using the solution. Or we should
> invest into using something like nuget for dependencies so that the
> dependencies are automatically fetched somehow and we can remove those from
> svn/scm altogether.
> the source currently violates the "don't make me think about it" principle.
> I know we all dislike chms, but until we figure out a better way of posting
> the generated msdn documentation online, we should include that in releases
> as well.  The static website version generates a high number of static html
> files and our current CMS requires that those files are pushed into SVN
> which just is not feasible. Committing that all at once will choke infra's
> setup (and if they hired ninjas to pay us a visit, I probably wouldn't
> blame them) and doing partial commits is just borderline insanity.
> Just waiting on the all the tests to finish running.
> On Wed, Jan 25, 2012 at 6:29 AM, Stefan Bodewig <>
> wrote:
> > On 2012-01-25, Michael Herndon wrote:
> >
> > > Stefan what did you use to check the eof of files for svn?
> >
> > Pretty much a long and boring manual process.  I did something like
> >
> > find . -name \*.cs -print0 | xargs -0 -e svn ps svn:eol-style native
> >
> > i.e. tried to set the eol-style property on all C# source files.  This
> > won't do anything if the property is set and tell you it has changed
> > something in "svn status" if it the property hasn't been set before.
> >
> > svn will also fail if the file in question contains inconsistent line
> > ends, this is the case for the NUnit doc files and even some of
> > Lucene.NET sources.
> >
> > Repeat for all other file extension that should map to text files.
> >
> > > I'm setting up RAT on my local.  Are there any other tools that you or
> > ASF
> > > recommends in general to validate releases?
> >
> > I think Sebb has a bunch of scripts he uses, but never bothered to look
> > them up.  If so, they'd be inside the comitters svn repo.
> >
> > For this release you don't even need to check line-feeds, the properties
> > have not been set on all files.  The patch I provided a while ago only
> > applied to trunk.  To me this is no reason to stop the release, in
> > particular since most files have Windows line-ends and Prescott built
> > the release on Windows so the files would be the same with and without
> > svn:eol-style anyway.
> >
> > I intend to provide a new patch for the 3.0.3 branch once you have
> > decided which way to go.  Most likely there'll be files without license
> > headers in that branch as well.
> >
> > Stefan
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message