On Mon, Sep 14, 2015 at 1:09 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > I put some time into this a little while back, doing releasedocmaker > backports from the Yetus branch. IIRC from Allen, we still need to get lint > mode working before it's good to go. Probably a good bit of JIRA cleanup > will be required to get a clean lint run.
The lint tests will evolve as we discover new inconsistencies. Does it need to be a prerequisite? We've had this discussion before. Using JIRA is at least as accurate as CHANGES.txt, we should just use Allen's script (now part of Yetus?) to generate the release notes, and stop rehashing this. If someone wants to cross-reference other sources to improve accuracy, that would be fine followup. -C > On Sun, Sep 13, 2015 at 4:38 AM, Steve Loughran <ste...@hortonworks.com> > wrote: > >> >> > On 12 Sep 2015, at 20:26, Allen Wittenauer <a...@altiscale.com> wrote: >> > >> > >> > On Sep 12, 2015, at 12:25 PM, Allen Wittenauer <a...@altiscale.com> wrote: >> > >> >> >> >> On Sep 12, 2015, at 11:03 AM, Steve Loughran <ste...@hortonworks.com> >> wrote: >> >> >> >>> >> >>> 2. go to JIRA-generated change logs. Though for that to be reliable, >> those fix-version fields have to be 100% accurate too. >> > >> > >> > P.S., >> https://github.com/aw-altiscale/eco-release-metadata/blob/master/HADOOP/README.md >> > >> > >> >> nice. I'd prefer this, as long as we keep up on the versioning. In >> particular, any cherry picking back to a point release, 2.7.2 etc will need >> the entry being re-edited >> >> in the meantime, I celebrate Haohui's volunteering -though need to warn it >> was the thought of making the 2.7.x and 2.6.x changes consistent which >> worried me there -you end up having to re-arrange entries across four files >> >> -steve >>
