tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hitesh Shah <hit...@apache.org>
Subject Re: [DISCUSS] Updating CHANGES.txt to track fixes/commits
Date Thu, 13 Aug 2015 20:13:34 GMT
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
View raw message