lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: [VOTE] Removing strong naming from all future versions
Date Sat, 03 May 2014 17:48:47 GMT
Vote concluded, we will remove strong naming this week.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Thu, May 1, 2014 at 10:20 PM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> Michael, this is a majority vote, and this is what I was implying, sorry
> if it was understood differently. Also, vetoing isn't on by default on all
> votes, like you can read in the link you provided.
>
> Either way, you haven't provided your vote.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Thu, May 1, 2014 at 8:46 PM, michael herndon <
> mherndon@michaelherndon.com> wrote:
>
>> Its probably worth reiterating that with this vote:
>>
>> Signed binaries are NOT going away.
>>
>>   - They are just reverting back to the previous manual download
>> distribution method.
>>   - Nothing prevents a developer from creating their own nuget feed with
>> the signed binaries using something like nuget.server or myget.org.
>>
>> On a side note, statements like, "Michael and Simon's votes are still
>> absent but that won't matter anyway.", should be avoided in the future.
>>
>> The above statement could be misconstrued as:
>>
>> a) Voting doesn't matter and thus a person's opinion or voice doesn't
>> matter. Part of purpose of voting is to elicit feedback and
>> build consensus with the community because the community matters. The
>> other
>> purpose is conflict resolution.
>>
>> b) That the named parties are the only missing committer votes. There are
>> other members not listed that have not voted.
>>
>> b) That people are being singled out. Calling out people rather than just
>> focusing on the issue is bad form. It can make things seem personal or
>> meant for public shaming even when the intent was anything but that.
>>
>> c) Majority rules applies to this vote when it does not.  A single binding
>> negative one vote effectively vetoes a code modification vote / proposal
>> like this one.  https://www.apache.org/foundation/voting.html
>>
>> -M
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, May 1, 2014 at 8:57 AM, Simon Svensson <sisve@devhost.se> wrote:
>>
>> > +1
>> >
>> > (I'll admit that I had no idea that I had any voting power...)
>> >
>> >
>> > On 01/05/14 14:33, Itamar Syn-Hershko wrote:
>> >
>> >> Ok so we have 4 binding votes in favor to this move (counting Paul as
>> well
>> >> because of his recent contributions), 1 non-binding in favor, and 2
>> >> non-binding against it.
>> >>
>> >> Michael and Simon's votes are still absent but that won't matter
>> anyway.
>> >>
>> >> I haven't announced a deadline initially so I'll be setting one now.
>> Vote
>> >> terminates May 2nd 2PM GMT, just a bit over 24h from now.
>> >>
>> >> We will then move to making the mentioned changes.
>> >>
>> >> --
>> >>
>> >> Itamar Syn-Hershko
>> >> http://code972.com | @synhershko <https://twitter.com/synhershko>
>> >> Freelance Developer & Consultant
>> >> Author of RavenDB in Action <http://manning.com/synhershko/>
>> >>
>> >>
>> >> On Thu, May 1, 2014 at 1:39 AM, Nicholas Paldino <
>> >> casperOne@caspershouse.com
>> >>
>> >>> wrote:
>> >>> +1
>> >>>
>> >>>  On Apr 30, 2014, at 6:38 PM, "Troy Howard" <thoward37@gmail.com>
>> wrote:
>> >>>>
>> >>>> +1
>> >>>>
>> >>>> On Tue, Apr 29, 2014 at 9:49 AM, Prescott Nasser <
>> geobmx540@hotmail.com
>> >>>> wrote:
>> >>>>
>> >>>>  +1 since we will make both available
>> >>>>>
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: "Paul Irwin" <pirwin@feature23.com>
>> >>>>> Sent: ‎4/‎29/‎2014 7:06 AM
>> >>>>> To: "dev@lucenenet.apache.org" <dev@lucenenet.apache.org>
>> >>>>> Subject: Re: [VOTE] Removing strong naming from all future versions
>> >>>>>
>> >>>>> +1 since an alternative signed version would be available as
a
>> >>>>> download.
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Apr 29, 2014 at 9:20 AM, Itamar Syn-Hershko <
>> >>>>> itamar@code972.com
>> >>>>>
>> >>>>>> wrote:
>> >>>>>> Here is my +1
>> >>>>>>
>> >>>>>> All reasoning are here:
>> >>>>>>
>> >>>>>>  http://code972.com/blog/2014/04/68-ditching-strong-naming-
>> >>> for-lucene-net
>> >>>
>> >>>> We will publish both signed and non-signed. If someone can't change
>> >>>>>>
>> >>>>> their
>> >>>
>> >>>> process for making their project not sign, they are most likely
not
>> >>>>>>
>> >>>>> using
>> >>>
>> >>>> nuget anyway. May be a bit harsh but that's mostly true.
>> >>>>>>
>> >>>>>> --
>> >>>>>>
>> >>>>>> Itamar Syn-Hershko
>> >>>>>> http://code972.com | @synhershko <https://twitter.com/synhershko>
>> >>>>>> Freelance Developer & Consultant
>> >>>>>> Author of RavenDB in Action <http://manning.com/synhershko/>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Apr 29, 2014 at 11:29 AM, Rob Vesse <rvesse@dotnetrdf.org>
>> >>>>>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> -1
>> >>>>>>>
>> >>>>>>> I am strongly in favour of keeping strong naming for
previously
>> >>>>>>>
>> >>>>>> mentioned
>> >>>>>
>> >>>>>> reasons, I believe removing the signing will cause issues
>> throughout
>> >>>>>>>
>> >>>>>> the
>> >>>>>
>> >>>>>> wider ecosystem of developers who rely on Lucene.Net
>> >>>>>>>
>> >>>>>>> Counter-proposal:
>> >>>>>>>
>> >>>>>>> Publish both signed and unsigned packages and leave
it up to
>> users to
>> >>>>>>> decide which to use, the main package IDs should continue
to be
>> >>>>>>> signed
>> >>>>>>>
>> >>>>>> and
>> >>>>>>
>> >>>>>>> new package IDs should be created for the unsigned variants
>> >>>>>>>
>> >>>>>>> Rob
>> >>>>>>>
>> >>>>>>>  On 29/04/2014 03:52, "Itamar Syn-Hershko" <itamar@code972.com>
>> >>>>>>>>
>> >>>>>>> wrote:
>> >>>
>> >>>> This is a vote for removing strong naming from Lucene.NET effective
>> >>>>>>>> immediately, affecting all future versions including
the planned
>> v3
>> >>>>>>>>
>> >>>>>>> bugfix
>> >>>>>>
>> >>>>>>> release and obviously the v4 branch, arguments being:
>> >>>>>>>>
>> >>>>>>>> 1. This is a headache to manage, given dependencies
may or may
>> not
>> >>>>>>>> be
>> >>>>>>>> signed and as long as we are signed we can't use
them without
>> >>>>>>>> signing
>> >>>>>>>>
>> >>>>>>> them
>> >>>>>>
>> >>>>>>> first. At this point in time it's a blocker for us from
releasing
>> the
>> >>>>>>>>
>> >>>>>>> v3
>> >>>>>
>> >>>>>> bugfix version.
>> >>>>>>>>
>> >>>>>>>> 2. Strong naming is pretty much pointless as it
is anyway,
>> >>>>>>>> especially
>> >>>>>>>> since
>> >>>>>>>> we are OSS and our key is public anyway.
>> >>>>>>>>
>> >>>>>>>> All main distribution channels (nuget, binary downloads)
will
>> not be
>> >>>>>>>> signed, but we will provide a download link with
a signed version
>> >>>>>>>> for
>> >>>>>>>> people who need a signed. This is to address needs
coming from
>> >>>>>>>> people
>> >>>>>>>>
>> >>>>>>> who
>> >>>>>>
>> >>>>>>> already have signed their projects.
>> >>>>>>>>
>> >>>>>>>> We will also publish a Wiki page describing this
move in detail,
>> >>>>>>>> with
>> >>>>>>>>
>> >>>>>>> the
>> >>>>>>
>> >>>>>>> hopes people will remove signing from their projects
instead of
>> using
>> >>>>>>>>
>> >>>>>>> the
>> >>>>>>
>> >>>>>>> signed version.
>> >>>>>>>>
>> >>>>>>>> Let's make the world a better place.
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>>
>> >>>>>>>> Itamar Syn-Hershko
>> >>>>>>>> http://code972.com | @synhershko <https://twitter.com/synhershko
>> >
>> >>>>>>>> Freelance Developer & Consultant
>> >>>>>>>> Author of RavenDB in Action <http://manning.com/synhershko/>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>> --
>> >>>>>
>> >>>>> Paul Irwin
>> >>>>> Lead Software Engineer
>> >>>>> feature[23]
>> >>>>>
>> >>>>> Email: pirwin@feature23.com
>> >>>>> Cell: 863-698-9294
>> >>>>>
>> >>>>>
>> >
>>
>
>

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