[DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

Howdy,

My pet peeve these days is our release process. IMHO, we should be able to
release ("move") much faster than today.

My proposal would be:
* vote is "done done" the moment quorum is reached
* change the wording in the vote email from "Vote open for at least 72
hours." to "Vote open for a maximum of 72 hours.".

Reasoning:
* vote cannot be vetoed by definition (only release mgr can cancel it).
* change would not conflict with ASF defined rules, the 72h is not
compulsory (document states "should" not "must").
* the release process is already wearisome, complex, and is easy to miss
(over-represented) manual steps. For example yesterday for some reason it
took almost 2 hours to sync release artifacts to Maven Central, during
which you are in a "busy loop" (the announcement and site depends on sync).
Leaving it "for tomorrow" may cause users to learn about a new release thru
Artifact Listener or whatever other service, causing confusion. Ideally,
site and announcement mail should be tied to sync, and that does lead to
"busy loop".
* 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.
* which part do you like: as a developer sitting on needles while being
blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
* we already agreed on one minor process improvement: we have quite long
"chains" of dependencies, so a bugfix that can span on long trails could
take weeks to be done serially, even if the bugfix itself is trivial. Hence
we did accept that we can do "batch votes" (release together) and can do
one vote for this case.
* on positive site this could lead to mindset change of bugfix releases, as
today, few wants to go thru painful release process for "single simple
change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
wrong: we all should release early and often. And be happy with it, not
feel it like chores :)

Finally some "canned responses":
* "time is needed for all interested parties to review": If someone cannot
get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
does not matter, as release is to happen anyway (unless release mgr cancels
it). One not getting to it, will be notified via mails anyway (vote,
result, announce). We can already observe that there are "areas of
interests", but also there is the customary habit of "review invitation"
which is a good thing IMHO, as usually one invites a colleague with whom
the topic was or is under discussion already, so both of them are
"contextualized". Those initiated developers will most probably join in
voting for release as well, as either they depend on the fix or they know
what the problem was.
* "this will lead to more bugs" or "we are too hasty making changes": no,
it will not and we are not. As in essence, this change would allow us, in
case of need, to release even multiple times per day (so release the
project carrying a bug in the morning, then have a patch release for it in
the afternoon). Really, as bugs are inevitable, they happen with or without
72 hours, still the current process just causes problems IMHO. As the new
release is sitting on Central, without immediate remediation possibility.
Or to put it another way, having this option open does not mean we will
make all releases like it, and we will not start competing by releasing all
the plugins several times a day :) You can see there are "hot spots'' (if
you look at maveniverse as whole, sometimes plugins, sometimes shared
stuff, sometime maven, etc), especially with closing releases of Maven, but
those hotspots come and go, move, and just like today, some components will
not be released for quite some time, as the hotspots move from here to
there.

Applying this process change, if accepted, would not alter anything
regarding "commit policy" of code changes (PRs, JIRA attached patches, etc).

Refs:
https://www.apache.org/foundation/voting.html
https://www.apache.org/legal/release-policy.html

Please comment, add your opinion. Ideally, if discussion closes with
"positive outcome", I would like to propose a vote for these changes.

Thanks
T

Re: [DISCUSS] Speed up release process?

[Stefan Bodewig <bo...@apache.org>]

Hi

I'm not a member of the developer community here, just a watcher
offering a comment from the peanut gallery.

On 2022-11-18, Tamás Cservenák wrote:

> * vote cannot be vetoed by definition (only release mgr can cancel it).

while this is true there also is a rule that says "and more positive
binding votes than negative binding votes MUST be cast"[1]. If you stop
after receiving three +1s technically it is still possible four people
would be voting with -1 in the remaining window of time.

This is one reason why there is defined window of time for the vote - so
you know when to tally the votes.

Stefan

[1] https://www.apache.org/legal/release-policy.html#release-approval

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

Lets try one question/issue per email…

Which developers have to pause what activities.

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 <da...@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 <da...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

If all 153 projects released at once with 72 hour windows, that would be 72 hours. That’s just as plausible as sequential 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 <da...@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 <da...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

