From a JIRA perspective, I seem to recall this was used previously but can’t remember if this was still in use this time around but...
Would it be worth (1) raising individual “release tickets” in JIRA for each planned release, (2) link all tickets associated with it, - if ticket during development doesn’t meet the acceptance criteria then can be deferred to next, scheduled in future release, or send it back to the backlog - there maybe some overlap with github PRs but this is more for planning and monitoring and less for actual merge activities. Assume PRs would be called out in the tickets. Although could have a “merge sub-task” to provide another means in JIRA to identify PRs in this context - there maybe some overlap with milestone and labels here as well some alternative can have a “link” to a filter for all applicable milestone / labels items for the release (3) include a “release checklist” with the defined process activities included. - This can formalize the activities needed for a given release (raise git branches, merge tickets to given branch, remove temp branches, etc.) - Can have different ones for LTR (with NETCat) vs otherwise (4) Maybe some form of JIRA admin or Change Control Board (CCB) group can be established - manage JIRA activities - help in release planning including linking items to future release - update status where applicable - combined, reject, close out OBE items, etc. - manage milestones, labels, grouping fields, etc. - can utilize JIRA dashboards, kanban types for status monitoring as well. JIRA is powerful when used properly (5) Maybe a side effect of need for additional planning but have a Triage Group to review new or older tickets (maybe group in some way like platform, feature, etc.) and help identify what may be good for future release, priority, maybe work estimates, tickets have all necessary details, etc. Regarding branching process, is this documented anywhere outside of mailing list? If so where? If not should it be? Regarding LTR item, can these just always be the x.0? Regarding API review, what's meant by this? Eric Bresie [email protected] (mailto:[email protected]) > On December 8, 2020 at 5:04:24 AM CST, Neil C Smith <[email protected] > (mailto:[email protected])> wrote: > On Tue, 8 Dec 2020 at 05:45, Laszlo Kishalmi <[email protected] > (mailto:[email protected])> wrote: > > As version 12.2 got out, > > Congratulations! And thanks. > > > - Well, the release is out, we almost made that in our projected > > timeframe. (One of our fastest releases) > > I make it third out of the five update releases .. more on speed below .. > > > - It seems managing the master, delivery and release branches worked > > well without headache or too much overhead. I'd thank the contributors > > to play well with the rules and supporting my requests. It is about 40+ > > PR got merged into master while we were still working on the release > > stabilization. > > Yes, seems to have been a really good solution! Any issues on your > end in merging delivery branch? Any PRs actually held up from merging > to master? > > Temporary delivery branch just an artefact of our current build > process, or actually useful to keep in the process? > > > increased activity around the PR processing. > > What about JIRA processing this time? It's the aspect I feel got > worse and harder to manage over release cycles I've RM'd. > > > - Well, the release speed is still not there where we imagined. > > But can it be improved?! We seem to have stabilised at a similar > release speed. It's reliant on adequate testing and fixes being > proposed for criticals / blockers. Can that really be sped up in > practice? Because we haven't so far. Still, most delays have been > macOS or nb-javac related ... > > What about installers? Some delays caused by inadequate testing there > - is there any way to automate the installer process with code > signing? And deliver for betas / rcs? And then we could do with > trying to get back to binary votes being roughly parallel with release > vote? > > > - Early feedback! ... So instead of voting 0 (saying meh), reason! > > +1 to that. And if not sure if something should be a blocker, > discussion thread off the vote thread (and ideally before it)? > > > - We need to add an API change review round even before branching for > > the release. > > +1. Also not helped in that I'd not followed up properly on post-12.1 > discussion to get that in place for freeze. But agree, before freeze > would be more helpful. > > This one seemed "worse" too. I feel there were things in there that > should have been breaking some tests?! And picking up at PR time, not > release, would have been better? > > > - We still do not have a definitive answer, what do we want from an LTS > > release (or do we want it all). > > Drop it! ;-) > > > - We still have not decided how the 12.3 and 13.0 would relate to each > > other. (as the other side of the LTS topic) > > Or if we keep, your previous suggestion of LTS being built off of x.3? > As long as we find a way to ensure fixes for LTS hit master. And > start NetCAT on 12.3 release date? > > I also dislike we voted on a versioning scheme before we even decided > what our release strategy was, and it keeps confusing people - so > maybe after 12.3 (x-apple-data-detectors://6), the outward facing branding > goes something more like > 13.0 LTS, 14.0, 14.1, 14.2, 14.3 LTS? Or just 13 LTS, 14, 15, 16, 17 > LTS? > > And speaking of confusions, we need to think about how the Check for > Updates UI relates to informing users of both LTS and non-LTS > availability. > > > - Our love and hate relationship to nb-javac needs to be resolved. We > > suggest people to go without it, then we suggest people to try that. > > Also with the current release we see an increased amount of NPE-s and > > parsing errors. If we would like to have it around, maybe we need to > > able to patch it, even if outside Apache. But at the moment even me the > > latest RM do not know what to think about that. > > Drop it! ;-) > > Or if we keep it, then absolutely in favour of Matthias' blocker for > next release. Move to delivering nb-javac via Maven and plugin > portal. > > Previous releases have been delayed by nb-javac not landing before > freeze, and not being adequately tested. Even landing at freeze feels > too late. And the third-party UC is another cause of problems, and we > shouldn't need an IDE release just to deliver an nb-javac update? > > To deliver nb-javac via plugin portal we would also need a per release > catalog - not just 11, 12, etc. And possibly one explicitly for dev. > If nb-javac stays then is a snapshot version in dev (for master) that > tracks upstream javac commits feasible? That process feels like it > could be partly automated, but not here obviously! > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > (mailto:[email protected]) > For additional commands, e-mail: [email protected] > (mailto:[email protected]) > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > >
