If I’m ready to release in a Thursday if I wait till Monday to release I might have found things broken and have to wait until next Thursday to be ready again.
Kind of half joking. But not totally a lie :) I will try to do it on a Monday or Tuesday next time and if I need a Thursday I will just wait more time as needed :) Clebert Suconic On Thu, Mar 20, 2025 at 2:01 PM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > 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 > > >
