[mentor advice request] release process final steps

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[mentor advice request] release process final steps

Joe Witt
Mentors (formal or otherwise),

Please confirm I have this correctly.  At the conclusion of the 72 hour
voting period and assuming a successful outcome I intend to do the
following steps to conclude the RM duties for this release:

1) Send out the IPMC vote result e-mail.

2) In the apache nexus staging repos : 'Release'

3) Upload the two source release bundles to
https://dist.apache.org/repos/dist/release/incubator/nifi/

4) Build convenience binaries from the source bundles and place those
along-side the source release in dist.

5) Update the incubator/nifi website to point to download links for those
items and their signatures/hashes

6) Update the incubator nifi podling status page to indicate this 'news'

If that is correct will make it happen and will update the release guide to
reflect this.

Then we get on with the business of 0.0.2 or 0.1.0 or whatever is coming
next :-)

Thanks!
Joe
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Benson Margulies
On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:

> Mentors (formal or otherwise),
>
> Please confirm I have this correctly.  At the conclusion of the 72 hour
> voting period and assuming a successful outcome I intend to do the
> following steps to conclude the RM duties for this release:
>
> 1) Send out the IPMC vote result e-mail.
>
> 2) In the apache nexus staging repos : 'Release'
>
> 3) Upload the two source release bundles to
> https://dist.apache.org/repos/dist/release/incubator/nifi/

You might need one of us for this job. Outside the incubator, only PMC
members have access.

>
> 4) Build convenience binaries from the source bundles and place those
> along-side the source release in dist.
>
> 5) Update the incubator/nifi website to point to download links for those
> items and their signatures/hashes
>
> 6) Update the incubator nifi podling status page to indicate this 'news'
>
> If that is correct will make it happen and will update the release guide to
> reflect this.
>
> Then we get on with the business of 0.0.2 or 0.1.0 or whatever is coming
> next :-)
>
> Thanks!
> Joe
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Sergio Fernández


On 29/01/15 14:35, Benson Margulies wrote:

> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
>> Mentors (formal or otherwise),
>>
>> Please confirm I have this correctly.  At the conclusion of the 72 hour
>> voting period and assuming a successful outcome I intend to do the
>> following steps to conclude the RM duties for this release:
>>
>> 1) Send out the IPMC vote result e-mail.
>>
>> 2) In the apache nexus staging repos : 'Release'
>>
>> 3) Upload the two source release bundles to
>> https://dist.apache.org/repos/dist/release/incubator/nifi/
>
> You might need one of us for this job. Outside the incubator, only PMC
> members have access.

Don't they get permissions on the incubator dist area?

>> 4) Build convenience binaries from the source bundles and place those
>> along-side the source release in dist.

The binaries should be exactly the same that were voted; i.e., the
checksums _must_ match. If your vote did not include binary releases,
which I thing is your case, then you should not distribute binaries.

>> 5) Update the incubator/nifi website to point to download links for those
>> items and their signatures/hashes
>>
>> 6) Update the incubator nifi podling status page to indicate this 'news'
>>
>> If that is correct will make it happen and will update the release guide to
>> reflect this.

I think that's all.

Take into account that some processes (particularly mirroring) usually
take up to 24 hours. So you should wait until the release can be
officially announced.

Cheers,

--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: [hidden email]
w: http://redlink.co
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Benson Margulies
On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]> wrote:

>
>
> On 29/01/15 14:35, Benson Margulies wrote:
>>
>> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
>>>
>>> Mentors (formal or otherwise),
>>>
>>> Please confirm I have this correctly.  At the conclusion of the 72 hour
>>> voting period and assuming a successful outcome I intend to do the
>>> following steps to conclude the RM duties for this release:
>>>
>>> 1) Send out the IPMC vote result e-mail.
>>>
>>> 2) In the apache nexus staging repos : 'Release'
>>>
>>> 3) Upload the two source release bundles to
>>> https://dist.apache.org/repos/dist/release/incubator/nifi/
>>
>>
>> You might need one of us for this job. Outside the incubator, only PMC
>> members have access.
>
>
> Don't they get permissions on the incubator dist area?
>
>>> 4) Build convenience binaries from the source bundles and place those
>>> along-side the source release in dist.
>
>
> The binaries should be exactly the same that were voted; i.e., the checksums
> _must_ match. If your vote did not include binary releases, which I thing is
> your case, then you should not distribute binaries.

Sorry to be argumentative, but _no_. We do not vote on binaries. At
all. Binaries are conveniences, not part of the release, not covered
by Foundation legal protections, not an 'act of the PMC'. See the
email chain with Jan I and Bertrand and myself on general@incubator
over the last two days.

It's a happenstance that corresponding binaries happen to get pushed
around by Maven.

>
>>> 5) Update the incubator/nifi website to point to download links for those
>>> items and their signatures/hashes
>>>
>>> 6) Update the incubator nifi podling status page to indicate this 'news'
>>>
>>> If that is correct will make it happen and will update the release guide
>>> to
>>> reflect this.
>
>
> I think that's all.
>
> Take into account that some processes (particularly mirroring) usually take
> up to 24 hours. So you should wait until the release can be officially
> announced.
>
> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: [hidden email]
> w: http://redlink.co
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Joe Witt
Sergio,

I believe based on [1], previous comments in this thread and others, and
what I've read throughout the various policy documentation and guides we're
actually good to go on providing a convenience binary build along side the
actual official source release which is technically and legally the only
real release.  This is provided we follow exactly the guidance below.

The specific language from the release guide of relevance here I believe to
be:

"In some cases, binary/bytecode packages are also produced as a convenience
to users that might not have the appropriate tools to build a compiled
version of the source. In all such cases, the binary/bytecode package must
have the same version number as the source release and may only add
binary/bytecode files that are the result of compiling that version of the
source code release."

[1]: http://www.apache.org/dev/release.html#what

Thanks
Joe

On Thu, Jan 29, 2015 at 8:58 AM, Benson Margulies <[hidden email]>
wrote:

> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> wrote:
> >
> >
> > On 29/01/15 14:35, Benson Margulies wrote:
> >>
> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
> >>>
> >>> Mentors (formal or otherwise),
> >>>
> >>> Please confirm I have this correctly.  At the conclusion of the 72 hour
> >>> voting period and assuming a successful outcome I intend to do the
> >>> following steps to conclude the RM duties for this release:
> >>>
> >>> 1) Send out the IPMC vote result e-mail.
> >>>
> >>> 2) In the apache nexus staging repos : 'Release'
> >>>
> >>> 3) Upload the two source release bundles to
> >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> >>
> >>
> >> You might need one of us for this job. Outside the incubator, only PMC
> >> members have access.
> >
> >
> > Don't they get permissions on the incubator dist area?
> >
> >>> 4) Build convenience binaries from the source bundles and place those
> >>> along-side the source release in dist.
> >
> >
> > The binaries should be exactly the same that were voted; i.e., the
> checksums
> > _must_ match. If your vote did not include binary releases, which I
> thing is
> > your case, then you should not distribute binaries.
>
> Sorry to be argumentative, but _no_. We do not vote on binaries. At
> all. Binaries are conveniences, not part of the release, not covered
> by Foundation legal protections, not an 'act of the PMC'. See the
> email chain with Jan I and Bertrand and myself on general@incubator
> over the last two days.
>
> It's a happenstance that corresponding binaries happen to get pushed
> around by Maven.
>
> >
> >>> 5) Update the incubator/nifi website to point to download links for
> those
> >>> items and their signatures/hashes
> >>>
> >>> 6) Update the incubator nifi podling status page to indicate this
> 'news'
> >>>
> >>> If that is correct will make it happen and will update the release
> guide
> >>> to
> >>> reflect this.
> >
> >
> > I think that's all.
> >
> > Take into account that some processes (particularly mirroring) usually
> take
> > up to 24 hours. So you should wait until the release can be officially
> > announced.
> >
> > Cheers,
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: [hidden email]
> > w: http://redlink.co
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Joe Witt
Benson: "You might need one of us for this job. Outside the incubator, only
PMC
members have access."

Sergio: "Don't they get permissions on the incubator dist area?"

I have verified that I am able to put files into that directory and remove
them.

Do you agree that the steps I listed then are correct?

Thanks
Joe

On Thu, Jan 29, 2015 at 9:10 AM, Joe Witt <[hidden email]> wrote:

> Sergio,
>
> I believe based on [1], previous comments in this thread and others, and
> what I've read throughout the various policy documentation and guides we're
> actually good to go on providing a convenience binary build along side the
> actual official source release which is technically and legally the only
> real release.  This is provided we follow exactly the guidance below.
>
> The specific language from the release guide of relevance here I believe
> to be:
>
> "In some cases, binary/bytecode packages are also produced as a
> convenience to users that might not have the appropriate tools to build a
> compiled version of the source. In all such cases, the binary/bytecode
> package must have the same version number as the source release and may
> only add binary/bytecode files that are the result of compiling that
> version of the source code release."
>
> [1]: http://www.apache.org/dev/release.html#what
>
> Thanks
> Joe
>
> On Thu, Jan 29, 2015 at 8:58 AM, Benson Margulies <[hidden email]>
> wrote:
>
>> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
>> wrote:
>> >
>> >
>> > On 29/01/15 14:35, Benson Margulies wrote:
>> >>
>> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
>> >>>
>> >>> Mentors (formal or otherwise),
>> >>>
>> >>> Please confirm I have this correctly.  At the conclusion of the 72
>> hour
>> >>> voting period and assuming a successful outcome I intend to do the
>> >>> following steps to conclude the RM duties for this release:
>> >>>
>> >>> 1) Send out the IPMC vote result e-mail.
>> >>>
>> >>> 2) In the apache nexus staging repos : 'Release'
>> >>>
>> >>> 3) Upload the two source release bundles to
>> >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
>> >>
>> >>
>> >> You might need one of us for this job. Outside the incubator, only PMC
>> >> members have access.
>> >
>> >
>> > Don't they get permissions on the incubator dist area?
>> >
>> >>> 4) Build convenience binaries from the source bundles and place those
>> >>> along-side the source release in dist.
>> >
>> >
>> > The binaries should be exactly the same that were voted; i.e., the
>> checksums
>> > _must_ match. If your vote did not include binary releases, which I
>> thing is
>> > your case, then you should not distribute binaries.
>>
>> Sorry to be argumentative, but _no_. We do not vote on binaries. At
>> all. Binaries are conveniences, not part of the release, not covered
>> by Foundation legal protections, not an 'act of the PMC'. See the
>> email chain with Jan I and Bertrand and myself on general@incubator
>> over the last two days.
>>
>> It's a happenstance that corresponding binaries happen to get pushed
>> around by Maven.
>>
>> >
>> >>> 5) Update the incubator/nifi website to point to download links for
>> those
>> >>> items and their signatures/hashes
>> >>>
>> >>> 6) Update the incubator nifi podling status page to indicate this
>> 'news'
>> >>>
>> >>> If that is correct will make it happen and will update the release
>> guide
>> >>> to
>> >>> reflect this.
>> >
>> >
>> > I think that's all.
>> >
>> > Take into account that some processes (particularly mirroring) usually
>> take
>> > up to 24 hours. So you should wait until the release can be officially
>> > announced.
>> >
>> > Cheers,
>> >
>> > --
>> > Sergio Fernández
>> > Partner Technology Manager
>> > Redlink GmbH
>> > m: +43 660 2747 925
>> > e: [hidden email]
>> > w: http://redlink.co
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Sean Busbey
In reply to this post by Benson Margulies
On Thu, Jan 29, 2015 at 7:58 AM, Benson Margulies <[hidden email]>
wrote:

> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> wrote:
> >
> >
> > On 29/01/15 14:35, Benson Margulies wrote:
> >>
> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
> >>>
> >>>
> >
> >>> 4) Build convenience binaries from the source bundles and place those
> >>> along-side the source release in dist.
> >
> >
> > The binaries should be exactly the same that were voted; i.e., the
> checksums
> > _must_ match. If your vote did not include binary releases, which I
> thing is
> > your case, then you should not distribute binaries.
>
> Sorry to be argumentative, but _no_. We do not vote on binaries. At
> all. Binaries are conveniences, not part of the release, not covered
> by Foundation legal protections, not an 'act of the PMC'. See the
> email chain with Jan I and Bertrand and myself on general@incubator
> over the last two days.
>
> It's a happenstance that corresponding binaries happen to get pushed
> around by Maven.
>
>
Benson, do you happen to have the thread subject handy? I'm having some
trouble finding the thread you're referencing.

--
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Joe Witt
Sean,

He is at the very least referring to this exchange involving himself, Jan
I, and Bertrand D:

http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCALhtWkfLgc95eshQBRY6C80Y0v%3Dt4FmmVO-%3Donb2gZPY_3tVrQ%40mail.gmail.com%3E
http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCAK2iWdSgLQLjc09kTmHWbxH19_48zAkr2Awym%2BzsZgqNSPxwkA%40mail.gmail.com%3E
http://mail-archives.apache.org/mod_mbox/incubator-general/201501.mbox/%3CCAEWfVJm8A-04_gX7qSU9pbO3ZNOoA7KbBZaegRX-FFb7AaMXYw%40mail.gmail.com%3E

Of note it is pretty clearly called out in release guides/policy that the
only actual release of the apache software foundation is source code.  The
mechanics of the provision of a binary convenience package is spelled out
and that is it must come exclusively from building the raw source materials
that were voted upon and released.  In addition, the licensing criteria and
policies also spell out the nature of the distinction of 'source'
dependency vs 'binary' dependency.  That is why we got such interesting
feedback about the complexity of our license.

Thanks
Joe

On Thu, Jan 29, 2015 at 9:33 AM, Sean Busbey <[hidden email]> wrote:

> On Thu, Jan 29, 2015 at 7:58 AM, Benson Margulies <[hidden email]>
> wrote:
>
> > On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> > wrote:
> > >
> > >
> > > On 29/01/15 14:35, Benson Margulies wrote:
> > >>
> > >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
> > >>>
> > >>>
> > >
> > >>> 4) Build convenience binaries from the source bundles and place those
> > >>> along-side the source release in dist.
> > >
> > >
> > > The binaries should be exactly the same that were voted; i.e., the
> > checksums
> > > _must_ match. If your vote did not include binary releases, which I
> > thing is
> > > your case, then you should not distribute binaries.
> >
> > Sorry to be argumentative, but _no_. We do not vote on binaries. At
> > all. Binaries are conveniences, not part of the release, not covered
> > by Foundation legal protections, not an 'act of the PMC'. See the
> > email chain with Jan I and Bertrand and myself on general@incubator
> > over the last two days.
> >
> > It's a happenstance that corresponding binaries happen to get pushed
> > around by Maven.
> >
> >
> Benson, do you happen to have the thread subject handy? I'm having some
> trouble finding the thread you're referencing.
>
> --
> Sean
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Billie Rinaldi-2
In reply to this post by Benson Margulies
On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <[hidden email]>
wrote:

> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> wrote:
> >
> >
> > On 29/01/15 14:35, Benson Margulies wrote:
> >>
> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
> >>>
> >>> Mentors (formal or otherwise),
> >>>
> >>> Please confirm I have this correctly.  At the conclusion of the 72 hour
> >>> voting period and assuming a successful outcome I intend to do the
> >>> following steps to conclude the RM duties for this release:
> >>>
> >>> 1) Send out the IPMC vote result e-mail.
> >>>
> >>> 2) In the apache nexus staging repos : 'Release'
> >>>
> >>> 3) Upload the two source release bundles to
> >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> >>
> >>
> >> You might need one of us for this job. Outside the incubator, only PMC
> >> members have access.
> >
> >
> > Don't they get permissions on the incubator dist area?
> >
> >>> 4) Build convenience binaries from the source bundles and place those
> >>> along-side the source release in dist.
> >
> >
> > The binaries should be exactly the same that were voted; i.e., the
> checksums
> > _must_ match. If your vote did not include binary releases, which I
> thing is
> > your case, then you should not distribute binaries.
>
> Sorry to be argumentative, but _no_. We do not vote on binaries. At
> all. Binaries are conveniences, not part of the release, not covered
> by Foundation legal protections, not an 'act of the PMC'. See the
> email chain with Jan I and Bertrand and myself on general@incubator
> over the last two days.
>
> It's a happenstance that corresponding binaries happen to get pushed
> around by Maven.
>

I don't know, Benson.  I need you to convince me a little more.  Based on
the references below, it seems to me that at a minimum we need to verify
any binary artifacts we want to distribute can be built from the source,
have correct signatures and checksums, and have a correct LICENSE and
NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
maven pushes around.  As long as they don't pull in dependencies, they seem
guaranteed to meet all of these requirements.  But the same is not true for
other types of artifacts (wars/nars/tars/zips).  If I read the release page
_really_ carefully it _might_ be saying that only the source package needs
to be voted upon.  I don't know how to reconcile that with the fact that
there are also requirements placed on binary artifacts that the PMC must
verify.

"Release Candidate
    A source package and other accompanying artifacts to be inspected and
voted on in order to release"
(from https://www.apache.org/foundation/glossary.html#ReleaseCandidate)

"Note that the PMC is responsible for all artifacts in their distribution
directory, which is a subdirectory of www.apache.org/dist/ ; and all
artifacts placed in their directory must be signed by a committer,
preferably by a PMC member. It is also necessary for the PMC to ensure that
the source package is sufficient to build any binary artifacts associated
with the release."
(from the release page)

Also:
http://www.apache.org/dev/release.html#distribute-other-artifacts


>
> >
> >>> 5) Update the incubator/nifi website to point to download links for
> those
> >>> items and their signatures/hashes
> >>>
> >>> 6) Update the incubator nifi podling status page to indicate this
> 'news'
> >>>
> >>> If that is correct will make it happen and will update the release
> guide
> >>> to
> >>> reflect this.
> >
> >
> > I think that's all.
> >
> > Take into account that some processes (particularly mirroring) usually
> take
> > up to 24 hours. So you should wait until the release can be officially
> > announced.
> >
> > Cheers,
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: [hidden email]
> > w: http://redlink.co
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Joe Witt
Billie,