Evidently you know something I don’t, and I hope you’ll explain it to me.

For the 3rd time, 
>>>>> Which developers have to pause what activities?

—

Right now there are usually release votes in parallel. As I pointed out, all 308 could be in parallel.  What relevance does your calculation have to anything?

This discussion looks to me like the others I’ve seen about shortening release votes: someone is basically complaining that the apache process is inconvenient for a particular subset of developers on a particular project, without examining what the actual roadblocks to effective development are or what other solutions might be possible.

In particular, I’d like to see an analysis of what would happen if a “release” was for a particular project plus all downstream changes needed to use it, whether as a single vote or as concurrent votes.

Thanks
David Jencks

> On Nov 18, 2022, at 1:48 PM, Tamás Cservenák <ta...@cservenak.net> wrote:
> 
> 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 <da...@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 <da...@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.jencks@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Guillaume Nodet <gn...@apache.org>]

Le mer. 23 nov. 2022 à 14:38, Romain Manni-Bucau <rm...@gmail.com> 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 <eo...@gmail.com> a
> écrit :
>
> > Tamas,
> >
> > Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák
> > <ta...@cservenak.net> 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 <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <ta...@cservenak.net>
> 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/dev@maven.apache.org/msg126418.html
> > > > https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
> > > > https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
> > > > https://www.mail-archive.com/dev@maven.apache.org/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 <
> > > > rmannibucau@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 <
> tamas@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 <
> > gnodet@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 <
> > tamas@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 <
> > > > > > tamas@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.jencks@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 <
> > > > > > > tamas@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.jencks@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 <
> > > > > > > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > > > > > >> >> For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > >> >>
> > > > > > > > > >> >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > >> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > > > > > > > > >> For additional commands, e-mail:
> > dev-help@maven.apache.org
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ------------------------
> > > > > > > > Guillaume Nodet
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>


-- 
------------------------
Guillaume Nodet

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

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.

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 <eo...@gmail.com> a
écrit :

> Tamas,
>
> Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák
> <ta...@cservenak.net> 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 <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <ta...@cservenak.net> 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/dev@maven.apache.org/msg126418.html
> > > https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
> > > https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
> > > https://www.mail-archive.com/dev@maven.apache.org/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 <
> > > rmannibucau@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 <
> gnodet@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 <
> tamas@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 <
> > > > > tamas@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.jencks@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 <
> > > > > > tamas@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.jencks@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 <
> > > > > > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > > > > >> >> For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > >> >>
> > > > > > > > >> >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > >
> ---------------------------------------------------------------------
> > > > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > >> For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Speed up release process?

[Enrico Olivelli <eo...@gmail.com>]

Tamas,

Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák
<ta...@cservenak.net> 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 <rm...@gmail.com>
> wrote:
>
> > Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <ta...@cservenak.net> 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/dev@maven.apache.org/msg126418.html
> > https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
> > https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
> > https://www.mail-archive.com/dev@maven.apache.org/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 <
> > rmannibucau@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 <gn...@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 <tamas@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 <
> > > > tamas@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.jencks@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 <
> > > > > tamas@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.jencks@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 <
> > > > > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >> >>
> > > > > > > >> >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > ---------------------------------------------------------------------
> > > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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

Thanks
T



On Sat, Nov 19, 2022 at 6:05 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <ta...@cservenak.net> 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/dev@maven.apache.org/msg126418.html
> https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
> https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
> https://www.mail-archive.com/dev@maven.apache.org/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 <
> rmannibucau@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 <gn...@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 <tamas@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 <
> > > tamas@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.jencks@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 <
> > > > tamas@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.jencks@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 <
> > > > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák <ta...@cservenak.net> 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/dev@maven.apache.org/msg126418.html
https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
https://www.mail-archive.com/dev@maven.apache.org/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 <rm...@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 <gn...@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 <
> > tamas@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.jencks@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 <
> > > tamas@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.jencks@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 <
> > > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >> >>
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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 <rm...@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 <gn...@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 <
> tamas@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.jencks@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 <
> > tamas@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.jencks@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 <
> > > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >> >>
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>
> > > > >>
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

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 <gn...@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.jencks@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 <
> tamas@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.jencks@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 <
> > tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>
> > > >> >>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >>
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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 <gn...@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.jencks@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.jencks@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 <
> tamas@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.jencks@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-unsubscribe@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>

Re: [DISCUSS] Speed up release process?

[Guillaume Nodet <gn...@apache.org>]

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 <da...@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.jencks@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.jencks@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-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>


-- 
------------------------
Guillaume Nodet

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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 <da...@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 <da...@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.jencks@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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 <da...@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 <da...@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.jencks@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

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 <da...@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 <da...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Enrico Olivelli <eo...@gmail.com>]

Sorry for top posting.
At least 72 hours is needed because we are all volunteers and it takes time
to validate a release.

Also I see that in a few projects (maybe not Maven) the VOTE starts during
the weekend and this is a problem because sometimes in the weekend you are
not at the keyboard and we miss the opportunity to have VOTEs from people
that could cast their vote during regular work days


Just my two cents

Enrico

Il Sab 19 Nov 2022, 10:12 Romain Manni-Bucau <rm...@gmail.com> ha
scritto:

> Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > So Maven cares for us, hence the 72h? I don't get how one is deduced from
> > another.
> >
> > And as they are (and usually are) dependent on each other from
> perspective
> > of single release mgr local repo we could release all 150+, at the cost
> of
> > breaking all the 150+ CI jobs and all source builds in the wild for at
> > least 72+2h (actually more, as _during_ release preparation they would
> > start breaking, not only during vote). So, thank you, but no, thank you
> :D
> >
> > Strange, that you say "no user complained of waiting". From where did you
> > source this information, or from where can you support this claim?
> >
> > Just as an example, complaints on Slack do happen, quite often and
> > regularly.
> >
>
> Not of the 72h, just of the months they need to wait, please dont mix it.
> Also which % compared to the user base?
>
> Also note that all your computations sounds false since the release can be
> ran by multiple clients at once in the same staging, dont play the extreme
> game, in practise a single repo works for 5-6 projects - way bigger than 10
> maven projects ;) - in a very controlled time. If you need 30 maven
> projects it will work without any issue....but once again it is likely not
> an issue maven hits, the process being heavy - didnt say only for bads - is
> way more hurting and slowing us down (even make features abandonned) than 3
> days.
>
>
>
> > T
> >
> >
> >
> > On Fri, Nov 18, 2022 at 9:19 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Side note: asf is about people not code so maven must care about people
> > and
> > > this is why 72h came from.
> > >
> > > For me dependencies is not a reason to make release < 72h since you can
> > > release 10 projects in a single staging - anyone failling rolls back
> them
> > > all but that is the intent anyway right?
> > > It means releasing 150+ projects can be done in....72h ;).
> > >
> > > It is done with success at apache by multiple projects and respects the
> > > core of our foundation, human beings.
> > >
> > > Now no user complained of waiting for 72h and if we are good enough in
> > > votes it is the needed time so think the issue you want to tackle is
> > > elsewhere, really.
> > >
> > > Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák <ta...@cservenak.net> a
> > > écrit :
> > >
> > > > 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.jencks@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 <
> tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák <ta...@cservenak.net> a
écrit :

> So Maven cares for us, hence the 72h? I don't get how one is deduced from
> another.
>
> And as they are (and usually are) dependent on each other from perspective
> of single release mgr local repo we could release all 150+, at the cost of
> breaking all the 150+ CI jobs and all source builds in the wild for at
> least 72+2h (actually more, as _during_ release preparation they would
> start breaking, not only during vote). So, thank you, but no, thank you :D
>
> Strange, that you say "no user complained of waiting". From where did you
> source this information, or from where can you support this claim?
>
> Just as an example, complaints on Slack do happen, quite often and
> regularly.
>

Not of the 72h, just of the months they need to wait, please dont mix it.
Also which % compared to the user base?

Also note that all your computations sounds false since the release can be
ran by multiple clients at once in the same staging, dont play the extreme
game, in practise a single repo works for 5-6 projects - way bigger than 10
maven projects ;) - in a very controlled time. If you need 30 maven
projects it will work without any issue....but once again it is likely not
an issue maven hits, the process being heavy - didnt say only for bads - is
way more hurting and slowing us down (even make features abandonned) than 3
days.



> T
>
>
>
> On Fri, Nov 18, 2022 at 9:19 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Side note: asf is about people not code so maven must care about people
> and
> > this is why 72h came from.
> >
> > For me dependencies is not a reason to make release < 72h since you can
> > release 10 projects in a single staging - anyone failling rolls back them
> > all but that is the intent anyway right?
> > It means releasing 150+ projects can be done in....72h ;).
> >
> > It is done with success at apache by multiple projects and respects the
> > core of our foundation, human beings.
> >
> > Now no user complained of waiting for 72h and if we are good enough in
> > votes it is the needed time so think the issue you want to tackle is
> > elsewhere, really.
> >
> > Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák <ta...@cservenak.net> a
> > écrit :
> >
> > > 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.jencks@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 <tamas@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.jencks@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

So Maven cares for us, hence the 72h? I don't get how one is deduced from
another.

And as they are (and usually are) dependent on each other from perspective
of single release mgr local repo we could release all 150+, at the cost of
breaking all the 150+ CI jobs and all source builds in the wild for at
least 72+2h (actually more, as _during_ release preparation they would
start breaking, not only during vote). So, thank you, but no, thank you :D

Strange, that you say "no user complained of waiting". From where did you
source this information, or from where can you support this claim?

Just as an example, complaints on Slack do happen, quite often and
regularly.

T



On Fri, Nov 18, 2022 at 9:19 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Side note: asf is about people not code so maven must care about people and
> this is why 72h came from.
>
> For me dependencies is not a reason to make release < 72h since you can
> release 10 projects in a single staging - anyone failling rolls back them
> all but that is the intent anyway right?
> It means releasing 150+ projects can be done in....72h ;).
>
> It is done with success at apache by multiple projects and respects the
> core of our foundation, human beings.
>
> Now no user complained of waiting for 72h and if we are good enough in
> votes it is the needed time so think the issue you want to tackle is
> elsewhere, really.
>
> Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > 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 <da...@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.jencks@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

Side note: asf is about people not code so maven must care about people and
this is why 72h came from.

For me dependencies is not a reason to make release < 72h since you can
release 10 projects in a single staging - anyone failling rolls back them
all but that is the intent anyway right?
It means releasing 150+ projects can be done in....72h ;).

It is done with success at apache by multiple projects and respects the
core of our foundation, human beings.

Now no user complained of waiting for 72h and if we are good enough in
votes it is the needed time so think the issue you want to tackle is
elsewhere, really.

Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák <ta...@cservenak.net> a
écrit :

> 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 <da...@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.jencks@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

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 <da...@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 <da...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

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 <da...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

David,

I just meant that there is a "forced pause" of 72h.

T

On Fri, Nov 18, 2022 at 7:50 PM David Jencks <da...@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?
>
>

Re: [DISCUSS] Speed up release process?

[David Jencks <da...@gmail.com>]

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

AFAIK cascading dependencies can be handled by releasing cause + all effects at once.  If that’s hard to do now, maybe there’s a way to make it easier. I’d expect it would make testing a change more plausible as well.

David Jencks

