FYI: Just created PR around master branch:
https://github.com/apache/storm/pull/2253
I'll apply this to other version line branches as well, so please take a
look at this and comment. I'll just apply this in tomorrow if no
outstanding comment is seen.
2017년 8월 2일 (수) 오전 6:41, Jungtaek Lim
Forgot to say, +1 on Stig's explanation. I don't see critical issue from
locating release note (previously CHANGELOG) file.
After releasing, release note on website will also have static
representation (string content) of CHANGELOG so we will provide CHANGELOG
at least two places.
I'll bring
I'm seeing several voices worrying about JIRA update.
I think the main reason to miss to update is that we're doing it manually.
If you remember the PR about adopting Kafka merge script, it also updates
corresponding JIRA issue at the end of merge. If you're not aware of,
please refer
Would it fit alongside the other release artifacts in e.g.
https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.1.1-rc2/? That
seems to be what Kafka is doing as well
https://dist.apache.org/repos/dist/release/kafka/0.11.0.0/.
If we could put the change log up along the other artifacts, we
A couple thoughts/questions regarding the mechanics of publishing the resulting
HTML file.
When voting on release candidates, in the past we point to the CHANGELOG file
in git. What would we do in this case?
My assumption is the release manager would generate the file and post it to
their
Opened JIRA here https://issues.apache.org/jira/browse/STORM-2665 and took
a look at adjusting Kafka's script here
https://github.com/apache/storm/pull/2250
2017-07-31 21:02 GMT+02:00 Bobby Evans :
> So it looks like we all agree, now we just need someone to file a
So it looks like we all agree, now we just need someone to file a JIRA and a
corresponding pull request. The kafka script looks like a good place to start,
but we can iterate on it in the pull request to try and address Taylor's
concern about JIRA not being up to date. I would love to do it,
I’m all for getting rid of the current process for CHANGELOG. My only concern
with any JIRA-based solution is that we would need to be very good about
setting the “Fix Version” field properly when merging a patch and updating the
associated ticket. In the past I’ve seen a lot of patches merged
Maybe we could adapt the script Kafka uses? It looks simple enough
https://github.com/apache/kafka/blob/trunk/release_notes.py. I think the
release notes they have are very readable.
2017-07-31 16:06 GMT+02:00 Bobby Evans :
> I am happy to switch as soon as someone
I am happy to switch as soon as someone has a working alternative. The big
thing in my opinion is giving end users a clear list of all of the changes that
went into a release so they can review it for themselves. However we do it is
fine with me as the current changelog file leaves a lot to
Let me also put long ago discussion about this:
http://search-hadoop.com/m/Storm/8gnYyUdhVp1eajp31?subj=+DISCUSSION+More+convenient+way+to+maintain+committer+contributor+list+and+changelogs
In my view, from long ago discussion, Haohui and Bobby agreed to not
maintain CHANGELOG by hand. Haohui
correction: other projects -> *some* other projects, though they're popular
projects (including in competition)
2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim 님이 작성:
> I'm happy that there're other guys having same difficult and sharing same
> feeling.
>
> This discussion has been
I'm happy that there're other guys having same difficult and sharing same
feeling.
This discussion has been initiating several times (from me) and getting
some +1s for each thread but didn't reach to actual work.
We already utilize JIRA, and I'm subscribing issues@ and taking care of
issues
We already have to keep JIRA updated, and keeping JIRA consistent is easier
since there isn't one view of the resolved issues for each git branch like
we have with CHANGELOG, so there's no worry about e.g. master having a
different opinion on solved issues in 1.2.0 than 1.x-branch has.
I think we
I am +1 for discontinuing CHANGELOG. However, using JIRA to compile this info
will only work if contributors are very disciplined and consistent updating
JIRA. That leads to the question, is it any easier to maintain JIRA consistent
then it is to keep CHANGELOG consistent? A clean and
Sorry to necro this thread, but I think it's worth bringing this issue up
again. As Jungtaek mentioned a manual changelog is easy to break, and it
looks like some issues are listed wrong on master and missing from 1.x (
https://github.com/apache/storm/pull/2245)
I think dropping CHANGELOG is a
This propose will make merge process simpler, so I guess committers/PMCs
might not have strong opinions about this. I'm concerning mainly about how
it will affect release process.
Taylor, I guess you're busy, but could you give your opinion about this as
a release manager? Would removing
LGTM. I give a +1 for the idea.
2017-03-07 9:29 GMT+08:00 Jungtaek Lim :
> Bump. I think it's not that trivial for code merger and release manager,
> and even contributors (how to represent their contributions.)
>
> 2017년 2월 24일 (금) 오전 9:43, Roshan Naik
Bump. I think it's not that trivial for code merger and release manager,
and even contributors (how to represent their contributions.)
2017년 2월 24일 (금) 오전 9:43, Roshan Naik 님이 작성:
> Sounds like a good idea to me.
> -roshan
>
> On 2/23/17, 4:41 PM, "Jungtaek Lim"
Sounds like a good idea to me.
-roshan
On 2/23/17, 4:41 PM, "Jungtaek Lim" wrote:
Hi devs,
I guess we discussed about this before, but didn't move to actual work.
I'd like to propose again removing CHANGELOG file in repository, and use
JIRA issue's
Hi devs,
I guess we discussed about this before, but didn't move to actual work.
I'd like to propose again removing CHANGELOG file in repository, and use
JIRA issue's fixed version(s).
Maintaining CHANGELOG to file is really easy to break. I've seen several
times and most of them is about
21 matches
Mail list logo