I think the statement "now i am worried about the jars" sums it up for me.
In looking at 'prior-art' if you will in this area I looked into the
META-INF/LICENSE files included in artifacts that end up in places like
Maven for other projects.  For example, Accumulo's LICENSE and NOTICE which
applies to the entire project tree calls out a BSD dependency.  Yet in the
artifacts (jar, native.tar.gz) I don't see any reference to it.  Perhaps it
is in one of them but I haven't seen anything beyond the stock
LICENSE/NOTICE [no mention of the BSD dependency accumulo has].  This makes
sense though because the bundled 'stock LICENSE/NOTICE' is what is used in
maven land during the build.  Perhaps it can be overridden but that does
not appear to be common practice.

I too would prefer that our license/notice and perhaps disclaimer be
included in all artifacts.  That said, should that be the case then we also
would need to have a license/notice/disclaimer per artifact so that it
would be specific to that artifact or else it would be too broad and
untrue.  This would be a pretty impressive standard to uphold.

Do you see this as something unique to apache nifi (incubating) or a
broader issue?  My primary concern here is not having our effort held to a
different standard than any other project (assuming I am understanding the
facts correctly).  I do appreciate your diligence in this even if the angst
of wanting our first release out is obvious.

Thanks
Joe

On Thu, Jan 29, 2015 at 9:51 AM, Billie Rinaldi <[hidden email]> wrote:

> On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <[hidden email]>
> wrote:
>
> > On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> > wrote:
> > >
> > >
> > > On 29/01/15 14:35, Benson Margulies wrote:
> > >>
> > >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
> > >>>
> > >>> Mentors (formal or otherwise),
> > >>>
> > >>> Please confirm I have this correctly.  At the conclusion of the 72
> hour
> > >>> voting period and assuming a successful outcome I intend to do the
> > >>> following steps to conclude the RM duties for this release:
> > >>>
> > >>> 1) Send out the IPMC vote result e-mail.
> > >>>
> > >>> 2) In the apache nexus staging repos : 'Release'
> > >>>
> > >>> 3) Upload the two source release bundles to
> > >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> > >>
> > >>
> > >> You might need one of us for this job. Outside the incubator, only PMC
> > >> members have access.
> > >
> > >
> > > Don't they get permissions on the incubator dist area?
> > >
> > >>> 4) Build convenience binaries from the source bundles and place those
> > >>> along-side the source release in dist.
> > >
> > >
> > > The binaries should be exactly the same that were voted; i.e., the
> > checksums
> > > _must_ match. If your vote did not include binary releases, which I
> > thing is
> > > your case, then you should not distribute binaries.
> >
> > Sorry to be argumentative, but _no_. We do not vote on binaries. At
> > all. Binaries are conveniences, not part of the release, not covered
> > by Foundation legal protections, not an 'act of the PMC'. See the
> > email chain with Jan I and Bertrand and myself on general@incubator
> > over the last two days.
> >
> > It's a happenstance that corresponding binaries happen to get pushed
> > around by Maven.
> >
>
> I don't know, Benson.  I need you to convince me a little more.  Based on
> the references below, it seems to me that at a minimum we need to verify
> any binary artifacts we want to distribute can be built from the source,
> have correct signatures and checksums, and have a correct LICENSE and
> NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
> maven pushes around.  As long as they don't pull in dependencies, they seem
> guaranteed to meet all of these requirements.  But the same is not true for
> other types of artifacts (wars/nars/tars/zips).  If I read the release page
> _really_ carefully it _might_ be saying that only the source package needs
> to be voted upon.  I don't know how to reconcile that with the fact that
> there are also requirements placed on binary artifacts that the PMC must
> verify.
>
> "Release Candidate
>     A source package and other accompanying artifacts to be inspected and
> voted on in order to release"
> (from https://www.apache.org/foundation/glossary.html#ReleaseCandidate)
>
> "Note that the PMC is responsible for all artifacts in their distribution
> directory, which is a subdirectory of www.apache.org/dist/ ; and all
> artifacts placed in their directory must be signed by a committer,
> preferably by a PMC member. It is also necessary for the PMC to ensure that
> the source package is sufficient to build any binary artifacts associated
> with the release."
> (from the release page)
>
> Also:
> http://www.apache.org/dev/release.html#distribute-other-artifacts
>
>
> >
> > >
> > >>> 5) Update the incubator/nifi website to point to download links for
> > those
> > >>> items and their signatures/hashes
> > >>>
> > >>> 6) Update the incubator nifi podling status page to indicate this
> > 'news'
> > >>>
> > >>> If that is correct will make it happen and will update the release
> > guide
> > >>> to
> > >>> reflect this.
> > >
> > >
> > > I think that's all.
> > >
> > > Take into account that some processes (particularly mirroring) usually
> > take
> > > up to 24 hours. So you should wait until the release can be officially
> > > announced.
> > >
> > > Cheers,
> > >
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: [hidden email]
> > > w: http://redlink.co
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Sergio Fernández
In reply to this post by Benson Margulies
On 29/01/15 14:58, Benson Margulies wrote:
> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]> wrote:
> Sorry to be argumentative, but _no_. We do not vote on binaries. At
> all. Binaries are conveniences, not part of the release, not covered
> by Foundation legal protections, not an 'act of the PMC'.

Right, binaries produced as a convenience. Usually I like that those
binaries are built together the release, although not strictly under the
vote, for provenance purposes. But that's not a requirements, so never
mind, sorry.

--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: [hidden email]
w: http://redlink.co
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Billie Rinaldi-2
In reply to this post by Joe Witt
On Thu, Jan 29, 2015 at 7:15 AM, Joe Witt <[hidden email]> wrote:

> Billie,
>
> I think the statement "now i am worried about the jars" sums it up for me.
>