> On Nov 18, 2022, at 10:44 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> 
> Hi Tamás,
> 
> Is 3 days that bothering - didnt spot it to be honest?
> Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't
> think you can say for a maximum otherwise it means you need to cancel if
> you don't get it ;) - but it also means you mean the project does not care
> about its core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
> 
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
> 
> Hope it makes sense.
> 
> 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 ven. 18 nov. 2022 à 18:55, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
> 
>> Howdy,
>> 
>> My pet peeve these days is our release process. IMHO, we should be able to
>> release ("move") much faster than today.
>> 
>> My proposal would be:
>> * vote is "done done" the moment quorum is reached
>> * change the wording in the vote email from "Vote open for at least 72
>> hours." to "Vote open for a maximum of 72 hours.".
>> 
>> Reasoning:
>> * vote cannot be vetoed by definition (only release mgr can cancel it).
>> * change would not conflict with ASF defined rules, the 72h is not
>> compulsory (document states "should" not "must").
>> * the release process is already wearisome, complex, and is easy to miss
>> (over-represented) manual steps. For example yesterday for some reason it
>> took almost 2 hours to sync release artifacts to Maven Central, during
>> which you are in a "busy loop" (the announcement and site depends on sync).
>> Leaving it "for tomorrow" may cause users to learn about a new release thru
>> Artifact Listener or whatever other service, causing confusion. Ideally,
>> site and announcement mail should be tied to sync, and that does lead to
>> "busy loop".
>> * 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.
>> * which part do you like: as a developer sitting on needles while being
>> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
>> * we already agreed on one minor process improvement: we have quite long
>> "chains" of dependencies, so a bugfix that can span on long trails could
>> take weeks to be done serially, even if the bugfix itself is trivial. Hence
>> we did accept that we can do "batch votes" (release together) and can do
>> one vote for this case.
>> * on positive site this could lead to mindset change of bugfix releases, as
>> today, few wants to go thru painful release process for "single simple
>> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
>> wrong: we all should release early and often. And be happy with it, not
>> feel it like chores :)
>> 
>> Finally some "canned responses":
>> * "time is needed for all interested parties to review": If someone cannot
>> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
>> does not matter, as release is to happen anyway (unless release mgr cancels
>> it). One not getting to it, will be notified via mails anyway (vote,
>> result, announce). We can already observe that there are "areas of
>> interests", but also there is the customary habit of "review invitation"
>> which is a good thing IMHO, as usually one invites a colleague with whom
>> the topic was or is under discussion already, so both of them are
>> "contextualized". Those initiated developers will most probably join in
>> voting for release as well, as either they depend on the fix or they know
>> what the problem was.
>> * "this will lead to more bugs" or "we are too hasty making changes": no,
>> it will not and we are not. As in essence, this change would allow us, in
>> case of need, to release even multiple times per day (so release the
>> project carrying a bug in the morning, then have a patch release for it in
>> the afternoon). Really, as bugs are inevitable, they happen with or without
>> 72 hours, still the current process just causes problems IMHO. As the new
>> release is sitting on Central, without immediate remediation possibility.
>> Or to put it another way, having this option open does not mean we will
>> make all releases like it, and we will not start competing by releasing all
>> the plugins several times a day :) You can see there are "hot spots'' (if
>> you look at maveniverse as whole, sometimes plugins, sometimes shared
>> stuff, sometime maven, etc), especially with closing releases of Maven, but
>> those hotspots come and go, move, and just like today, some components will
>> not be released for quite some time, as the hotspots move from here to
>> there.
>> 
>> Applying this process change, if accepted, would not alter anything
>> regarding "commit policy" of code changes (PRs, JIRA attached patches,
>> etc).
>> 
>> Refs:
>> https://www.apache.org/foundation/voting.html
>> https://www.apache.org/legal/release-policy.html
>> 
>> Please comment, add your opinion. Ideally, if discussion closes with
>> "positive outcome", I would like to propose a vote for these changes.
>> 
>> Thanks
>> T
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Speed up release process?

[Tamás Cservenák <ta...@cservenak.net>]

Howdy,

I think you got it a bit "upside down": it is not a project that "cares"
for people (this is not a corp), it is the other way around. As for key
people, they should be "key" for a reason, I trust they care, so I am
pretty much sure "key people" will be present when needed (they usually
are). On the other hand, if a PMC member decides to take a bus tour and
crashes, the fact he lies in a hospital (in gypsum with hanging limbs, like
in cartoons) does not mean he doesn't care, as he will not vote even after
72h (replace here child birth, hangover after a too successful party, or
whatever). And again, unsure what 3 days matter. Release process is already
HOURS (just sync is 2+), so let's make it AT LEAST 72h? It should be a push
of a button.

