Will do thanks. Just to be clear -- the META-INF dir with the binary L&N files will be removed and the binary-related L&N files will be moved to as assembly directory (or something similar) when we break out the submodules. In the meantime the META-INF (with binary L&N files) as in the PR will be merged after adding the README as suggested. Folks will be responsible for updating the binary L&N files as they add dependencies.
On Sat, Aug 20, 2016 at 12:41 PM, Suneel Marthi <[email protected]> wrote: > +1 > > On Sat, Aug 20, 2016 at 12:40 PM, Tim Ellison <[email protected]> > wrote: > > > On 20 August 2016 at 17:04, Ellison Anne Williams < > > [email protected]> > > wrote: > > > > > Yes, if that's acceptable, then I can go that route. > > > > > > I can allow the artifacts to be generated and pushed to Nexus, I can > > remove > > > the binary artifacts, fix the L&N files, rehash/sign, and upload. > Then, I > > > can close the repo (which will run through all signing verifications) > and > > > provide the URL for voting. Once we get the submodules in place, the > L&N > > > file placement will be taken care of automatically for binary artifacts > > and > > > the manual intervention won't be necessary. > > > > > > Would it be OK to go ahead and merge the PR with the binary L&N files > in > > > the bin-license-notice dir in META-INF? That way, folks can be > > responsible > > > for keeping them updated as they add any new dependencies. > > > > > > > That works for me. Unless other mentors object, I say we go with this > > plan. > > > > To avoid any confusion you may want to consider creating a brief readme > > file in the META-INF to explain that the L&N files in there only relate > to > > the exe-jar. > > > > Regards, > > Tim > > > > > > > > > On Sat, Aug 20, 2016 at 11:51 AM, Tim Ellison <[email protected]> > > > wrote: > > > > > > > On 20 August 2016 at 16:23, Ellison Anne Williams < > > > > [email protected]> > > > > wrote: > > > > > > > > > Thanks Tim - yes, I've been following that thread with interest. To > > > speak > > > > > to the documentation for Pirk releases, I have been working on a > page > > > for > > > > > the website documenting our release process (and the gotchas) > > > > step-by-step. > > > > > Once we complete a successful release vote internally, I will put > > forth > > > > the > > > > > page for comment. I agree with the discussion on the > > general@incubator > > > > > thread that the release process for a project needs to be > documented > > > such > > > > > that anyone can walk into the project and complete a release - it > > > > shouldn't > > > > > be a mystical endeavor. > > > > > > > > > > > > I don't know precisely what steps you are following at the moment, > but > > if > > > > there is an opportunity to manually intervene and fix-up the binary > JAR > > > > licenses before the artefacts are hashed / signed / uploaded then > that > > > > could simply be a "documented step" until the scripts handle it all. > > > > > > > > ... or even produce the JAR, then > > > > - delete the exe-jar's sig/hash > > > > - rearrange the L&N files > > > > - re-sign/hash > > > > > > > > Provided it is a repeatable process for the binaries, I think that > > would > > > be > > > > ok. > > > > > > > > WDYT? > > > > > > > > Regards, > > > > Tim > > > > > > > > > > > > > On Sat, Aug 20, 2016 at 10:58 AM, Tim Ellison < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > On 20 August 2016 at 04:52, Ellison Anne Williams < > > > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > After spending a bit of time taking a look at the submodule > > > > breakout, I > > > > > > > would rather wait and break the project out into submodules in > a > > > more > > > > > > > deliberate manner (not as a first pass just for the binary > > > > artifacts). > > > > > > > > > > > > > > As submodules seem to be required to get the L&N files for > binary > > > > > > > distributions up to par, I propose that we proceed with a > source > > > only > > > > > > > release now. We will slate the submodules for our next release > > (or > > > > so). > > > > > > > > > > > > > > We've certainly learned tons about the release process over the > > > last > > > > > week > > > > > > > and I think that it would be good to go ahead and exercise the > > full > > > > > > process > > > > > > > to completion. > > > > > > > > > > > > > > Unless anyone objects, I will try to get the source release > > > artifacts > > > > > up > > > > > > > for voting over the weekend. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > Sure. Thanks for your continued focus on this Ellison Anne. > > > > > > > > > > > > FYI there is a discussion underway on [email protected] that > > is > > > > > > relevant to this thread... > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator- > > > > general/201608.mbox/% > > > > > > 3C5113b38e-e52b-0c16-eced-903e00fc4477%40apache.org%3E > > > > > > > > > > > > I mention it as I expect the Incubator PMC are likely to assess > > > Pirk's > > > > > > release by this criteria, given it will be fresh in people's mind > > > when > > > > > our > > > > > > vote is proposed. > > > > > > > > > > > > Regards, > > > > > > Tim > > > > > > > > > > > > > > > > > > > > >
