I agree with Robbie, using staging repos is not really an answer for most users because you are using a version that may not be released and cancelled.
And I also agree with Robbie's earlier email that it's definitely a balancing act where it is annoying for users who are waiting for a release. I don't think there is really a right or wrong thing here, I don't think we need any "official" policy or change, mostly just like a courtesy type thing. The person doing the release ultimately gets to decide when to release, as long as the Apache guidelines are followed. In regards to the Mon/Tues thing...when I was doing releases I used to do them on Monday or Tuesday just for this exact reason as well :) On Thu, Mar 20, 2025 at 10:58 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > In some cases they could, that is true. Though for many users it > simply isnt permissible to use pre-release software (it is also > foundation policy that we not really suggest it), and it doesn't > really work for the large number of folks who will only use bits via > Maven Central (or often some curated internal proxy of it), or work > for folks that would need/want to release their own dependent bits > into Maven Central. > > On Tue, 18 Mar 2025 at 21:51, Matt Pavlovich <mattr...@apache.org> wrote: > > > > > > > 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 > > > > > > --------------------------------------------------------------------- > 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
