Yep, I like a good Monday/Tuesday vote opening when things suit, both for that and also getting it all over within the same week :)
On Thu, 20 Mar 2025 at 16:37, Christopher Shannon <christopher.l.shan...@gmail.com> wrote: > > 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 > > --------------------------------------------------------------------- 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
