Romain, Who talks here about "release without feedback"?
Or explain to me what you mean by "feedback" (as obviously you don't count the mandatory votes as "feedback"). And, to help me in better understanding, can you point me to any example of "feedback" (in your understanding) that happened on some Maven release? Thanks T On Sat, Nov 19, 2022 at 2:55 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Agree asf enables to release without feedback....question is not if it is > legal IMHO but is it what maven wants to do for thz mentionned reasons? > > For me it would clearly be negative - even at asf level - and the sign the > project does not belong to asf anymore (people first) so ultimately means > it should find another home. Luckily we are not there :). > > Le sam. 19 nov. 2022 à 12:50, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > Howdy, > > > > Let's all step back a little bit. Let's go back to my original > "postulate". > > > > - release vote SHOULD take 72h > > - release vote CANNOT be vetoed (only release mgr can cancel it) > > - release vote MUST reach PMC quorum > > > > Hence, in my reading, the above set of constraints does not conflicts > with > > this one below: > > > > => release vote is "done done" in a moment release has a PMC quorum > within > > 72h. > > > > And IMO this conclusion does not violate anything from those constraints > > above. As I see, none of the responses I got tackled my original > deduction > > (simplified above) :) > > > > === > > > > Or to rephrase: when a person announces the release (we usually first > > inform teammates about it on ML or Slack), person KNOWS he needs to > commit > > for upcoming 72+ hours, so he usually tries to "choose wisely" (with all > > the negative effects) -- what can be a good a reason to rather postpone > > (not now due this, not then due that...). My point is simply, that the > > process hinders us to "release often, release early", as the developer > will > > "choose wisely" WHEN he can commit his 72+ hours, hence the outcome is > what > > we have today: slow pace. > > > > Because there are so many things so few people checking can miss. > Release, > > and in a day 5k people may try it and find critical issues and within a > > couple days you may fix a handful of serious issues because you can get > so > > much more feedback. > > > > > > That's all > > T > > > > PS: +1 on "reduce the number of git reposes" but this is a digression. > > > > On Sat, Nov 19, 2022 at 1:08 AM Guillaume Nodet <gno...@apache.org> > wrote: > > > > > I also fail to see how the 72 hours period is the root cause of any > issue > > > you have. > > > > > > Here are a few possible changes that could improve the release > process: > > > * Releases can be done in parallel or in batches. > > > * If the fact that master branches are broken while releasing, we > could > > > certainly create branches and release from them. But we do usually > work > > > with PRs, so you can branch your PR from not the latest master and work > > > from that. > > > * We could also (but I think this has been discussed) reduce the > number > > > of git repos and always release things in batches, this could reduce > the > > > friction. > > > > > > > > > Le ven. 18 nov. 2022 à 22:48, Tamás Cservenák <ta...@cservenak.net> a > > > écrit : > > > > > > > damn me > > > > > > > > 16848 hours = 702 days = almost TWO YEARS of Maven releases just to > > build > > > > Maven itself. > > > > > > > > But, if you consider all apache artifacts (almost all, unsure is > there > > > > other in different groupId) > > > > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | > > grep > > > > "commons-" | wc -l > > > > 45 > > > > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | > > grep > > > > "org/apache" | wc -l > > > > 263 > > > > > > > > In total, 308 JARs = 22176 hours = 924 days = 2,5 years. > > > > > > > > T > > > > > > > > On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák < > ta...@cservenak.net> > > > > wrote: > > > > > > > > > David, > > > > > > > > > > I agree, and understand. > > > > > > > > > > But let me step back a bit: > > > > > ASF (as it all started around httpd) as a foundation hosts MANY > > > projects > > > > > wildly different projects, and those projects usually have a > handful > > > > (few, > > > > > when compared to Maven) of "deliverables" or "artifacts" being > > > released. > > > > Or > > > > > in other words (and am not trying to lessen their complexity or nor > > to > > > > > present Maven as something "special" here), most of ASF projects > have > > > > few, > > > > > very few deliverables (again, I am talking about the majority, > > correct > > > me > > > > > if I am wrong). Really, are there any statistics about: > > > > > - number of reposes used per ASF project > > > > > - number of different (!) artifact releases done per project? > > > > > > > > > > Maven on the other hand, while id DOES also have ONE "downloadable" > > > item > > > > > on download page (https://maven.apache.org/download.cgi) we all > know > > > > that > > > > > story does not end there: it is known to "download the whole > > internet", > > > > > just to run Maven "mvn clean verify" it will download zillion of > > > plugins > > > > > and their dependant artifacts (and I did not even mention 3rd > party, > > > non > > > > > ASF plugins). So, Maven, as a "deliverable" or "product" is > > definitely > > > > not > > > > > one ZIP file you see on the download page. ASF Maven project has > many > > > > > interconnected reposes/artifacts/releases. > > > > > > > > > > So, what I want to say: is it possible that ASF "way" works for > > > "typical" > > > > > projects, while Maven is more like "atypical"? > > > > > > > > > > Or, to make my example more concrete: > > > > > 1. I checked out master of maven from > http://github.com/apache/maven > > > > > 2. built it w/ pristine local repo > > > > > 3. and run some stats on it: > > > > > 4. > https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7 > > > > > > > > > > This simply means that for the end user, the "experience of ASF > > Maven" > > > is > > > > > literally 1 (that on download page) + 233 = 234 releases. And it is > > all > > > > > very interconnected. > > > > > > > > > > Btw, I just downloaded 16848 hours :) > > > > > > > > > > T > > > > > > > > > > On Fri, Nov 18, 2022 at 9:53 PM David Jencks < > > david.a.jen...@gmail.com > > > > > > > > > wrote: > > > > > > > > > >> You are free to do your own research. I’ve seen plenty of “but we > > > want > > > > >> the convenience of <72hr releases” discussions over the years, and > > the > > > > >> feedback I’ve seen is consistently that the reason for the > “should” > > > > rather > > > > >> than “must” is to account for emergency security patches etc, not > > > normal > > > > >> releases. > > > > >> > > > > >> David Jencks > > > > >> > > > > >> > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák < > > ta...@cservenak.net> > > > > >> wrote: > > > > >> > > > > > >> > As I wrote, we did have examples of changes + cascading, it is > > okay. > > > > >> > > > > > >> > But I don't agree with your statement about the board, as they > > > > >> themselves > > > > >> > state "should" not "must" for 72h. If it does not cut with them, > > > they > > > > >> > should modify the refd page(s). > > > > >> > > > > > >> > And it's not "we're impatient" either, part of the response for > > that > > > > is > > > > >> in > > > > >> > "hasty changes" canned response. > > > > >> > > > > > >> > Simply put: > > > > >> > - people see releases as a chore, as some "burden" that needs to > > be > > > > done > > > > >> > once in a while (see refd Slack messages in 1st mail), and when > it > > > > >> comes to > > > > >> > be done, "let's do it when it's worth". We have MANY user > > questions > > > on > > > > >> ML > > > > >> > of type "when is X released? As the issue [the user is > interested > > > in] > > > > is > > > > >> > fixed". And we have too many "dropped balls" in our court. IMHO, > > > > >> modifying > > > > >> > the process (to take less than 72+2h) is one step toward making > > > > release > > > > >> > less painful, less blocker. > > > > >> > > > > > >> > Fun fact: maven project consists of (not sure of exact count, > just > > > > >> > guessing) 150+ repositories (GH on ASF org gives 153 when I type > > in > > > > >> > "maven-" in the repo search bar). This is a LOT. If we'd, for > some > > > > >> reason, > > > > >> > start releasing all of those in 72h windows, it would be 10800 > > > hours, > > > > or > > > > >> > 450 days, more than a year. > > > > >> > > > > > >> > > > > > >> > On Fri, Nov 18, 2022 at 8:34 PM David Jencks < > > > > david.a.jen...@gmail.com> > > > > >> > wrote: > > > > >> > > > > > >> >> Which developers have to pause what activities? > > > > >> >> > > > > >> >> From previous discussions elsewhere, I’m strongly of the > opinion > > > that > > > > >> < 72 > > > > >> >> hr release votes are intended only for emergency security fixes > > and > > > > >> similar > > > > >> >> events, and that “we’re impatient” isn’t going to cut it with > the > > > > >> board. > > > > >> >> It certainly wouldn’t with me. > > > > >> >> > > > > >> >> How many of these annoyances would be eliminated by an easy way > > to > > > > >> release > > > > >> >> and vote on a set of changed artifacts + the cascading > > dependencies > > > > >> all at > > > > >> >> once? > > > > >> >> > > > > >> >> thanks > > > > >> >> David Jencks > > > > >> >> > > > > >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák < > > > ta...@cservenak.net> > > > > >> >> wrote: > > > > >> >>> > > > > >> >>> David, > > > > >> >>> > > > > >> >>> I just meant that there is a "forced pause" of 72h. > > > > >> >>> > > > > >> >>> T > > > > >> >>> > > > > >> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks < > > > > >> david.a.jen...@gmail.com> > > > > >> >>> wrote: > > > > >> >>> > > > > >> >>>> +1 from the sidelines. > > > > >> >>>> > > > > >> >>>> I don’t understand > > > > >> >>>>>>> * current process causes (forced) context switching, and > can > > > > >> likely > > > > >> >>>> lead to > > > > >> >>>> human mistakes: when the release vote is announced, developer > > is > > > > >> FORCED > > > > >> >> to > > > > >> >>>> stop for 72h and possibly switch. This is just a productivity > > > > killer. > > > > >> >>>> <<< > > > > >> >>>> Who is forced to do anything and for what reason? > > > > >> >>>> > > > > >> >>>> > > > > >> >> > > > > >> >> > > > > >> >> > > > --------------------------------------------------------------------- > > > > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> >> > > > > >> >> > > > > >> > > > > >> > > > > >> > > --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > >> > > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > > > >
