Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of marcel.offermans@luminis.eu
 designates 213.199.154.13 as permitted sender)
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: [VOTE] Release Celix version 1.0.0.incubating
From: Marcel Offermans <marcel.offermans@luminis.eu>
In-Reply-To: 
 <CA+ULb+uiR65o=E1Ub9D7zr02MYnBtUGPBG9u2h6rY-x7fFqeYg@mail.gmail.com>
Date: Tue, 11 Feb 2014 20:44:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <7626736C-A2A4-4566-ABC8-D788A1D6757B@luminis.eu>
References: 
 <CA+T-u8d4UDf7RDvXRU6zYYEhp9uLmtGDrU6+FRr=0gYzje4MzQ@mail.gmail.com>
 <35F7D512-42D5-4E99-B492-D9B779445D81@luminis.eu>
 <CA+ULb+uiD3GKHd8WOChcYruz9pfzg5Xxh8qqtJtD802tndUStA@mail.gmail.com>
 <CA+T-u8eNyL8yKzMh=r30v_tz=yA2wgx0AN7cvhE5137ecy6Fag@mail.gmail.com>
 <CA+ULb+u+rH_gJ+u8LYkX9L5TWwB1234vT-fedMXfROfX9QKRHA@mail.gmail.com>
 <CA+T-u8cV=RP3vuXRvuGQc7N8oNV6x2FPNQGhSg8uf2MWd9zHkQ@mail.gmail.com>
 <CAPhv5g-NvS=cwtH8mvsYVDLTjaa4QoO+tvw40fvb3487a2Nawg@mail.gmail.com>
 <CAPhv5g9D1PSoQLyJco8y4uzkvE_oeA_PkE53AJ46QzjOfcjs6A@mail.gmail.com>
 <8C2EF175-E4CB-44A6-BC19-42CD2F79258A@luminis.eu>
 <CA+ULb+uiR65o=E1Ub9D7zr02MYnBtUGPBG9u2h6rY-x7fFqeYg@mail.gmail.com>
To: "<celix-dev@incubator.apache.org>" <celix-dev@incubator.apache.org>

Hello Roman,

On 11 Feb 2014, at 20:37 pm, Roman Shaposhnik <rvs@apache.org> wrote:

> Apologies for the late reply -- I am fine with you guys forwarding the
> vote to general@

No worries, Roman, thanks for getting back to us.

> To put my comments in context, here's my only bit of feedback to you:
> mentors are
> volunteers. They are not being payed or otherwise incentivesed to
> review releases
> in cases where it is not immediately obvious how to do a certain bit =
of release
> verification. This is a bit of accommodation that you may consider =
useful to get
> votes quicker. On the other hand, like you mentioned in the case of
> hashsums -- you
> seem to be following some kind of documentation. The fact that to this
> day, I don't know
> of a tool that would let me automate that check doesn't mean other =
members
> of the incubator community wouldn't be more creative.

This was exactly the feedback I provided to the community: please =
provide some kind of script that allows everybody to quickly validate =
such hashsums. There is no need for everybody to validate them by hand, =
I totally agree there.

Greetings, Marcel


> The only way to find out is to try the vote and see what happens.
>=20
> Thanks,
> Roman.
>=20
> On Tue, Feb 11, 2014 at 4:09 AM, Marcel Offermans
> <marcel.offermans@luminis.eu> wrote:
>> I'm in favor for forwarding the vote, we need someone else to look at =
it, or Roman to answer to the responses given here. I tried pinging =
Roman last week. I think he must be very busy at the moment, so let's =
try to move ahead!
>>=20
>> Greetings, Marcel
>>=20
>>=20
>> On 07 Feb 2014, at 9:52 am, Pepijn Noltes <pepijnnoltes@gmail.com> =
wrote:
>>=20
>>> Hi All,
>>>=20
>>> I would like to propose to forward the release vote to the incubator
>>> mailing list We got two +1 binding vote and -1 vote, so we are one =
binding
>>> +1 short.
>>> There is still some comments from Roman, but I think there is always =
some
>>> room for improvement and again there is no  -1 vote.
>>>=20
>>> I would like to known if any mentors see a problem with this =
approach. I
>>> don't want to step on anybody's toes, but would like to push the =
release
>>> forward.
>>>=20
>>> Greetings,
>>> Pepijn
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Tue, Jan 28, 2014 at 8:08 PM, Pepijn Noltes =
<pepijnnoltes@gmail.com>wrote:
>>>=20
>>>> Hi Roman,
>>>>=20
>>>> Could you have a look at the comments of Alexander? I known I'm =
pushing a
>>>> bit, but we are hoping to get the release ready :).
>>>>=20
>>>>=20
>>>> On Fri, Jan 24, 2014 at 12:11 PM, Alexander Broekhuis <
>>>> a.broekhuis@gmail.com> wrote:
>>>>=20
>>>>> Hi Roman,
>>>>>=20
>>>>> See my remarks inline below. I hope this gives you enough =
confidence to
>>>>> sign this release off.
>>>>>=20
>>>>> 2014/1/24 Roman Shaposhnik <rvs@apache.org>
>>>>>=20
>>>>>> I know that some of the items are nits, but if we are to
>>>>>> re-cut an RC for Boost reasons -- I'd suggest we may
>>>>>> as well take care of them
>>>>>>=20
>>>>>=20
>>>>> The way I read [2], there is no need to add anything to the notice =
file at
>>>>> all. All third party sources we use have a header with the =
respective
>>>>> license information. At [2] it is even explicitly mentioned not to =
add
>>>>> anything unless legally required.
>>>>>=20
>>>>> "Do not add anything to NOTICE which is not legally required."
>>>>>=20
>>>>> So I don't see a reason why a new release is needed for Boost.
>>>>>=20
>>>>>>=20
>>>>>>> The checksum has been created with the command mentioned on the =
Apache
>>>>>>> Signing Releases page [1]. I don't see what is wrong with this.
>>>>>>=20
>>>>>> There was an old discussion on that some time ago. Basically
>>>>>> the problem boils down to a fact that I can't verify it with =
shasum(1)
>>>>>> and thus can't sign off on it.
>>>>>>=20
>>>>>=20
>>>>> This was indeed an old discussion, but there has never been =
reached a
>>>>> consensus, and as stated before, I've explicitly used the method =
described
>>>>> on the Apache pages, which uses the gpg tooling to verify a =
checksum.
>>>>> Instead of using shasum, you can simply use gpg --print-md =
"filename".
>>>>>=20
>>>>> If all I do is follow the official Apache document then what am I =
doing
>>>>> wrong?
>>>>>=20
>>>>> I've had some discussion with Marcel on this topic as well, and in =
some
>>>>> other project where Marcel is involved, they use a script to =
compare the
>>>>> checksums. A similar solution might be implemented for Celix as =
well, I
>>>>> don't mind adding this to the backlog.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>>  * it would be nice to have version embedded into the name of =
the
>>>>> top
>>>>>>>>    level dir inside of the tarball
>>>>>>>>=20
>>>>>>>=20
>>>>>>> We have decided to leave it out since else there would always be =
an
>>>>> issue
>>>>>>> with the BUILDING instructions and the default directory. This =
was a
>>>>>> remark
>>>>>>> by someone on the first (0.0.1) release where we did have the =
version
>>>>> in
>>>>>>> the top-level directory.
>>>>>>=20
>>>>>> Hm. I'm just curious -- was there a thread on this one?
>>>>>>=20
>>>>>=20
>>>>> This was a remark made by Marcel on our first release. See [3] for =
his
>>>>> message/the release thread.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>>>  * boost license is missing in NOTICES
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Why should the boost license be in the NOTICES file? There have =
been a
>>>>>> lot
>>>>>>> of discussions on this file, and my understanding always has =
been that
>>>>>> if a
>>>>>>> license is in a header it is not needed to add it to the NOTICES =
file.
>>>>>>=20
>>>>>> I honestly don't recall this. Care to point a thread?
>>>>>>=20
>>>>>=20
>>>>> I can't find the thread, but [2] gives a good explanation.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> Thanks,
>>>>>> Roman.
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> [1]: http://www.apache.org/dev/release-signing#sha-checksum
>>>>> [2]: http://www.apache.org/dev/licensing-howto.html#mod-notice
>>>>> [3]: http://incubator.markmail.org/thread/ot7cwepmcusdblqs
>>>>>=20
>>>>> --
>>>>> Met vriendelijke groet,
>>>>>=20
>>>>> Alexander Broekhuis
>>>>>=20
>>>>=20
>>>>=20
>>=20