To clarify, I said I am NOT worried about the jars.  I'm not worried about
jars (non-shaded jars) because the default license is fine for them.  They
only contain classes built from our own code.  The same is true for
Accumulo's native tarball.  The only Accumulo artifact (that I'm aware of)
that contains dependencies that require mentions in the license and notice
is the binary tarball.  Accumulo is using the same license and notice for
its source and binary tarballs, which is not recommended procedure, but nor
is it sufficient to stop a release.  Otherwise we would not list the BSD
dependencies in the license for the source tarball at all, because they are
not bundled there.  The point is the license should cover whatever is
contained in the actual artifact.  Having more is acceptable, but less is
not.


> In looking at 'prior-art' if you will in this area I looked into the
> META-INF/LICENSE files included in artifacts that end up in places like
> Maven for other projects.  For example, Accumulo's LICENSE and NOTICE which
> applies to the entire project tree calls out a BSD dependency.  Yet in the
> artifacts (jar, native.tar.gz) I don't see any reference to it.  Perhaps it
> is in one of them but I haven't seen anything beyond the stock
> LICENSE/NOTICE [no mention of the BSD dependency accumulo has].  This makes
> sense though because the bundled 'stock LICENSE/NOTICE' is what is used in
> maven land during the build.  Perhaps it can be overridden but that does
> not appear to be common practice.
>
> I too would prefer that our license/notice and perhaps disclaimer be
> included in all artifacts.  That said, should that be the case then we also
> would need to have a license/notice/disclaimer per artifact so that it
> would be specific to that artifact or else it would be too broad and
> untrue.  This would be a pretty impressive standard to uphold.
>

I don't know how other projects handle this -- I'm only familiar with
projects that produce a small number of the kind of artifact that requires
a special license and notice, so it's not a big deal.


>
> Do you see this as something unique to apache nifi (incubating) or a
> broader issue?  My primary concern here is not having our effort held to a
> different standard than any other project (assuming I am understanding the
> facts correctly).  I do appreciate your diligence in this even if the angst
> of wanting our first release out is obvious.
>

You have more than enough +1s for the release.  :-)


>
> Thanks
> Joe
>
> On Thu, Jan 29, 2015 at 9:51 AM, Billie Rinaldi <[hidden email]> wrote:
>
> > On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <[hidden email]
> >
> > wrote:
> >
> > > On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> > > wrote:
> > > >
> > > >
> > > > On 29/01/15 14:35, Benson Margulies wrote:
> > > >>
> > > >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]>
> wrote:
> > > >>>
> > > >>> Mentors (formal or otherwise),
> > > >>>
> > > >>> Please confirm I have this correctly.  At the conclusion of the 72
> > hour
> > > >>> voting period and assuming a successful outcome I intend to do the
> > > >>> following steps to conclude the RM duties for this release:
> > > >>>
> > > >>> 1) Send out the IPMC vote result e-mail.
> > > >>>
> > > >>> 2) In the apache nexus staging repos : 'Release'
> > > >>>
> > > >>> 3) Upload the two source release bundles to
> > > >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> > > >>
> > > >>
> > > >> You might need one of us for this job. Outside the incubator, only
> PMC
> > > >> members have access.
> > > >
> > > >
> > > > Don't they get permissions on the incubator dist area?
> > > >
> > > >>> 4) Build convenience binaries from the source bundles and place
> those
> > > >>> along-side the source release in dist.
> > > >
> > > >
> > > > The binaries should be exactly the same that were voted; i.e., the
> > > checksums
> > > > _must_ match. If your vote did not include binary releases, which I
> > > thing is
> > > > your case, then you should not distribute binaries.
> > >
> > > Sorry to be argumentative, but _no_. We do not vote on binaries. At
> > > all. Binaries are conveniences, not part of the release, not covered
> > > by Foundation legal protections, not an 'act of the PMC'. See the
> > > email chain with Jan I and Bertrand and myself on general@incubator
> > > over the last two days.
> > >
> > > It's a happenstance that corresponding binaries happen to get pushed
> > > around by Maven.
> > >
> >
> > I don't know, Benson.  I need you to convince me a little more.  Based on
> > the references below, it seems to me that at a minimum we need to verify
> > any binary artifacts we want to distribute can be built from the source,
> > have correct signatures and checksums, and have a correct LICENSE and
> > NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
> > maven pushes around.  As long as they don't pull in dependencies, they
> seem
> > guaranteed to meet all of these requirements.  But the same is not true
> for
> > other types of artifacts (wars/nars/tars/zips).  If I read the release
> page
> > _really_ carefully it _might_ be saying that only the source package
> needs
> > to be voted upon.  I don't know how to reconcile that with the fact that
> > there are also requirements placed on binary artifacts that the PMC must
> > verify.
> >
> > "Release Candidate
> >     A source package and other accompanying artifacts to be inspected and
> > voted on in order to release"
> > (from https://www.apache.org/foundation/glossary.html#ReleaseCandidate)
> >
> > "Note that the PMC is responsible for all artifacts in their distribution
> > directory, which is a subdirectory of www.apache.org/dist/ ; and all
> > artifacts placed in their directory must be signed by a committer,
> > preferably by a PMC member. It is also necessary for the PMC to ensure
> that
> > the source package is sufficient to build any binary artifacts associated
> > with the release."
> > (from the release page)
> >
> > Also:
> > http://www.apache.org/dev/release.html#distribute-other-artifacts
> >
> >
> > >
> > > >
> > > >>> 5) Update the incubator/nifi website to point to download links for
> > > those
> > > >>> items and their signatures/hashes
> > > >>>
> > > >>> 6) Update the incubator nifi podling status page to indicate this
> > > 'news'
> > > >>>
> > > >>> If that is correct will make it happen and will update the release
> > > guide
> > > >>> to
> > > >>> reflect this.
> > > >
> > > >
> > > > I think that's all.
> > > >
> > > > Take into account that some processes (particularly mirroring)
> usually
> > > take
> > > > up to 24 hours. So you should wait until the release can be
> officially
> > > > announced.
> > > >
> > > > Cheers,
> > > >
> > > > --
> > > > Sergio Fernández
> > > > Partner Technology Manager
> > > > Redlink GmbH
> > > > m: +43 660 2747 925
> > > > e: [hidden email]
> > > > w: http://redlink.co
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Benson Margulies
In reply to this post by Billie Rinaldi-2
On Thu, Jan 29, 2015 at 9:51 AM, Billie Rinaldi <[hidden email]> wrote:

> On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <[hidden email]>
> wrote:
>
>> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
>> wrote:
>> >
>> >
>> > On 29/01/15 14:35, Benson Margulies wrote:
>> >>
>> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]> wrote:
>> >>>
>> >>> Mentors (formal or otherwise),
>> >>>
>> >>> Please confirm I have this correctly.  At the conclusion of the 72 hour
>> >>> voting period and assuming a successful outcome I intend to do the
>> >>> following steps to conclude the RM duties for this release:
>> >>>
>> >>> 1) Send out the IPMC vote result e-mail.
>> >>>
>> >>> 2) In the apache nexus staging repos : 'Release'
>> >>>
>> >>> 3) Upload the two source release bundles to
>> >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
>> >>
>> >>
>> >> You might need one of us for this job. Outside the incubator, only PMC
>> >> members have access.
>> >
>> >
>> > Don't they get permissions on the incubator dist area?
>> >
>> >>> 4) Build convenience binaries from the source bundles and place those
>> >>> along-side the source release in dist.
>> >
>> >
>> > The binaries should be exactly the same that were voted; i.e., the
>> checksums
>> > _must_ match. If your vote did not include binary releases, which I
>> thing is
>> > your case, then you should not distribute binaries.
>>
>> Sorry to be argumentative, but _no_. We do not vote on binaries. At
>> all. Binaries are conveniences, not part of the release, not covered
>> by Foundation legal protections, not an 'act of the PMC'. See the
>> email chain with Jan I and Bertrand and myself on general@incubator
>> over the last two days.
>>
>> It's a happenstance that corresponding binaries happen to get pushed
>> around by Maven.
>>
>
> I don't know, Benson.  I need you to convince me a little more.  Based on
> the references below, it seems to me that at a minimum we need to verify
> any binary artifacts we want to distribute can be built from the source,
> have correct signatures and checksums, and have a correct LICENSE and
> NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
> maven pushes around.  As long as they don't pull in dependencies, they seem
> guaranteed to meet all of these requirements.  But the same is not true for
> other types of artifacts (wars/nars/tars/zips).  If I read the release page
> _really_ carefully it _might_ be saying that only the source package needs
> to be voted upon.  I don't know how to reconcile that with the fact that
> there are also requirements placed on binary artifacts that the PMC must
> verify.

Billie,

In general, this is an area that makes me want to thread straws
through my rapidly disappearing hair.

How does this model strike you?

1. The official ASF release is just the source.

2. As part of producing software for the public good, many PMCs choose
to create and distribute convenience binaries.

3. These PMCs create policies and procedures that aim to produce
reliable, safe, useful convenience binaries. These might include: (a)
procedures for building them from the precise version of the official
source release, (b) policies for minimizing exposure to malware
injection, (c) ...

4. It is _convenient_ for a PMC to piggy-back some validation of the
procedure onto the official release process. Thus, it's common for the
binaries to be built by the RM at the same time as the source release,
and be available for checking.

5. The incubator has its own special problems. The whole IPMC can't
very well participate in (3) for all of the podlings. So, when the
vote goes from the podling to the whole IPMC, there's a great
opportunity for confusion about the status of the binaries.



>
> "Release Candidate
>     A source package and other accompanying artifacts to be inspected and
> voted on in order to release"
> (from https://www.apache.org/foundation/glossary.html#ReleaseCandidate)
>
> "Note that the PMC is responsible for all artifacts in their distribution
> directory, which is a subdirectory of www.apache.org/dist/ ; and all
> artifacts placed in their directory must be signed by a committer,
> preferably by a PMC member. It is also necessary for the PMC to ensure that
> the source package is sufficient to build any binary artifacts associated
> with the release."
> (from the release page)
>
> Also:
> http://www.apache.org/dev/release.html#distribute-other-artifacts
>
>
>>
>> >
>> >>> 5) Update the incubator/nifi website to point to download links for
>> those
>> >>> items and their signatures/hashes
>> >>>
>> >>> 6) Update the incubator nifi podling status page to indicate this
>> 'news'
>> >>>
>> >>> If that is correct will make it happen and will update the release
>> guide
>> >>> to
>> >>> reflect this.
>> >
>> >
>> > I think that's all.
>> >
>> > Take into account that some processes (particularly mirroring) usually
>> take
>> > up to 24 hours. So you should wait until the release can be officially
>> > announced.
>> >
>> > Cheers,
>> >
>> > --
>> > Sergio Fernández
>> > Partner Technology Manager
>> > Redlink GmbH
>> > m: +43 660 2747 925
>> > e: [hidden email]
>> > w: http://redlink.co
>>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Joe Witt
In reply to this post by Billie Rinaldi-2
billie

thanks.  My apologies for missing the 'not' in that.

Thanks for the comments.  We will make this better.

Joe

On Thu, Jan 29, 2015 at 10:45 AM, Billie Rinaldi <[hidden email]> wrote:

