What about a Jenkins job for detecting the diff between jira and git?
And I agree that, let's not include CHANGES.md and RELEASENOTES.md in our
code base directly which means we need to sink an RC only if these two
files are incorrect, not the actual code.
Andrew Purtell <apurt...@apache.org> 于2021年1月16日周六 上午11:11写道：
> I think the discussion has already moved forward a lot with mention of
> scripts I did not know existed. One well developed git<->jira diff tool,
> documented as part of the RM procedure, would be much better than we have
> right now, with various RMs doing ad hoc things.
>
>
> On Fri, Jan 15, 2021 at 6:04 PM 张铎(Duo Zhang) <palomino...@gmail.com>
> wrote:
>
> > Haven't fully read all the comments but I think this is the duty for the
> > release manager? This is what I use to get the difference between jira
> and
> > git
> >
> > git log --oneline 0167558eb31ff48308d592ef70b6d005ba6d21fb...3ee8b0c75b |
> > grep -o -E "^[0-9a-z]*\s*HBASE-[0-9]*"|awk '{print $2}' | sort -u >
> > in_git_2.0.0.txt
> > cat CHANGELOG.md | grep -o -E "\[HBASE-[0-9]*\]" | grep -o -E
> > "HBASE-[0-9]*" | sort -u > CHANGELOG_jiras.txt
> >
> > And then you could use comm to get the difference.
> >
> > We all make mistakes so this process can not be automatic, trust me.
> > Sometimes a commit is reverted and never applied again, sometimes we
> > include the wrong jira id in commit message.
> > This is why I always use a jira issue to land the CHANGES and
> RELEASENOTES,
> > tag it, and then use the release script to generate the RC.
> >
> > For me, it will cost me a lot of time when creating a new minor release
> > because there will be a lot of commits, but for a patch release usually
> it
> > is fine.
> >
> > Maybe things will be easier if we move all the development process to
> > github?
> >
> > Thanks.
> >
> > Sean Busbey <bus...@apache.org> 于2021年1月16日周六 上午8:05写道：
> >
> > > What would the logistics look like for git as the source of truth?
> > >
> > > Every release candidate I've ever done I've had to do the jira and git
> > > reconciliation. There are always errors in both. Folks commit stuff
> with
> > > the wrong JIRA ID or wrong message.
> > >
> > > Would reconciliation for a RM then require revert and reapply of any
> such
> > > changes?
> > >
> > > On Fri, Jan 15, 2021, 17:54 Stack <st...@duboce.net> wrote:
> > >
> > > > On Fri, Jan 15, 2021 at 10:06 AM Andrew Purtell <apurt...@apache.org
> >
> > > > wrote:
> > > >
> > > > > I have now had to sink two 2.4.1 RCs because of errors in the
> change
> > > log.
> > > > >
> > > > > I made a pass over git history and ensured every commit was
> > included. I
> > > > had
> > > > > also made a pass over JIRA to move out any unresolved issues or
> > > complete
> > > > > the resolution of same. What I did not do is check that every
> > resolved
> > > > JIRA
> > > > > corresponded to an actual commit. This is not something RMs have
> had
> > to
> > > > do
> > > > > in the past and it asks a lot of them.
> > > > >
> > > > >
> > > > Just to say, that making RCs, I've the done the JIRA<->GIT
> > reconciliation
> > > > described (ugly hack scripting, sorting, and comparing). Others have
> > too
> > > > I've noticed. It is awful, yes, especially when issues like those
> found
> > > by
> > > > Viraj in yours and Huaxiangs RCs this week. The refguide is vague on
> > what
> > > > is involved; it needs more detail. The issue HBASE-22853 description
> on
> > > the
> > > > need for a tool to do the reconcile is a bit better.
> > > >
> > > >
> > > >
> > > > > I know NOW that as RM I cannot currently trust committers to get
> fix
> > > > > versions right or care about this.
> > > > >
> > > > > That's right... Commtters cannot be trusted to correctly maintain
> > issue
> > > > > metadata in JIRA.
> > > > >
> > > > >
> > > > Yes (says a key offender).
> > > >
> > > >
> > > >
> > > > > That is not a good situation for the project to be in. Up until now
> > it
> > > > has
> > > > > not been the responsibility of the RM to check each and every JIRA
> > > > status.
> > > > > It has been the collective responsibility of committers to care
> about
> > > the
> > > > > project's release tracking insofar as to correctly update fix
> > versions
> > > in
> > > > > JIRA. For releases containing relatively few changes, like 2.4.1,
> > with
> > > > ~50
> > > > > changes, I suppose it is possible for the RM to remove all 2.4.1
> fix
> > > > > versions, walk the commit history, and set back fix versions on
> JIRA
> > to
> > > > > actually correspond with what was truly committed. However, for
> minor
> > > > > releases, with hundreds of commits, this will not be possible.
> > > > >
> > > > > I think the root cause is GitHub and JIRA are two separate change
> > > > tracking
> > > > > systems with only a minimal amount of integration. It requires
> manual
> > > > > effort. More and more, new committers are familiar with GitHub and
> > PRs
> > > > and
> > > > > are not familiar with JIRA and the Apache way of using JIRA to
> build
> > > > change
> > > > > logs. We need to better educate new and existing committers on
> their
> > > > > responsibilities with regards to maintaining JIRA metadata
> correctly.
> > > > >
> > > > >
> > > > Agree.
> > > >
> > > > Other issues are that the release process has been evolving. In the
> old
> > > > days, JIRA was the source of truth; changelog was a JIRA report. The
> > > > CHANGES.md/RELEASENOTES.md have come to the fore perhaps making
> > > difference
> > > > between JIRA and GIT more pronounced.
> > > >
> > > > I like the suggestion made by you above (and Nick in an internal
> > > > discussion) that git be the source of truth. That the CHANGES.md NOT
> be
> > > > checked-in is also a good idea so it can be regenerated w/o need of a
> > > > change to the RC if JIRA is changed (I can work on this part if
> > wanted).
> > > >
> > > > S
> > > >
> > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > > - A23, Crosstalk
> > > > >
> > > >
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
