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