> On Thu, Jan 29, 2015 at 7:15 AM, Joe Witt <[hidden email]> wrote:
>
> > Billie,
> >
> > I think the statement "now i am worried about the jars" sums it up for
> me.
> >
>
> To clarify, I said I am NOT worried about the jars.  I'm not worried about
> jars (non-shaded jars) because the default license is fine for them.  They
> only contain classes built from our own code.  The same is true for
> Accumulo's native tarball.  The only Accumulo artifact (that I'm aware of)
> that contains dependencies that require mentions in the license and notice
> is the binary tarball.  Accumulo is using the same license and notice for
> its source and binary tarballs, which is not recommended procedure, but nor
> is it sufficient to stop a release.  Otherwise we would not list the BSD
> dependencies in the license for the source tarball at all, because they are
> not bundled there.  The point is the license should cover whatever is
> contained in the actual artifact.  Having more is acceptable, but less is
> not.
>
>
> > In looking at 'prior-art' if you will in this area I looked into the
> > META-INF/LICENSE files included in artifacts that end up in places like
> > Maven for other projects.  For example, Accumulo's LICENSE and NOTICE
> which
> > applies to the entire project tree calls out a BSD dependency.  Yet in
> the
> > artifacts (jar, native.tar.gz) I don't see any reference to it.  Perhaps
> it
> > is in one of them but I haven't seen anything beyond the stock
> > LICENSE/NOTICE [no mention of the BSD dependency accumulo has].  This
> makes
> > sense though because the bundled 'stock LICENSE/NOTICE' is what is used
> in
> > maven land during the build.  Perhaps it can be overridden but that does
> > not appear to be common practice.
> >
> > I too would prefer that our license/notice and perhaps disclaimer be
> > included in all artifacts.  That said, should that be the case then we
> also
> > would need to have a license/notice/disclaimer per artifact so that it
> > would be specific to that artifact or else it would be too broad and
> > untrue.  This would be a pretty impressive standard to uphold.
> >
>
> I don't know how other projects handle this -- I'm only familiar with
> projects that produce a small number of the kind of artifact that requires
> a special license and notice, so it's not a big deal.
>
>
> >
> > Do you see this as something unique to apache nifi (incubating) or a
> > broader issue?  My primary concern here is not having our effort held to
> a
> > different standard than any other project (assuming I am understanding
> the
> > facts correctly).  I do appreciate your diligence in this even if the
> angst
> > of wanting our first release out is obvious.
> >
>
> You have more than enough +1s for the release.  :-)
>
>
> >
> > Thanks
> > Joe
> >
> > On Thu, Jan 29, 2015 at 9:51 AM, Billie Rinaldi <[hidden email]>
> wrote:
> >
> > > On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]
> >
> > > > wrote:
> > > > >
> > > > >
> > > > > On 29/01/15 14:35, Benson Margulies wrote:
> > > > >>
> > > > >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]>
> > wrote:
> > > > >>>
> > > > >>> Mentors (formal or otherwise),
> > > > >>>
> > > > >>> Please confirm I have this correctly.  At the conclusion of the
> 72
> > > hour
> > > > >>> voting period and assuming a successful outcome I intend to do
> the
> > > > >>> following steps to conclude the RM duties for this release:
> > > > >>>
> > > > >>> 1) Send out the IPMC vote result e-mail.
> > > > >>>
> > > > >>> 2) In the apache nexus staging repos : 'Release'
> > > > >>>
> > > > >>> 3) Upload the two source release bundles to
> > > > >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> > > > >>
> > > > >>
> > > > >> You might need one of us for this job. Outside the incubator, only
> > PMC
> > > > >> members have access.
> > > > >
> > > > >
> > > > > Don't they get permissions on the incubator dist area?
> > > > >
> > > > >>> 4) Build convenience binaries from the source bundles and place
> > those
> > > > >>> along-side the source release in dist.
> > > > >
> > > > >
> > > > > The binaries should be exactly the same that were voted; i.e., the
> > > > checksums
> > > > > _must_ match. If your vote did not include binary releases, which I
> > > > thing is
> > > > > your case, then you should not distribute binaries.
> > > >
> > > > Sorry to be argumentative, but _no_. We do not vote on binaries. At
> > > > all. Binaries are conveniences, not part of the release, not covered
> > > > by Foundation legal protections, not an 'act of the PMC'. See the
> > > > email chain with Jan I and Bertrand and myself on general@incubator
> > > > over the last two days.
> > > >
> > > > It's a happenstance that corresponding binaries happen to get pushed
> > > > around by Maven.
> > > >
> > >
> > > I don't know, Benson.  I need you to convince me a little more.  Based
> on
> > > the references below, it seems to me that at a minimum we need to
> verify
> > > any binary artifacts we want to distribute can be built from the
> source,
> > > have correct signatures and checksums, and have a correct LICENSE and
> > > NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
> > > maven pushes around.  As long as they don't pull in dependencies, they
> > seem
> > > guaranteed to meet all of these requirements.  But the same is not true
> > for
> > > other types of artifacts (wars/nars/tars/zips).  If I read the release
> > page
> > > _really_ carefully it _might_ be saying that only the source package
> > needs
> > > to be voted upon.  I don't know how to reconcile that with the fact
> that
> > > there are also requirements placed on binary artifacts that the PMC
> must
> > > verify.
> > >
> > > "Release Candidate
> > >     A source package and other accompanying artifacts to be inspected
> and
> > > voted on in order to release"
> > > (from https://www.apache.org/foundation/glossary.html#ReleaseCandidate
> )
> > >
> > > "Note that the PMC is responsible for all artifacts in their
> distribution
> > > directory, which is a subdirectory of www.apache.org/dist/ ; and all
> > > artifacts placed in their directory must be signed by a committer,
> > > preferably by a PMC member. It is also necessary for the PMC to ensure
> > that
> > > the source package is sufficient to build any binary artifacts
> associated
> > > with the release."
> > > (from the release page)
> > >
> > > Also:
> > > http://www.apache.org/dev/release.html#distribute-other-artifacts
> > >
> > >
> > > >
> > > > >
> > > > >>> 5) Update the incubator/nifi website to point to download links
> for
> > > > those
> > > > >>> items and their signatures/hashes
> > > > >>>
> > > > >>> 6) Update the incubator nifi podling status page to indicate this
> > > > 'news'
> > > > >>>
> > > > >>> If that is correct will make it happen and will update the
> release
> > > > guide
> > > > >>> to
> > > > >>> reflect this.
> > > > >
> > > > >
> > > > > I think that's all.
> > > > >
> > > > > Take into account that some processes (particularly mirroring)
> > usually
> > > > take
> > > > > up to 24 hours. So you should wait until the release can be
> > officially
> > > > > announced.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > --
> > > > > Sergio Fernández
> > > > > Partner Technology Manager
> > > > > Redlink GmbH
> > > > > m: +43 660 2747 925
> > > > > e: [hidden email]
> > > > > w: http://redlink.co
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [mentor advice request] release process final steps

