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
