Terrific - I will lean on you both for support. The plan of action is to try to tag a release in Github on April 9th. Then there should be validation of that, then a vote, then a formal release. Release should be within a few days to a week after April 9th if all goes to plan.
Tickets that are open but not being worked on should move to the theoretical release 1.10.0. I'll run a batch update on the jira tickets. I'll also close and archive tickets that are NOT being worked on recently (since release 1.9.0 date of early Jan). It makes no sense to have hundreds of open tickets that no one is working on, and difficult to know if the tickets are valid unless they've been created recently. So, grab a ticket if you want and keep it alive. You have until April 8th. Grab a few, grab many. Open and in process tickets - please let me know a week in advance. We can accommodate a shift in dates... just need to know what's going on. I would ask that you try to keep things especially stable on April 8-10th, but we can move this a week later or so. Again, I'm trying to set the date - so speak up. Also, I am assuming that all PRs are properly following the checklist which includes test coverage, coding standards, and reference to a jira ticket. This last one is essential for traceability of the code changes, and I'll be looking for adherence to this policy. i.e. you can expect a reaction if you haven't managed this basic thing, so please check. For any of this, I'm open to being overruled by a vocal group of contributors, so let me know if this seems wrong in any way. I'm not dictating, just trying to move this forward, and I take silence as acquiescence. Thanks, On Fri, Mar 15, 2024 at 12:59 PM Inzemamul Haq <inzemamha...@gmail.com> wrote: > I can too assist... > > On Sat, 16 Mar, 2024, 1:25 am Aleksandar Vidakovic, < > chee...@monkeysintown.com> wrote: > >> ... can assist >> >> On Fri, Mar 15, 2024 at 4:09 PM James Dailey <jdai...@apache.org> wrote: >> >>> Devs >>> >>> I’d like to propose that we get out a release 1.9.1 with recent changes >>> by April 9th. I’m willing to serve as release manager although I’ll need >>> support. >>> >>> Let’s make sure we have stable code for a snapshot on April 3rd. If >>> someone has a better date , please let me know. >>> >>> The strategy should be quarterly releases so that we don’t end up with >>> such massive reviews. >>> >>> At all times the dev branch should be in a stable condition and passing >>> all tests. When it is not, then someone should be working on it actively >>> to correct the situation. >>> >>> >>> >>> Sent from Gmail Mobile >>> >>
