It's also possible that a mentor already has the karma to create it (I
have no idea how the permissions are controlled tbh). I made a guess
that it will require infra-support, but I think you gave enough
information :)
Joe Witt wrote:
Took at a stab at the infra ticket:
https://issues.apache.org/jira/browse/INFRA-8992
Didn't quite understand what i was asking for so there is a non-zero chance
of that not working out.
Thanks
Joe
On Wed, Jan 7, 2015 at 10:22 PM, Joe Witt<[email protected]> wrote:
Josh
Awesome.
Honestly I believe we're good on the LICENSE, NOTICE, DISCLAIMER, README.
All dependencies have been reviewed and checked for ASLv2 compatibility.
Will submit the infra ticket now for the dist/ path for keys files and
such.
My guess is that the release artifact should be a tarball of all source.
Could we literally just package up a clean source tree? Anyone else have
views on this?
Ideally with this release we'd do it all properly including maven
artifacts, sources/javadocs, and so on. The Maven build does already
operate now off a single command at the root to build everything
(build-order is gone) and inherits from the apache parent.
Will need to incorporate RAT.
Thanks for all that - definitely gives some stuff to work on and look into.
Thanks
Joe
On Wed, Jan 7, 2015 at 10:10 PM, Josh Elser<[email protected]> wrote:
Regardless of what you call it, writing down exactly what was done to
make a RC is extremely important early on (I know that I sure can't
remember what I did last week, much less last release). I'm not sure if
release guide is formally defined somewhere, but enough information that
any other committer can come by after "you get hit by a train" and make a
release is extremely important. Using the CMS and making a page on the
website for this is extremely easy to do, IMO.
Another concern for how to actually make a release is the type of
packaging that is released. I not talking about the source/binary release
here, literally "what is Apache NiFi 0.0.1-incubating"? Is it a tarball?
Are there jars in Maven? etc. A tarball is pretty easy to make, and likely
the closest to what the build-order.sh script already does (with Maven's
help). I'm not sure if maven-released artifacts are quite as important at
this point -- if it's not, punting on that will help. If/when you get to
that point, look into the apache parent pom[1]. It is extremely well
automated to use the existing infrastructure to do it all for you.
Without looking at official documentation (which is me being lazy,
sorry), some other things that will need to be thought about:
Start with the releases page [2]
* You *must* include a source artifact. It cannot have binaries. No Java
class files, no jars. A user must be able to download the source artifact
and build it all themselves. Artifacts which include binaries are for
user-convenience only and can optionally be provided as well.
* LICENSE, NOTICE and README must all be included in the top level of the
artifact. The NOTICE is the most painful and must include any required
third-party notices. [3]
* You will need to audit your dependencies to make sure that they are
ASLv2 compatible [4]
* Releases must be cryptographically signed (PGP) [5]. Your public key
should be published to known sites (e.g. pgp.mit.edu) and must be listed
in NiFi's KEYS file [6] (which does not yet exist, probably needs an infra
ticket to create your dist/ directory?).
* Verify that every source file contain the proper ASL header. The
release-audit-tool[7] (`mvn apache-rat:check`) is a wonderful tool that can
(and should, IMO) be integrated into your build process to prevent people
from accidentally committing new files between releases that do not have
the correct header.
And suddenly, this is really long :). Short answer: decide what the
release should look like (just a tarball?), start vetting your source code
for license headers, and looking into NiFi's dependencies and their
licenses.
[1] http://maven.apache.org/pom/asf/
[2] http://www.apache.org/dev/release.html
[3] http://www.apache.org/legal/src-headers.html
[4] http://www.apache.org/legal/resolved.html#category-x
[5] http://www.apache.org/dev/release-signing.html
[6] http://www.apache.org/dist/incubator/nifi/KEYS
[7] http://creadur.apache.org/rat/
Tony Kurc wrote:
I read the guide Joe linked and a lot of the sticky parts are marked
"TODO"
and it looks like a work in progress
"Podlings can short circuit this process by starting out with written
release documentation. It is strongly recommended that Podlings invest
time
looking at the best practices recommended in this document. By selection
and modification, sections of this document can be used to quickly and
easily bootstrap a release guide. "
Is step one putting together a release guide?
On Wed, Jan 7, 2015 at 9:26 PM, Joe Witt<[email protected]> wrote:
Hello
Just wanted to stir this one up a bit. Looks like all tickets pegged as
0.0.1 are resolved (2 remain as of now but seem likely to be resolved
shortly based on their comments). So working through the release steps
available on apache.org and via the link Brock sent.
Anyone interested in this part of the process or who has advice to help
us
avoid landmines we're happy to hear it.
Thanks
Joe
On Thu, Dec 18, 2014 at 1:31 PM, Joe Witt<[email protected]> wrote:
Thanks Brock this is very helpful.
On Thu, Dec 18, 2014 at 1:27 PM, Brock Noland<[email protected]>
wrote:
Hi,
This is a decent guide which can be copied:
http://mrunit.apache.org/pmc/how_to_release.html
Brock
On Thu, Dec 18, 2014 at 10:17 AM, Joe Witt<[email protected]>
wrote:
Folks,
Looking at the tickets that remain which are presently tied to 0.0.1
we're
probably 1-2 weeks out from this initial release. Can you provide
some
pointers/references or pointers on how to get this ball rolling and
any
rocks we must move before going down this path?
http://incubator.apache.org/guides/releasemanagement.html
That link seems really helpful but has a lot of TODOs for areas which
need
more explanation.
Thanks
Joe
