Le mer. 23 nov. 2022 à 14:38, Romain Manni-Bucau 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
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
Tamas,
Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák
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:
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".
Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák 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
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
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
Agree asf enables to release without feedbackquestion 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
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
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
Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák 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
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
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
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
+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
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
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 wrote:
>
> As I wrote, we did have examples of changes + cascading, it is okay.
>
> But I don't
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
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 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
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
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
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
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
David,
I just meant that there is a "forced pause" of 72h.
T
On Fri, Nov 18, 2022 at 7:50 PM David Jencks
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
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
+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
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
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
28 matches
Mail list logo
