Le mer. 23 nov. 2022 à 14:38, Romain Manni-Bucau <[email protected]> a écrit :
> To answer the typical/atypical point: I guess maven is atypically typical > ;). > There are multiple projects like that, from Geronimo (even if it gets > better these days) to the OSGi projects (aries, smix, ...), even TomEE at > some point which was releasing its own ~350 modules + 5-6 forks (to get > quick fixes) + specs in a single repo. > Size matters there but is not a real delayer. What can be one - but it is > not clear reading this thread - are all the manual steps to do so I tend to > read this thread as "our automotion is not sufficient" but I'm not 100% > sure about the part which is my interpretation there. > > > @Enrico: The merge of projects is really the thread about monorepo vs > multirepo but it does not impact releases since you can release all > projects in a single staging so I still feel like we are chasing something > which is not an issue. > I kinda agree. In the last release for the parent POM, I released 3 projects together. Well, they ended up in 4 staging repos, but that's not even a problem. They don't even have to be built on the same computer, as someone else could add the first staged repository to your settings in an activate profile, and release another project that depends on the first one. For completeness, it should also be possible to release projects in a monorepo independently. Guillaume > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mer. 23 nov. 2022 à 14:32, Enrico Olivelli <[email protected]> a > écrit : > > > Tamas, > > > > Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák > > <[email protected]> ha scritto: > > > > > > Romain, > > > > > > Ok, I accept your response. > > > > > > Would be interested about feedback for the rest of 152 projects... :) > > > (actually not, is rhetorical really, just shows my point) > > > > > > As I still stand with my conclusion: "Maven might be quite atypical ASF > > > project by juggling with many more artifacts than others". > > > > > > Is Maven really a "typical" ASF project? How it relates to others by: > > > - number of reposes used (actually irrelevant, like svn vs git etc) > > > - more importantly, number of different (!) artifacts released per > > project? > > > > > > But I will stop here and finish my attempt to speed up releases, let it > > be > > > 72h. > > > (despite my gut telling it is wrong, at least for some of those among > the > > > 152 artifacts we juggle). > > > > > > I think that maybe we could try to merge some repositories. > > > > It is cool that Maven is so "modular", but I am not sure how much is > > it really "useful" > > to need to release so many pieces all together. > > > > We could keep the plugins as independent projects and most of the > > "shared" components > > collapsed into "maven core". > > > > Please note that I know that this has been discussed before, > > but....maybe sometimes it is better > > to restart a discussion, because the community changes, new ideas, new > > energy..... > > I don't have pointers to previous discussions... > > we can start a brand new thread if you want > > > > Enrico > > > > > > > > Thanks > > > T > > > > > > > > > > > > On Sat, Nov 19, 2022 at 6:05 PM Romain Manni-Bucau < > > [email protected]> > > > wrote: > > > > > > > Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <[email protected]> > a > > > > écrit : > > > > > > > > > Romain, > > > > > > > > > > Who talks here about "release without feedback"? > > > > > > > > > > > > > Well there are two kind of consequences to reduce release time > (making > > a > > > > minimum a maximum): > > > > > > > > * You drop part of the opportunity of feedback you had (by > > construction) > > > > * You enable a 5mn release since you can "easily" agree with a small > > set of > > > > people (literally 3) to release without asking anyone else > > > > > > > > These two looks bad from my small and far window. > > > > > > > > > > > > > > > > > > Or explain to me what you mean by "feedback" (as obviously you > don't > > > > count > > > > > the mandatory votes as "feedback"). > > > > > > > > > > > > > I do count it obviously but they are not the most important community > > wise. > > > > User feedbacks we saw in last releases (several non-binding ones) are > > key > > > > for the community and ASF is only about community at the end, nothing > > else. > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > https://www.mail-archive.com/[email protected]/msg126418.html > > > > https://www.mail-archive.com/[email protected]/msg125247.html > > > > https://www.mail-archive.com/[email protected]/msg120439.html > > > > https://www.mail-archive.com/[email protected]/msg120452.html > > > > ... > > > > > > > > We often get non-binding feedback, they are likely the most valuable > > and > > > > limiting the voting period too strictly sounds like dropping them > (they > > > > often happen +4 days after the opening of the vote. > > > > > > > > Side note: I'd like to emphasis once again that our delay induced by > > the > > > > voting period, even if we put 10 days, does not prevent to release > the > > > > whole maven ecosystem in 10 days so I would really love to refine the > > goal > > > > of changing this widely adopted practise at asf which put people at > the > > > > center of our production and not software, we are *not* about > software > > and > > > > Apache is not a place to put software before people IMHO. > > > > > > > > > > > > > > > > > > Thanks > > > > > T > > > > > > > > > > On Sat, Nov 19, 2022 at 2:55 PM Romain Manni-Bucau < > > > > [email protected]> > > > > > 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 < > [email protected]> > > 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 < > > [email protected]> > > > > > > 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 < > > [email protected] > > > > > > > > > > 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 < > > > > > > [email protected]> > > > > > > > > > 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 < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > [email protected]> > > > > > > > > > >> 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 < > > > > > > > > > [email protected]> > > > > > > > > > >> > 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 < > > > > > > > > [email protected]> > > > > > > > > > >> >> 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 < > > > > > > > > > >> [email protected]> > > > > > > > > > >> >>> 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: > > [email protected] > > > > > > > > > >> >> For additional commands, e-mail: > > [email protected] > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > >> To unsubscribe, e-mail: > [email protected] > > > > > > > > > >> For additional commands, e-mail: > > [email protected] > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ------------------------ > > > > > > > > Guillaume Nodet > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- ------------------------ Guillaume Nodet