Billie Rinaldi-2
In reply to this post by Benson Margulies
On Thu, Jan 29, 2015 at 7:45 AM, Benson Margulies <[hidden email]>
wrote:

> On Thu, Jan 29, 2015 at 9:51 AM, Billie Rinaldi <[hidden email]> wrote:
> > On Thu, Jan 29, 2015 at 5:58 AM, Benson Margulies <[hidden email]
> >
> > wrote:
> >
> >> On Thu, Jan 29, 2015 at 8:52 AM, Sergio Fernández <[hidden email]>
> >> wrote:
> >> >
> >> >
> >> > On 29/01/15 14:35, Benson Margulies wrote:
> >> >>
> >> >> On Thu, Jan 29, 2015 at 7:43 AM, Joe Witt <[hidden email]>
> wrote:
> >> >>>
> >> >>> Mentors (formal or otherwise),
> >> >>>
> >> >>> Please confirm I have this correctly.  At the conclusion of the 72
> hour
> >> >>> voting period and assuming a successful outcome I intend to do the
> >> >>> following steps to conclude the RM duties for this release:
> >> >>>
> >> >>> 1) Send out the IPMC vote result e-mail.
> >> >>>
> >> >>> 2) In the apache nexus staging repos : 'Release'
> >> >>>
> >> >>> 3) Upload the two source release bundles to
> >> >>> https://dist.apache.org/repos/dist/release/incubator/nifi/
> >> >>
> >> >>
> >> >> You might need one of us for this job. Outside the incubator, only
> PMC
> >> >> members have access.
> >> >
> >> >
> >> > Don't they get permissions on the incubator dist area?
> >> >
> >> >>> 4) Build convenience binaries from the source bundles and place
> those
> >> >>> along-side the source release in dist.
> >> >
> >> >
> >> > The binaries should be exactly the same that were voted; i.e., the
> >> checksums
> >> > _must_ match. If your vote did not include binary releases, which I
> >> thing is
> >> > your case, then you should not distribute binaries.
> >>
> >> Sorry to be argumentative, but _no_. We do not vote on binaries. At
> >> all. Binaries are conveniences, not part of the release, not covered
> >> by Foundation legal protections, not an 'act of the PMC'. See the
> >> email chain with Jan I and Bertrand and myself on general@incubator
> >> over the last two days.
> >>
> >> It's a happenstance that corresponding binaries happen to get pushed
> >> around by Maven.
> >>
> >
> > I don't know, Benson.  I need you to convince me a little more.  Based on
> > the references below, it seems to me that at a minimum we need to verify
> > any binary artifacts we want to distribute can be built from the source,
> > have correct signatures and checksums, and have a correct LICENSE and
> > NOTICE (possibly also DISCLAIMER).  Now, I'm not worried about the jars
> > maven pushes around.  As long as they don't pull in dependencies, they
> seem
> > guaranteed to meet all of these requirements.  But the same is not true
> for
> > other types of artifacts (wars/nars/tars/zips).  If I read the release
> page
> > _really_ carefully it _might_ be saying that only the source package
> needs
> > to be voted upon.  I don't know how to reconcile that with the fact that
> > there are also requirements placed on binary artifacts that the PMC must
> > verify.
>
> Billie,
>
> In general, this is an area that makes me want to thread straws
> through my rapidly disappearing hair.
>
> How does this model strike you?
>
> 1. The official ASF release is just the source.
>
> 2. As part of producing software for the public good, many PMCs choose
> to create and distribute convenience binaries.
>
> 3. These PMCs create policies and procedures that aim to produce
> reliable, safe, useful convenience binaries. These might include: (a)
> procedures for building them from the precise version of the official
> source release, (b) policies for minimizing exposure to malware
> injection, (c) ...
>
> 4. It is _convenient_ for a PMC to piggy-back some validation of the
> procedure onto the official release process. Thus, it's common for the
> binaries to be built by the RM at the same time as the source release,
> and be available for checking.
>
> 5. The incubator has its own special problems. The whole IPMC can't
> very well participate in (3) for all of the podlings. So, when the
> vote goes from the podling to the whole IPMC, there's a great
> opportunity for confusion about the status of the binaries.
>

Sounds good to me!


>
>
>
> >
> > "Release Candidate
> >     A source package and other accompanying artifacts to be inspected and
> > voted on in order to release"
> > (from https://www.apache.org/foundation/glossary.html#ReleaseCandidate)
> >
> > "Note that the PMC is responsible for all artifacts in their distribution
> > directory, which is a subdirectory of www.apache.org/dist/ ; and all
> > artifacts placed in their directory must be signed by a committer,
> > preferably by a PMC member. It is also necessary for the PMC to ensure
> that
> > the source package is sufficient to build any binary artifacts associated
> > with the release."
> > (from the release page)
> >
> > Also:
> > http://www.apache.org/dev/release.html#distribute-other-artifacts
> >
> >
> >>
> >> >
> >> >>> 5) Update the incubator/nifi website to point to download links for
> >> those
> >> >>> items and their signatures/hashes
> >> >>>
> >> >>> 6) Update the incubator nifi podling status page to indicate this
> >> 'news'
> >> >>>
> >> >>> If that is correct will make it happen and will update the release
> >> guide
> >> >>> to
> >> >>> reflect this.
> >> >
> >> >
> >> > I think that's all.
> >> >
> >> > Take into account that some processes (particularly mirroring) usually
> >> take
> >> > up to 24 hours. So you should wait until the release can be officially
> >> > announced.
> >> >
> >> > Cheers,
> >> >
> >> > --
> >> > Sergio Fernández
> >> > Partner Technology Manager
> >> > Redlink GmbH
> >> > m: +43 660 2747 925
> >> > e: [hidden email]
> >> > w: http://redlink.co
> >>
>