But I think I described where 72h does matter, in my 1st mail.

The answer to "it is a good thing to enable people to review a release and
have the opportunity to give feedback" is among canned responses :)


T

On Fri, Nov 18, 2022 at 7:44 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:

> Hi Tamás,
>
> Is 3 days that bothering - didnt spot it to be honest?
> Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't
> think you can say for a maximum otherwise it means you need to cancel if
> you don't get it ;) - but it also means you mean the project does not care
> about its core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
>
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
>
> Hope it makes sense.
>
> 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 ven. 18 nov. 2022 à 18:55, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > My pet peeve these days is our release process. IMHO, we should be able
> to
> > release ("move") much faster than today.
> >
> > My proposal would be:
> > * vote is "done done" the moment quorum is reached
> > * change the wording in the vote email from "Vote open for at least 72
> > hours." to "Vote open for a maximum of 72 hours.".
> >
> > Reasoning:
> > * vote cannot be vetoed by definition (only release mgr can cancel it).
> > * change would not conflict with ASF defined rules, the 72h is not
> > compulsory (document states "should" not "must").
> > * the release process is already wearisome, complex, and is easy to miss
> > (over-represented) manual steps. For example yesterday for some reason it
> > took almost 2 hours to sync release artifacts to Maven Central, during
> > which you are in a "busy loop" (the announcement and site depends on
> sync).
> > Leaving it "for tomorrow" may cause users to learn about a new release
> thru
> > Artifact Listener or whatever other service, causing confusion. Ideally,
> > site and announcement mail should be tied to sync, and that does lead to
> > "busy loop".
> > * 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.
> > * which part do you like: as a developer sitting on needles while being
> > blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
> > * we already agreed on one minor process improvement: we have quite long
> > "chains" of dependencies, so a bugfix that can span on long trails could
> > take weeks to be done serially, even if the bugfix itself is trivial.
> Hence
> > we did accept that we can do "batch votes" (release together) and can do
> > one vote for this case.
> > * on positive site this could lead to mindset change of bugfix releases,
> as
> > today, few wants to go thru painful release process for "single simple
> > change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
> > wrong: we all should release early and often. And be happy with it, not
> > feel it like chores :)
> >
> > Finally some "canned responses":
> > * "time is needed for all interested parties to review": If someone
> cannot
> > get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
> > does not matter, as release is to happen anyway (unless release mgr
> cancels
> > it). One not getting to it, will be notified via mails anyway (vote,
> > result, announce). We can already observe that there are "areas of
> > interests", but also there is the customary habit of "review invitation"
> > which is a good thing IMHO, as usually one invites a colleague with whom
> > the topic was or is under discussion already, so both of them are
> > "contextualized". Those initiated developers will most probably join in
> > voting for release as well, as either they depend on the fix or they know
> > what the problem was.
> > * "this will lead to more bugs" or "we are too hasty making changes": no,
> > it will not and we are not. As in essence, this change would allow us, in
> > case of need, to release even multiple times per day (so release the
> > project carrying a bug in the morning, then have a patch release for it
> in
> > the afternoon). Really, as bugs are inevitable, they happen with or
> without
> > 72 hours, still the current process just causes problems IMHO. As the new
> > release is sitting on Central, without immediate remediation possibility.
> > Or to put it another way, having this option open does not mean we will
> > make all releases like it, and we will not start competing by releasing
> all
> > the plugins several times a day :) You can see there are "hot spots'' (if
> > you look at maveniverse as whole, sometimes plugins, sometimes shared
> > stuff, sometime maven, etc), especially with closing releases of Maven,
> but
> > those hotspots come and go, move, and just like today, some components
> will
> > not be released for quite some time, as the hotspots move from here to
> > there.
> >
> > Applying this process change, if accepted, would not alter anything
> > regarding "commit policy" of code changes (PRs, JIRA attached patches,
> > etc).
> >
> > Refs:
> > https://www.apache.org/foundation/voting.html
> > https://www.apache.org/legal/release-policy.html
> >
> > Please comment, add your opinion. Ideally, if discussion closes with
> > "positive outcome", I would like to propose a vote for these changes.
> >
> > Thanks
> > T
> >
>

Re: [DISCUSS] Speed up release process?

[Romain Manni-Bucau <rm...@gmail.com>]

Hi Tamás,

Is 3 days that bothering - didnt spot it to be honest?
Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't
think you can say for a maximum otherwise it means you need to cancel if
you don't get it ;) - but it also means you mean the project does not care
about its core people - if you start the release on friday night you
potentially let 0s to some PMC and users to review the release.
Indeed it is ont an apache requirement but I think it is a good thing to
enable people to review a release and have the opportunity to give feedback
so 3 days sounds like a very good default if you take into account the
world side - timezones - of our project.

Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
... - anything not final or urgent but very located.

Hope it makes sense.

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 ven. 18 nov. 2022 à 18:55, Tamás Cservenák <ta...@cservenak.net> a
écrit :

> Howdy,
>
> My pet peeve these days is our release process. IMHO, we should be able to
> release ("move") much faster than today.
>
> My proposal would be:
> * vote is "done done" the moment quorum is reached
> * change the wording in the vote email from "Vote open for at least 72
> hours." to "Vote open for a maximum of 72 hours.".
>
> Reasoning:
> * vote cannot be vetoed by definition (only release mgr can cancel it).
> * change would not conflict with ASF defined rules, the 72h is not
> compulsory (document states "should" not "must").
> * the release process is already wearisome, complex, and is easy to miss
> (over-represented) manual steps. For example yesterday for some reason it
> took almost 2 hours to sync release artifacts to Maven Central, during
> which you are in a "busy loop" (the announcement and site depends on sync).
> Leaving it "for tomorrow" may cause users to learn about a new release thru
> Artifact Listener or whatever other service, causing confusion. Ideally,
> site and announcement mail should be tied to sync, and that does lead to
> "busy loop".
> * 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.
> * which part do you like: as a developer sitting on needles while being
> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
> * we already agreed on one minor process improvement: we have quite long
> "chains" of dependencies, so a bugfix that can span on long trails could
> take weeks to be done serially, even if the bugfix itself is trivial. Hence
> we did accept that we can do "batch votes" (release together) and can do
> one vote for this case.
> * on positive site this could lead to mindset change of bugfix releases, as
> today, few wants to go thru painful release process for "single simple
> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
> wrong: we all should release early and often. And be happy with it, not
> feel it like chores :)
>
> Finally some "canned responses":
> * "time is needed for all interested parties to review": If someone cannot
> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
> does not matter, as release is to happen anyway (unless release mgr cancels
> it). One not getting to it, will be notified via mails anyway (vote,
> result, announce). We can already observe that there are "areas of
> interests", but also there is the customary habit of "review invitation"
> which is a good thing IMHO, as usually one invites a colleague with whom
> the topic was or is under discussion already, so both of them are
> "contextualized". Those initiated developers will most probably join in
> voting for release as well, as either they depend on the fix or they know
> what the problem was.
> * "this will lead to more bugs" or "we are too hasty making changes": no,
> it will not and we are not. As in essence, this change would allow us, in
> case of need, to release even multiple times per day (so release the
> project carrying a bug in the morning, then have a patch release for it in
> the afternoon). Really, as bugs are inevitable, they happen with or without
> 72 hours, still the current process just causes problems IMHO. As the new
> release is sitting on Central, without immediate remediation possibility.
> Or to put it another way, having this option open does not mean we will
> make all releases like it, and we will not start competing by releasing all
> the plugins several times a day :) You can see there are "hot spots'' (if
> you look at maveniverse as whole, sometimes plugins, sometimes shared
> stuff, sometime maven, etc), especially with closing releases of Maven, but
> those hotspots come and go, move, and just like today, some components will
> not be released for quite some time, as the hotspots move from here to
> there.
>
> Applying this process change, if accepted, would not alter anything
> regarding "commit policy" of code changes (PRs, JIRA attached patches,
> etc).
>
> Refs:
> https://www.apache.org/foundation/voting.html
> https://www.apache.org/legal/release-policy.html
>
> Please comment, add your opinion. Ideally, if discussion closes with
> "positive outcome", I would like to propose a vote for these changes.
>
> Thanks
> T
>

