Would a main JIRA Issue “MicroProfile Support” and sub-tasks with everything related under the parent task work?
> On 9 Aug 2018, at 17:36, David Blevins <david.blev...@gmail.com> wrote: > >> On Aug 9, 2018, at 4:28 AM, Gurkan Erdogdu <cgerdo...@gmail.com> wrote: >> >> Can you also please open JIRA issue (main issue and we >> can create sub-tasks under it) to track MP related work? > > Agreed. And for those reading, our release notes are generated from JIRA (or > at least they used to be). So we should file JIRAs with the subject written > from the perspective of someone reading the release notes. That's clean and > simple subjects. > > It would be very common for me to file a handful of JIRAs even though one > would do it from a tracking perspective. It was also common for me to go > back through commits at release time and spend 2 days filing them because the > release notes were too thin. > > Here's the template: > > - > https://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/resources/release-notes.vm > > As far as JIRAs, I'd probably aim for release notes looking like this: > > > Upgrades: > > - ... > > New Features: > > - MicroProfile 1.3 Support > - MicroProfile JWT 1.0 > - MicroProfile FaultTolerance 1.0 > [list them all cleanly] > > That'd mean you'd have to file a JIRA of type "New Feature" with the clean > subject "MicroProfile JWT 1.0." If you used talkative text like, "Adding > some MP-JWT Stuff", you'll get strange looking release notes. > > > Upgrades: > > - ... > > New Features: > > - Implement MP in TomEE > [list them all cleanly] > > Tasks & Subtasks: > > - Update the pom.xml with MP-JWT > - Fix integration issue with JWT Filter > [list them all cleanly] > > This doesn't clearly communicate our status to the world and just puts more > work on the release manager who would have to ensure the release notes make > sense, so it's to not just file JIRAs, but think of the future release note > readers when we file them. > > > -David > >
