Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
Yes. I expected we would just do a follow-on when we have cycles. Take the
win! :)
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@nickwallen @mmiklavc @ottobackwards While I'm loath to look gift +1's in
the mouth, the KEYS file issue still isn't resolved. Is everyone okay with me
making a follow-on ticket to address it
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1188
+1 from me, great improvements.
---
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1188
+1 by inspection pending your README for @ottobackwards
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
Don't worry about it. I think this is a big step forward. +1 by
inspection from me.
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
I'm open to suggestions on that (is there a way to just sign without a key
or something in gpg?). I'll dig around and see if I can find something, too.
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@nickwallen Not really? The key doesn't need to be in the KEYS file, but
the artifacts themselves all have to be signed. We could make it optional but
then half of the process isn't being done
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
Is there any way to do a dry run on this myself without having a signing
key? What do I enter here?
```
signing key id in 8-byte format (e.g. BADDCAFEDEADBEEF):
```
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@ottobackwards README added, let me know if there's anything else you want
to see in it. I limited it to just this script, so the validate and rc check
scripts aren't in the README right now.
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
I assumed this would mostly be documented in the release process wiki, but
I can definitely add a readme
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/1188
It may be time for a README for these scripts
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@nickwallen Updated the script.
I did a few things in the latest commits.
* reorganized slightly the order of prompts
* Fixed the last (non-KEYS file) TODO
* Uncommented out
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@nickwallen Same as my last comment. It's been pretty refactored since the
release (in order to handle the discussion we had around releases going
forward). I just haven't had time to sit down
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
What is the state of this @justinleet ? Did it work well for you during
the last release?
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
> @justinleet: that's because we tar up the rc and just rename the tar.gz
file when it gets promoted. It's expected (and occurs on our previous
releases). To add onto that, I don't know what
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
To add onto that, I don't know what other projects actually do about that
(they may not, in which case we might want to modify what we do). E.g. create
the folder without the suffix and rename
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
@nickwallen that's because we tar up the rc and just rename the tar.gz file
when it gets promoted. It's expected (and occurs on our previous releases)
---
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
@justinleet One thing I just noticed is that when you download the release
tarball from a mirror the file `apache-metron-0.6.0.tar.gz` contains a
directory called `apache-metron-0.6.0-rc1`. I
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
Most of the refactoring for separating the repos is done. The script
changed around a lot, but is largely relocating + making input easier/more
valid. Couple bit and pieces here and there left
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
FWIW - Your changes to `metron-rc-check` worked perfectly. I validated
that during 0.6.0 RC1
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
Per [a discuss
thread](https://lists.apache.org/thread.html/b651737261c712deb83b11750033372916698780c35522263e949095@%3Cdev.metron.apache.org%3E),
going forward we plan on splitting the releases
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
> I'm assuming this always pulls HEAD from master to cut the release. Do we
need or desire any support for cutting a release from a non-HEAD commit?
I'd also completely support doing
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1188
Trying this again on the PR itself :-)
Yeah, the Angular upgrade was the other bit that came to mind. Shane's PR
for the Angular upgrade has the necessary +1's, but @nickwallen you had
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
I could be wrong, but I think we've been fairly loose about it. Matt may
have done some management of it, but it would have been entirely manual. In
most cases we should be able to release
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1188
> I'm assuming this always pulls HEAD from master to cut the release. Do we
need or desire any support for cutting a release from a non-HEAD commit?
It would be very useful to continue
Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/1188
I'm assuming this always pulls HEAD from master to cut the release. Do we
need or desire any support for cutting a release from a non-HEAD commit? Also,
wondering if we need to consider
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1188
That's definitely an option. I know offhand there's a few more similar
flags (e.g. -o pipefail), which may also be useful. It might be sufficient, at
least as a first cut.
---
27 matches
Mail list logo
