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 Thu, 06 Aug 2015 19:54:50 GMT
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

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>

> 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

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