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 >> >>
