You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Troy Howard <th...@gmail.com> on 2011/02/19 05:38:59 UTC
Signing Binary Releases
Stefan/DIGY,
Have either of you gone through the process of making a signed release
yourselves? I've been reading over the documentation, and well..
That's a lot of documentation. It's hard to tell how much of this is
relevant.
I'd like to get myself set up to to do this but it seems a bit
complex. The step by step instructions still left me with questions.
I'd like to put together a wiki page of step-by-step set of
instructions that are specific to our project.
Thanks,
Troy
On Fri, Feb 18, 2011 at 3:26 PM, Digy <di...@gmail.com> wrote:
> Hi Prescott,
>
> I think there is a misunderstanding about the release. In Apache way, a
> release is a *signed* binary release(compiled version).
>
> Lucene.Net.dll has no dependency to other binaries(unless you want to test
> or use compression) and they will not be included in the release.
>
> DIGY
>
>
> -----Original Message-----
> From: Prescott Nasser [mailto:geobmx540@hotmail.com]
> Sent: Saturday, February 19, 2011 1:04 AM
> To: lucene-net-dev@lucene.apache.org
> Cc: sergey@mirvoda.com
> Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>
>
>
>
>> Perhaps that's Prescott's intention with the new vs2010 branch?
>
> Yes that's the intention. I started to look at what Wyatt did
> https://issues.apache.org/jira/browse/LUCENENET-377. I think feel that it
> works well as designed.
>
> Question: Wyatt has included the nunit.dll's I know we had a conversation
> before about this. But I think being able to pull down everything, open a
> single solution which has test, contrib, src, as well as the required
> dependancies would be a huge boon to getting people to work on this stuff.
>
> Every change I need to make for 2.9.2-2.9.5 requires me to touch the tests.
> it just makes sense from my perspective to have this all in the same
> solution ready to roll.
>
> Is this something people are open too having in the source control, or
> something I should keep to my local? Also, I don't recall the legal stuff
> behind including nunit.
>
> Obviously a release would just be the src rolled up and packaged.
>
>
>
>
> ----------------------------------------
>> From: thoward37@gmail.com
>> Date: Fri, 18 Feb 2011 13:38:47 -0800
>> Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>> To: lucene-net-dev@lucene.apache.org
>> CC: sergey@mirvoda.com
>>
>> It's a common practice for developers to create a branch to work on a
>> new feature, then merge that branch back into trunk later when the
>> changes are complete, then delete the branch.
>>
>> The goal is to ensure that incremental commits, performed now against
>> the branch instead of trunk, don't leave trunk in a incompatible,
>> unstable or un-buildable state.
>>
>> Perhaps that's Prescott's intention with the new vs2010 branch?
>>
>> Thanks,
>> Troy
>>
>>
>> On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote:
>> > +1 for only one trunk upgraded to VS2010
>> >
>> > On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott > >> wrote:
>> >
>> >> I agree with DIGY.
>> >>
>> >> Although why wait until after the official release?
>> >>
>> >> Scott
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Digy [mailto:digydigy@gmail.com]
>> >> Sent: Friday, February 18, 2011 3:38 PM
>> >> To: lucene-net-dev@lucene.apache.org
>> >> Subject: RE: svn commit: r1072121 -
> /incubator/lucene.net/branches/vs2010/
>> >>
>> >> Do we really need a VS2010 branch?. Since there isn't any release since
>> >> v2.0 and people have to compile the source by yourselves it has been
> good to
>> >> support older versions of VS. But after having an offical release, we
> could
>> >> update the trunk to support VS2010.
>> >>
>> >> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to
> update
>> >> another repository also.
>> >>
>> >> DIGY
>> >>
>> >> -----Original Message-----
>> >> From: pnasser@apache.org [mailto:pnasser@apache.org]
>> >> Sent: Friday, February 18, 2011 10:11 PM
>> >> To: lucene-net-commits@lucene.apache.org
>> >> Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>> >>
>> >> Author: pnasser
>> >> Date: Fri Feb 18 20:10:54 2011
>> >> New Revision: 1072121
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev
>> >> Log: (empty)
>> >>
>> >> Added:
>> >> incubator/lucene.net/branches/vs2010/
>> >> - copied from r1069573, incubator/lucene.net/trunk/
>> >>
>> >>
>> >>
>> >> This message (and any associated files) is intended only for the
>> >> use of the individual or entity to which it is addressed and may
>> >> contain information that is confidential, subject to copyright or
>> >> constitutes a trade secret. If you are not the intended recipient
>> >> you are hereby notified that any dissemination, copying or
>> >> distribution of this message, or files associated with this message,
>> >> is strictly prohibited. If you have received this message in error,
>> >> please notify us immediately by replying to the message and deleting
>> >> it from your computer. Thank you, King Industries, Inc.
>> >>
>> >
>> >
>> >
>> > --
>> > --Regards, Sergey Mirvoda
>> > =
>
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
Okay, cool
On Mon, Feb 21, 2011 at 11:27 AM, Robert Jordan <ro...@gmx.net> wrote:
> On 21.02.2011 05:55, Stefan Bodewig wrote:
>
>> On 2011-02-20, Robert Jordan wrote:
>>
>> On 20.02.2011 07:49, Stefan Bodewig wrote:
>>>
>>>> If you talk about strong naming assemblies then I don't have any
>>>> experience how a well designed scheme of sharing the key between several
>>>> developers might work. As the maintainer of XMLUnit I'd be interested
>>>> in a good solution myself.
>>>>
>>>
>> Many open source projects are keeping the key pair (*.snk)
>>> together with the source code in their repository because
>>> the security significance of the key is zero.
>>>
>>
>> Given how .NET assembly signing was designed, no one
>>> would be able to generate a compatible Lucene.Net assembly
>>> from source code w/out having to update assembly
>>> references in all projects using Lucene.Net.
>>>
>>
>> This is hardly compatible with open source principles
>>> and should be avoided.
>>>
>>
>> I agree but users have asked for a strong named version of XMLUnit in
>> the past so I was thinking about providing one as alternative. I've
>> seen similar user requests for log4net or NUnit as well.
>>
>
> Yes, the last part of my mail was misleading. I was actually
> proposing to keep Lucene.Net's SNK key together with the
> source code and to sign the assembly during the build process.
>
> Robert
>
>
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Robert Jordan <ro...@gmx.net>.
On 21.02.2011 05:55, Stefan Bodewig wrote:
> On 2011-02-20, Robert Jordan wrote:
>
>> On 20.02.2011 07:49, Stefan Bodewig wrote:
>>> If you talk about strong naming assemblies then I don't have any
>>> experience how a well designed scheme of sharing the key between several
>>> developers might work. As the maintainer of XMLUnit I'd be interested
>>> in a good solution myself.
>
>> Many open source projects are keeping the key pair (*.snk)
>> together with the source code in their repository because
>> the security significance of the key is zero.
>
>> Given how .NET assembly signing was designed, no one
>> would be able to generate a compatible Lucene.Net assembly
>> from source code w/out having to update assembly
>> references in all projects using Lucene.Net.
>
>> This is hardly compatible with open source principles
>> and should be avoided.
>
> I agree but users have asked for a strong named version of XMLUnit in
> the past so I was thinking about providing one as alternative. I've
> seen similar user requests for log4net or NUnit as well.
Yes, the last part of my mail was misleading. I was actually
proposing to keep Lucene.Net's SNK key together with the
source code and to sign the assembly during the build process.
Robert
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
Educate my users?
That is hardly my role. They get the benefit of being able to run a patch
version without undue hassle.
NHibernate 1.x tried to have a secret snk, and that failed pretty miserably
On Mon, Feb 21, 2011 at 2:16 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-21, Ayende Rahien wrote:
>
> > There are many situations where you _have_ to have a strong key, or
> > example, gac deployments. In those cases, anything in the chain also
> > have to have strong key.
>
> Yes, I knew that. Sorry if I sounded stupid. In most cases I try to
> avoid the GAC and my personal use-case (XMLUnit) is quite different from
> Lucene (i.e. it is less likely to end up as a dependency of something
> that gets deployed to the GAC).
>
> Fortunately my opinion is pretty unimportant here anyway 8-)
>
> > Most OSS in .NET have signed binary releases, and the snk is usually
> > in the source code.
>
> Do you educate your users that there is no security promise attached to
> the strong name in this case? I've always shied away from using strong
> names in OSS because of the illusion of verified-publisher they provide
> in such a setup.
>
> Thanks
>
> Stefan
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-21, Ayende Rahien wrote:
> There are many situations where you _have_ to have a strong key, or
> example, gac deployments. In those cases, anything in the chain also
> have to have strong key.
Yes, I knew that. Sorry if I sounded stupid. In most cases I try to
avoid the GAC and my personal use-case (XMLUnit) is quite different from
Lucene (i.e. it is less likely to end up as a dependency of something
that gets deployed to the GAC).
Fortunately my opinion is pretty unimportant here anyway 8-)
> Most OSS in .NET have signed binary releases, and the snk is usually
> in the source code.
Do you educate your users that there is no security promise attached to
the strong name in this case? I've always shied away from using strong
names in OSS because of the illusion of verified-publisher they provide
in such a setup.
Thanks
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Ayende Rahien <ay...@ayende.com>.
There are many situations where you _have_ to have a strong key, or example,
gac deployments.
In those cases, anything in the chain also have to have strong key. Most OSS
in .NET have signed binary releases, and the snk is usually in the source
code.
On Mon, Feb 21, 2011 at 6:55 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-20, Robert Jordan wrote:
>
> > On 20.02.2011 07:49, Stefan Bodewig wrote:
> >> If you talk about strong naming assemblies then I don't have any
> >> experience how a well designed scheme of sharing the key between several
> >> developers might work. As the maintainer of XMLUnit I'd be interested
> >> in a good solution myself.
>
> > Many open source projects are keeping the key pair (*.snk)
> > together with the source code in their repository because
> > the security significance of the key is zero.
>
> > Given how .NET assembly signing was designed, no one
> > would be able to generate a compatible Lucene.Net assembly
> > from source code w/out having to update assembly
> > references in all projects using Lucene.Net.
>
> > This is hardly compatible with open source principles
> > and should be avoided.
>
> I agree but users have asked for a strong named version of XMLUnit in
> the past so I was thinking about providing one as alternative. I've
> seen similar user requests for log4net or NUnit as well.
>
> Stefan
>
[Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-20, Robert Jordan wrote:
> On 20.02.2011 07:49, Stefan Bodewig wrote:
>> If you talk about strong naming assemblies then I don't have any
>> experience how a well designed scheme of sharing the key between several
>> developers might work. As the maintainer of XMLUnit I'd be interested
>> in a good solution myself.
> Many open source projects are keeping the key pair (*.snk)
> together with the source code in their repository because
> the security significance of the key is zero.
> Given how .NET assembly signing was designed, no one
> would be able to generate a compatible Lucene.Net assembly
> from source code w/out having to update assembly
> references in all projects using Lucene.Net.
> This is hardly compatible with open source principles
> and should be avoided.
I agree but users have asked for a strong named version of XMLUnit in
the past so I was thinking about providing one as alternative. I've
seen similar user requests for log4net or NUnit as well.
Stefan
Re: Signing Binary Releases
Posted by Robert Jordan <ro...@gmx.net>.
On 20.02.2011 07:49, Stefan Bodewig wrote:
> If you talk about strong naming assemblies then I don't have any
> experience how a well designed scheme of sharing the key between several
> developers might work. As the maintainer of XMLUnit I'd be interested
> in a good solution myself.
Many open source projects are keeping the key pair (*.snk)
together with the source code in their repository because
the security significance of the key is zero.
Given how .NET assembly signing was designed, no one
would be able to generate a compatible Lucene.Net assembly
from source code w/out having to update assembly
references in all projects using Lucene.Net.
This is hardly compatible with open source principles
and should be avoided.
Robert
Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-19, Troy Howard wrote:
> Have either of you gone through the process of making a signed release
> yourselves?
I'm not sure whether we are taling about the same kind of signing here.
In have OpenPGP signed the archive that het distributed several times
and this is really pretty simple once you have a key - preferrably one
that is well connected.
If you talk about strong naming assemblies then I don't have any
experience how a well designed scheme of sharing the key between several
developers might work. As the maintainer of XMLUnit I'd be interested
in a good solution myself.
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-23, Troy Howard wrote:
> That makes sense. We've been serving up the distributions from
> ~/lucene.net/site/download in our svn repo through the website.
Ah, understood. This is not the way you should do it - in fact you
should never have done. Releases are supposed to take advantage of the
ASF mirror system and the mirrors pick up stuff from www.apache.org/dist
The download page either only is a template for a CGI script provided by
our infrastructure gurus or uses
http://www.apache.org/dyn/closer.cgi/incubator/ (with an appropriate
path replacing the /incubator/ part) to link to the things to download.
It will never point to the mirrors for PGP signatures of MD5/SHA1
hashes, of course.
> I guess with this release, once it passes the IPMC vote, we can create
> a lucene.net under http://www.apache.org/dist/incubator/ and serve
> from there?
I'd say you must.
> Should we also move our past release artifacts there?
Old releases are supposed to be on <http://archive.apache.org/dist/>
which is a non-deleting mirror of <http://www.apache.org/dist/>. You
could get all the old releases archived by putting them on www for a
short time first but then all mirrors would pull them down just to
delete them soon thereafter. We should ask infra whether there is a
better way to move the old releases to the archive.
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Troy Howard <th...@gmail.com>.
That makes sense. We've been serving up the distributions from
~/lucene.net/site/download in our svn repo through the website. I
guess with this release, once it passes the IPMC vote, we can create a
lucene.net under http://www.apache.org/dist/incubator/ and serve from
there? Should we also move our past release artifacts there?
Thanks,
Troy
On Tue, Feb 22, 2011 at 9:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-22, Troy Howard wrote:
>
>> I found that we have an extant KEYS.TXT at:
>
>> https://svn.apache.org/repos/asf/incubator/lucene.net/site/download/KEYS.txt
>
>> Would it be acceptable to simply add to that file, or is this file in
>> the wrong location?
>
> The location doesn't really matter but you should copy it to wherever
> the distribution files will live as well.
>
> Stefan
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-22, Troy Howard wrote:
> I found that we have an extant KEYS.TXT at:
> https://svn.apache.org/repos/asf/incubator/lucene.net/site/download/KEYS.txt
> Would it be acceptable to simply add to that file, or is this file in
> the wrong location?
The location doesn't really matter but you should copy it to wherever
the distribution files will live as well.
Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Troy Howard <th...@gmail.com>.
Stefan,
Thanks so much for the explanation. This is much clearer.
I found that we have an extant KEYS.TXT at:
https://svn.apache.org/repos/asf/incubator/lucene.net/site/download/KEYS.txt
Would it be acceptable to simply add to that file, or is this file in
the wrong location?
Thanks,
Troy
On Mon, Feb 21, 2011 at 9:38 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-02-21, Troy Howard wrote:
>
>> Stefan - You indicated that the Apache signing process is
>> straightforward and simple, but the documentation is kind of all over
>> the place.
>
> I've never read any of it ;-)
>
>> It discusses so many edge cases and different methods for doing this
>> that it's hard to know what the correct one is. I might be missing
>> something. Do you mind breaking it down for me in a very simple step
>> by step manner?
>
> I'll try but skip over the details since they ultimately depend on the
> OpenPGP implementation you use. The only implementations I have ever
> used were a self-compiled PGP 2.6.x more than ten years ago and several
> versions of GnuPG, all of them running on Linux - and I've never used
> any GUI of any kind.
>
> If anything I write below is unclear, please ask and I'll try to figure
> out the correct answer. Maybe even by reading the ASF documentation.
>
> First of all you need an OpenPGP implementation. I use GnuPG, you might
> prefer something graphical.
>
> Then you need a key pair. This should be straight forward to create
> with your OpenPGP implementation. It may be best to pick the defaults
> offered as algorithms and the longest key length your implementation
> offers.
>
> In retrospect it may have been a good idea if I had created my key in a
> way that it expired after ten years since the key length of my key will
> no longer be sufficient in a few years (if it still is today). But then
> again I can simply create a new one and stop using the old one at one
> point in time.
>
> The next step is to publish the key. There are key servers and
> publishing you key there is a command line option in GnuPG. Most of the
> key servers have a web frontend where you can simply add your ASCII
> armored exported key as well. For example <http://pgpkeys.mit.edu/>.
> The key servers automatically propagate keys from one server to the
> others so it is sufficient to publish to a single server.
>
> You should also create a file called KEYS and add it to Lucene.NET's svn
> area so all developers can add their keys to it. This one will later be
> published in http://www.apache.org/dist/ as the authoritative source.
> For an example that also explains how to create the file see
> <http://svn.apache.org/repos/asf/ant/antlibs/common/trunk/KEYS>
>
> The most difficult part is getting your key signed by others. There is
> no general rule. You must try to find people who are willing to sign
> your key. Most people will only do so if you meet F2F so try to contact
> ASF people living close to you. All bigger ASF events have key signing
> parties just for this purpose.
>
> If your key isn't signed by anybody else you can certainly still sign
> the releases with it - users are just less likely to have chain of trust
> leading to your key. In reality they likely won't have one anyway.
>
> Finally you create the distribution artifact the way you always did.
> Once done you create a detached signature for each of the distribution
> artifacts. I.e. if you have foo-1.0-src.zip you sign it which creates
> foo-1.0-src.zip.asc. You publish both of them side by side. That is
> really all that needs to be done.
>
> On the download page the link to foo-1.0-src.zip will point to the ASF
> mirror system while the one to foo-1.0-src.zip.asc will always point to
> www.apache.org.
>
> Stefan
>
Re: [Lucene.Net] Re: Signing Binary Releases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-02-21, Troy Howard wrote:
> Stefan - You indicated that the Apache signing process is
> straightforward and simple, but the documentation is kind of all over
> the place.
I've never read any of it ;-)
> It discusses so many edge cases and different methods for doing this
> that it's hard to know what the correct one is. I might be missing
> something. Do you mind breaking it down for me in a very simple step
> by step manner?
I'll try but skip over the details since they ultimately depend on the
OpenPGP implementation you use. The only implementations I have ever
used were a self-compiled PGP 2.6.x more than ten years ago and several
versions of GnuPG, all of them running on Linux - and I've never used
any GUI of any kind.
If anything I write below is unclear, please ask and I'll try to figure
out the correct answer. Maybe even by reading the ASF documentation.
First of all you need an OpenPGP implementation. I use GnuPG, you might
prefer something graphical.
Then you need a key pair. This should be straight forward to create
with your OpenPGP implementation. It may be best to pick the defaults
offered as algorithms and the longest key length your implementation
offers.
In retrospect it may have been a good idea if I had created my key in a
way that it expired after ten years since the key length of my key will
no longer be sufficient in a few years (if it still is today). But then
again I can simply create a new one and stop using the old one at one
point in time.
The next step is to publish the key. There are key servers and
publishing you key there is a command line option in GnuPG. Most of the
key servers have a web frontend where you can simply add your ASCII
armored exported key as well. For example <http://pgpkeys.mit.edu/>.
The key servers automatically propagate keys from one server to the
others so it is sufficient to publish to a single server.
You should also create a file called KEYS and add it to Lucene.NET's svn
area so all developers can add their keys to it. This one will later be
published in http://www.apache.org/dist/ as the authoritative source.
For an example that also explains how to create the file see
<http://svn.apache.org/repos/asf/ant/antlibs/common/trunk/KEYS>
The most difficult part is getting your key signed by others. There is
no general rule. You must try to find people who are willing to sign
your key. Most people will only do so if you meet F2F so try to contact
ASF people living close to you. All bigger ASF events have key signing
parties just for this purpose.
If your key isn't signed by anybody else you can certainly still sign
the releases with it - users are just less likely to have chain of trust
leading to your key. In reality they likely won't have one anyway.
Finally you create the distribution artifact the way you always did.
Once done you create a detached signature for each of the distribution
artifacts. I.e. if you have foo-1.0-src.zip you sign it which creates
foo-1.0-src.zip.asc. You publish both of them side by side. That is
really all that needs to be done.
On the download page the link to foo-1.0-src.zip will point to the ASF
mirror system while the one to foo-1.0-src.zip.asc will always point to
www.apache.org.
Stefan
[Lucene.Net] Re: Signing Binary Releases
Posted by Troy Howard <th...@gmail.com>.
All,
It seems there's some confusion about the term 'signed release' from
my question. I'm specifically referring to Apache's rules about
signing releases using OpenPGP. This is the part I need help with.
Creating a Strong Named Assembly (SNA) using a Strong Name Key (SNK)
file is easy and is also something we'll be doing shortly, though not
for the 2.9.2 binary release. I'm going to start a new thread under a
different title to discuss that topic.
Stefan - You indicated that the Apache signing process is
straightforward and simple, but the documentation is kind of all over
the place. It discusses so many edge cases and different methods for
doing this that it's hard to know what the correct one is. I might be
missing something. Do you mind breaking it down for me in a very
simple step by step manner?
Thanks,
Troy
On Fri, Feb 18, 2011 at 8:38 PM, Troy Howard <th...@gmail.com> wrote:
> Stefan/DIGY,
>
> Have either of you gone through the process of making a signed release
> yourselves? I've been reading over the documentation, and well..
> That's a lot of documentation. It's hard to tell how much of this is
> relevant.
>
> I'd like to get myself set up to to do this but it seems a bit
> complex. The step by step instructions still left me with questions.
> I'd like to put together a wiki page of step-by-step set of
> instructions that are specific to our project.
>
> Thanks,
> Troy
>
>
> On Fri, Feb 18, 2011 at 3:26 PM, Digy <di...@gmail.com> wrote:
>> Hi Prescott,
>>
>> I think there is a misunderstanding about the release. In Apache way, a
>> release is a *signed* binary release(compiled version).
>>
>> Lucene.Net.dll has no dependency to other binaries(unless you want to test
>> or use compression) and they will not be included in the release.
>>
>> DIGY
>>
>>
>> -----Original Message-----
>> From: Prescott Nasser [mailto:geobmx540@hotmail.com]
>> Sent: Saturday, February 19, 2011 1:04 AM
>> To: lucene-net-dev@lucene.apache.org
>> Cc: sergey@mirvoda.com
>> Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>>
>>
>>
>>
>>> Perhaps that's Prescott's intention with the new vs2010 branch?
>>
>> Yes that's the intention. I started to look at what Wyatt did
>> https://issues.apache.org/jira/browse/LUCENENET-377. I think feel that it
>> works well as designed.
>>
>> Question: Wyatt has included the nunit.dll's I know we had a conversation
>> before about this. But I think being able to pull down everything, open a
>> single solution which has test, contrib, src, as well as the required
>> dependancies would be a huge boon to getting people to work on this stuff.
>>
>> Every change I need to make for 2.9.2-2.9.5 requires me to touch the tests.
>> it just makes sense from my perspective to have this all in the same
>> solution ready to roll.
>>
>> Is this something people are open too having in the source control, or
>> something I should keep to my local? Also, I don't recall the legal stuff
>> behind including nunit.
>>
>> Obviously a release would just be the src rolled up and packaged.
>>
>>
>>
>>
>> ----------------------------------------
>>> From: thoward37@gmail.com
>>> Date: Fri, 18 Feb 2011 13:38:47 -0800
>>> Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>>> To: lucene-net-dev@lucene.apache.org
>>> CC: sergey@mirvoda.com
>>>
>>> It's a common practice for developers to create a branch to work on a
>>> new feature, then merge that branch back into trunk later when the
>>> changes are complete, then delete the branch.
>>>
>>> The goal is to ensure that incremental commits, performed now against
>>> the branch instead of trunk, don't leave trunk in a incompatible,
>>> unstable or un-buildable state.
>>>
>>> Perhaps that's Prescott's intention with the new vs2010 branch?
>>>
>>> Thanks,
>>> Troy
>>>
>>>
>>> On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote:
>>> > +1 for only one trunk upgraded to VS2010
>>> >
>>> > On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott > >> wrote:
>>> >
>>> >> I agree with DIGY.
>>> >>
>>> >> Although why wait until after the official release?
>>> >>
>>> >> Scott
>>> >>
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Digy [mailto:digydigy@gmail.com]
>>> >> Sent: Friday, February 18, 2011 3:38 PM
>>> >> To: lucene-net-dev@lucene.apache.org
>>> >> Subject: RE: svn commit: r1072121 -
>> /incubator/lucene.net/branches/vs2010/
>>> >>
>>> >> Do we really need a VS2010 branch?. Since there isn't any release since
>>> >> v2.0 and people have to compile the source by yourselves it has been
>> good to
>>> >> support older versions of VS. But after having an offical release, we
>> could
>>> >> update the trunk to support VS2010.
>>> >>
>>> >> Now for each change in trunk (for v2.9.3, 2.9.4 & 2.9.5) we have to
>> update
>>> >> another repository also.
>>> >>
>>> >> DIGY
>>> >>
>>> >> -----Original Message-----
>>> >> From: pnasser@apache.org [mailto:pnasser@apache.org]
>>> >> Sent: Friday, February 18, 2011 10:11 PM
>>> >> To: lucene-net-commits@lucene.apache.org
>>> >> Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
>>> >>
>>> >> Author: pnasser
>>> >> Date: Fri Feb 18 20:10:54 2011
>>> >> New Revision: 1072121
>>> >>
>>> >> URL: http://svn.apache.org/viewvc?rev=1072121&view=rev
>>> >> Log: (empty)
>>> >>
>>> >> Added:
>>> >> incubator/lucene.net/branches/vs2010/
>>> >> - copied from r1069573, incubator/lucene.net/trunk/
>>> >>
>>> >>
>>> >>
>>> >> This message (and any associated files) is intended only for the
>>> >> use of the individual or entity to which it is addressed and may
>>> >> contain information that is confidential, subject to copyright or
>>> >> constitutes a trade secret. If you are not the intended recipient
>>> >> you are hereby notified that any dissemination, copying or
>>> >> distribution of this message, or files associated with this message,
>>> >> is strictly prohibited. If you have received this message in error,
>>> >> please notify us immediately by replying to the message and deleting
>>> >> it from your computer. Thank you, King Industries, Inc.
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > --Regards, Sergey Mirvoda
>>> > =
>>
>>
>