tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siddharth Seth <ss...@apache.org>
Subject Re: [DISCUSS] Updating CHANGES.txt to track fixes/commits
Date Mon, 17 Aug 2015 18:28:43 GMT
+1 for updating CHANGES.txt on all versions. I think there'll still be some
confusion when a new version (0.9 for example) becomes active though.

We also need to update the Affects version and Fix version correctly.

On Thu, Aug 13, 2015 at 1:13 PM, Hitesh Shah <hitesh@apache.org> wrote:

> CHANGES.txt via git commit log would be quite useful. Incorrect commit
> messages cannot be fixed in git though so there may need to be some manual
> edits needed from time to time.
>
> In the meantime, should we just make a call to update each section in
> CHANGES.txt based on where a particular fix went in? i.e. if commit is
> going to branch-0.6, it should go into the sections for all unreleased
> versions for master, branch-0.7 and branch-0.6?
>
> Likewise to answer @Rajesh’s question, I think the Incompatible changes
> section should likely be treated as a subset of the All Changes section.
>
> Comments?
>
> — Hitesh
>
> On Aug 6, 2015, at 12:54 PM, Siddharth Seth <sseth@apache.org> wrote:
>
> > It does get fairly confusing on where a patch goes in with the multiple
> > releases which are in progress right now.
> > Putting an entry in the earliest version isn't very useful either - since
> > it's tough to figure out order of releases. Fixed in 0.5.4, but was it in
> > 0.6.2 would depend on whether 0.6.2 was released after.
> > Also we often end up back-porting patches at a later point, at which
> point
> > - there's multiple entries. However, they're not necessarily in all
> > sections.
> >
> > Using the commit log may be a good option. We'll have to be careful about
> > commit messages getting the jira number correct, and potentially have a
> > pattern for addendum patches and corrections, so that a script can easily
> > parse this.
> > Figuring out incompatible changes isn't easy from this - without querying
> > jira in parallel.
> >
> > The fix version in jira - if set to all versions where a patch goes in -
> > would work well also. There can be a single jira query to check for
> > versions, title, incompatible and potentially release notes - if
> something
> > specific needs to be called out for a fix.
> >
> > Setting affects version to all relevant versions helps as well - for
> users
> > to lookup whether a bug exists in a specific version, and when it was
> > fixed. This would likely need to be set to the min version within a
> release
> > line where it exists. The diff between that and the fix version should
> give
> > an idea of the range of releases where a bug exists.
> >
> > - Sid
> >
> > On Wed, Aug 5, 2015 at 4:01 PM, Rajesh Balamohan <rbalamohan@apache.org>
> > wrote:
> >
> >> Also, What should be followed for incompatible changes?
> >>    - Should we treat "INCOMPATBILE CHANGES" as a subset of "ALL
> CHANGES"?
> >> Currently, we add it only in "INCOMPATBILE CHANGES" section.
> >>    - Let us say we have "TEZ-1111" to be added in "INCOMPATBILE CHANGES"
> >> in 0.5.x branch.  Should we add it to "INCOMPATBILE CHANGES" in other
> >> branches as well (0.6, 0.7, master)?
> >>
> >> ~Rajesh.B
> >>
> >> On Thu, Aug 6, 2015 at 4:01 AM, Hitesh Shah <hitesh@apache.org> wrote:
> >>
> >>> Given that we have parallel branches going with their own different
> >>> timelines on when a maintenance/patch release is done, what does folks
> >>> think about the way we are currently tracking what changes went into
> each
> >>> and every particular branch/release?
> >>>
> >>> For example, a commit for say TEZ-11111 would have been committed to
> >>> master, branch 0.7, branch 0.6 and branch 0.5. Putting the entry for
> >>> TEZ-11111 into only one section in CHANGES.txt makes it confusing to
> >> figure
> >>> out which release the fix is available in.
> >>>
> >>> There are multiple options we could take:
> >>>    1) Create a CHANGES.txt/release notes from the git commit log for a
> >>> given branch.
> >>>    2) Add an entry into every release section in CHANGES.txt i.e. 4
> >>> entries for TEZ-11111 in master CHANGES.txt and corresponding one into
> >> the
> >>> relevant CHANGES.txt for each branch
> >>>
> >>> The above are not completely useful to the user unless JIRA is kept in
> >>> sync and up to date to match the branches in which the fix was
> committed.
> >>> Likewise for setting “Affect Versions” correctly.
> >>>
> >>> Any other options/ideas?
> >>>
> >>> thanks
> >>> — Hitesh
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message