> 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 ...
Staging dist repos are public, and any anxious user is always able to grab the ‘pre-vote approved’ distribution and run with it. -Matt Pavlovich > 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 >> >> >> --------------------------------------------------------------------- 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
