That's fair, and you are right it's not a big deal, though I also think proceeding is fair too most of the time, if usual voters have already voted.
I'm definitely not just looking at it from the release managers perspective, though that's certainly a good part of it. However it's also annoying though for the users to have waited weeks or often months for fixes made for the issues they reported, and then see a potential fix release sitting just out of their reach that could maybe have been released days earlier. Especially during a period later in the vote when fewer tend to vote, and it should be less likely after earlier testing that such folks find anything obvious that also affects the users waiting. If anything is found, that maybe still doesn't affect various users waiting for specific fixes, they then have to wait yet longer again for a respin, instead of having the earlier spin that perhaps was fine for their needs. Then there will always be something else old or new that isn't found until after release, no matter how long a vote is left open. Cue need for another release anyway. Which folks become less inclined to do the more painful doing them is, instead trying to fit more and more into each release instead of just proceeding, because 'the next one is too far away'. Which then tends to lead to bigger collective change more likely to cause issues to begin with. Plus yet more waiting for users again for the next release with fixes they want/need. Basically I just err on the side of releasing more often, testing before starting the release, and doing very few respins wherever possible. Especially when it's the same amount of work for the releaser either way as another release is. If it's not an obvious blocker, and several folk didn't find it in 3+ days after it was already decided things are ready to release, then most of the time I'll tend to think rather than respin that if something found its more of a reason to do another smaller release real soon, rather than waiting weeks or more typically months later as most of them tend to be done. Getting the fixes that are ready to the users wanting/needing them. Alternative version: just try to open votes on Mondays or Tuesdays and this won't come up either way ;) Robbie On Tue, 18 Mar 2025, 15:06 Christopher Shannon, < christopher.l.shan...@gmail.com> wrote: > Robbie, > > From your response: "is just slowing things down unnecessarily." > > What exactly is the harm in slowing things down though? Unless there's > an urgent fix it's not a big deal if it waits another day. > > I think you are only looking at it from the side of the release > manager and are discounting the fact that it's annoying to end users > to push out a release, find something, and then immediately create a > new release to upgrade again a few days later when it could have been > avoided by simply giving everyone a chance that wants to review a > release sufficient time to review it. > > I don't think that requesting 3 business days for sufficient review > for people in the community who may want a chance to review something > is a big deal. > > Chris > > On Tue, Mar 18, 2025 at 8:59 AM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > > Clebert is being nice here and not throwing me under the bus. I was > > the one who suggested to him yesterday, before going out for a couple > > days myself, that if most of the usual folks that vote on an Artemis > > vote had done so then it was fine to close it later on yesterday given > > that the suggestion is only 72hrs, not business hours, and by that > > point it would have been open nearly 5 days, and even over 2 business > > days also in my case. I have personally done this many times over the > > decades with no complaints so far. > > > > We dont do enough releases, so for me the waiting further when the > > suggested time has more than passed, if the usual voters have voted, > > is just slowing things down unnecessarily. Worst case, someone who by > > that point is typically unlikely to be voting, does actually vote and > > finds an issue that warrants a respin. It's then the same amount of > > effort and time for the release manager to respin as doing a whole > > other release takes, and for me its typically going to be better that > > we just aim to do those more releases as a matter of course. So as I > > would have done so myself had I been doing the release, I suggested > > that he could just close the vote rather than let it sit a couple days > > more. > > > > Robbie > > > > On Tue, 18 Mar 2025 at 04:10, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > > > > I usually wait rhe business days. > > > > > > This time I thought it was fine given it was almost over, and I wanted > to > > > finish it before I was gone for a day tomorrow. > > > > > > > > > I will make sure I wait the businesss hours next time. > > > > > > Thanks Chris. > > > > > > Clebert Suconic > > > > > > > > > On Mon, Mar 17, 2025 at 7:32 PM Christopher Shannon < > > > christopher.l.shan...@gmail.com> wrote: > > > > > > > Giving the date is fine, but I would still phrase it as something > like > > > > "Voting will continue until at least X date" just so everyone knows > it > > > > won't close before then, vs a hard deadline as it can still go longer > > > > if something comes up. (outstanding issue, release manager is busy, > > > > etc). > > > > > > > > The end time in UTC could be included as well but I'm not too worried > > > > either way about it being exact as the spirit of the proposal is to > > > > prevent stuff like starting a vote on friday afternoon and closing it > > > > on monday afternoon when the majority of time people are probably not > > > > even paying attention for the entire weekend so it is really just a > 24 > > > > hour vote. > > > > > > > > > > > > On Mon, Mar 17, 2025 at 6:52 PM Ken Liao <kenlia...@gmail.com> > wrote: > > > > > > > > > > Agree. And on a side note, to make it easier for the community, > the email > > > > > should include a date for the "deadline" of voting, instead of > saying "it > > > > > will be open for at least 72 hours". WDYT? > > > > > > > > > > Thanks, > > > > > Ken > > > > > > > > > > On Mon, Mar 17, 2025 at 2:59 PM Jamie G. <jamie.goody...@gmail.com > > > > > > wrote: > > > > > > > > > > > I tend to agree here. > > > > > > > > > > > > Full builds with all unit tests on AMQ can take 4 to 5 hours , > if one > > > > is > > > > > > testing many jvm vendors & platforms it can take a few days just > to get > > > > > > coverage. Weekend releases can make it challenging to complete > them > > > > all. > > > > > > > > > > > > On Mon, Mar 17, 2025 at 19:23 Christopher Shannon < > > > > > > christopher.l.shan...@gmail.com> wrote: > > > > > > > > > > > > > The Apache guideline for voting is that votes should run for > at least > > > > > > > 72 hours [1] but nothing prevents a vote from going longer. It > also > > > > > > > doesn't specify anything about votes on weekends or not but > just > > > > > > > generally 72 hours. > > > > > > > > > > > > > > Because there isn't a maximum time for votes, (I've seen votes > go > > > > > > > weeks on some projects), I think it would be a good idea if we > > > > adopted > > > > > > > a policy where we don't count weekend days or major holidays > etc to > > > > > > > allow for everyone 3 business days to be able to have a chance > to > > > > > > > review a release and vote. > > > > > > > > > > > > > > This doesn't have to be something super strict, we don't need > to go > > > > > > > crazy counting holidays as they can vary by country and > region, but > > > > > > > major holidays like New Years make sense. Urgent releases can > also > > > > > > > always go out quicker if needed, I just think it would be a > nice goal > > > > > > > for most releases though. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > [1] https://www.apache.org/foundation/voting.html > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > > > > For further information, visit: > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > For further information, visit: https://activemq.apache.org/contact > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > For additional commands, e-mail: dev-h...@activemq.apache.org > > For further information, visit: https://activemq.apache.org/contact > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
