-1 This is fundamentally a bad idea and is the wrong way to solve the problem you mention.
If you want people to vote, then work on developing a large enough community of committers or PMC members that are interested in seeing your project evolve. If you are in constant contact with your community, they will vote. Don't extend the minimum time that the vote has to be open. That is a terrible idea. Our project as well as many projects need speed and responsiveness for new features that their communities need and for timely security fixes. Regards, Lee. On Fri, May 12, 2023 at 11:05 AM Jeremy Landis <jeremylan...@hotmail.com> wrote: > From a real-life perspective, this stuff should remain fast. People will > only vote on what they are comfortable with as most others have stated. > But the real-life part of it at least as I can speak, it will take months > to get some of the updates that have been pushed into widespread adoption. > In our usage, we rely heavily on the maven wrapper. It drives through a > seeding process to pull request it around to repos in say 2k range for us > (continuing to upscale). This goes through 'develop' branches, that then > takes a while to even propagate up from there to release. Some teams will > run hot and fast. Others will push back for years. We physically have to > tell people we will intentionally break their builds (ie threats to delete > jdk 8 for example), raise threats for a while, back off, give another date, > etc. So I don't think making any of this move slower would be helpful. > For those that are fast to uptake the results (devops leads), they are the > ones you really want to focus on. They give the wider tests to prove stuff > actually works but typically won't even touch until its out. If people are > just forced to vote to vote, you won't get any good results and if people > are forced to have to figure out how to test everything, you won't get any > engagement no matter how long it takes. There are still others such as > myself that while I may or may not agree with some changes (thinking maven > 3.9.2 warning levels here), I go with it and see how it looks after the > fact because it does take time to setup and I'd rather spend that time > scaling it then one off testing it. Any fallout from there just goes back > to rework efforts IMO. > > Also, IMO, for years maven never ran like this. It's been bumpy here. > That isn't' a problem. Fail fast, its good. The overall improvements have > been grand. So keep it fast 😉 Too many components to go slow, this isn't > the spring framework where monthly cadence works. Save that for maven > itself 😉 > > -----Original Message----- > From: Tamás Cservenák <csta...@apache.org> > Sent: Friday, May 12, 2023 5:32 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: [VOTE] Change to the voting process > > Howdy, > > I'd like to propose a change to the ASF Maven voting process (in line with > ASF guidelines): > CHANGE the current "vote open for at least 72h" window to "vote open for > at least 30 days, or more". > > Reasoning: > According to paperwork (ASF stats) we have more than 90 voters available > (PMCs + committers). > Still, multiple release votes recently were able to pass the "doorstep" > only by "hunting down" voters and pulling their sleeves (apologies and > thanks to them). This makes it clear that ONLY 72h is totally > anti-community and disrespectful. Nobody's sleeve should be pulled. That's > disrespectful for sleeves as well (except if you wear a T-shirt). We must > serve our project community in the best manner, and let our voters be able > to cast well thought votes in a timely manner, hence increasing the > irrationally short window of opportunity for casting votes IS A MUST. And > leave the sleeves alone. > > Sorry, but the vote is open for at least 72 hours ONLY. > > [ ] +1 > [ ] +0 > [ ] -1 >