Re: [DISCUSS] Speed up release process?

[Manfred Moser <ma...@simpligility.ca>]

+1

That sounds good to me. There is plenty of communication going on BEFORE 
the release is even kicked off.. from then on it really should be just 
process and minimal validation. If something goes wrong.. run another 
patch release.

I would even go for .. lazy consensus after 48 hours counts as well.

Manfred

On 2022-11-18 9:55 a.m., Tamás Cservenák wrote:
> Howdy,
>
> My pet peeve these days is our release process. IMHO, we should be able to
> release ("move") much faster than today.
>
> My proposal would be:
> * vote is "done done" the moment quorum is reached
> * change the wording in the vote email from "Vote open for at least 72
> hours." to "Vote open for a maximum of 72 hours.".
>
> Reasoning:
> * vote cannot be vetoed by definition (only release mgr can cancel it).
> * change would not conflict with ASF defined rules, the 72h is not
> compulsory (document states "should" not "must").
> * the release process is already wearisome, complex, and is easy to miss
> (over-represented) manual steps. For example yesterday for some reason it
> took almost 2 hours to sync release artifacts to Maven Central, during
> which you are in a "busy loop" (the announcement and site depends on sync).
> Leaving it "for tomorrow" may cause users to learn about a new release thru
> Artifact Listener or whatever other service, causing confusion. Ideally,
> site and announcement mail should be tied to sync, and that does lead to
> "busy loop".
> * 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.
> * which part do you like: as a developer sitting on needles while being
> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
> * we already agreed on one minor process improvement: we have quite long
> "chains" of dependencies, so a bugfix that can span on long trails could
> take weeks to be done serially, even if the bugfix itself is trivial. Hence
> we did accept that we can do "batch votes" (release together) and can do
> one vote for this case.
> * on positive site this could lead to mindset change of bugfix releases, as
> today, few wants to go thru painful release process for "single simple
> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
> wrong: we all should release early and often. And be happy with it, not
> feel it like chores :)
>
> Finally some "canned responses":
> * "time is needed for all interested parties to review": If someone cannot
> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
> does not matter, as release is to happen anyway (unless release mgr cancels
> it). One not getting to it, will be notified via mails anyway (vote,
> result, announce). We can already observe that there are "areas of
> interests", but also there is the customary habit of "review invitation"
> which is a good thing IMHO, as usually one invites a colleague with whom
> the topic was or is under discussion already, so both of them are
> "contextualized". Those initiated developers will most probably join in
> voting for release as well, as either they depend on the fix or they know
> what the problem was.
> * "this will lead to more bugs" or "we are too hasty making changes": no,
> it will not and we are not. As in essence, this change would allow us, in
> case of need, to release even multiple times per day (so release the
> project carrying a bug in the morning, then have a patch release for it in
> the afternoon). Really, as bugs are inevitable, they happen with or without
> 72 hours, still the current process just causes problems IMHO. As the new
> release is sitting on Central, without immediate remediation possibility.
> Or to put it another way, having this option open does not mean we will
> make all releases like it, and we will not start competing by releasing all
> the plugins several times a day :) You can see there are "hot spots'' (if
> you look at maveniverse as whole, sometimes plugins, sometimes shared
> stuff, sometime maven, etc), especially with closing releases of Maven, but
> those hotspots come and go, move, and just like today, some components will
> not be released for quite some time, as the hotspots move from here to
> there.
>
> Applying this process change, if accepted, would not alter anything
> regarding "commit policy" of code changes (PRs, JIRA attached patches, etc).
>
> Refs:
> https://www.apache.org/foundation/voting.html
> https://www.apache.org/legal/release-policy.html
>
> Please comment, add your opinion. Ideally, if discussion closes with
> "positive outcome", I would like to propose a vote for these changes.
>
> Thanks
> T
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org