Am 06.11.26 um 12:50 schrieb Jim Jagielski:
Personally, I would vote -1 for any suggestion to add a scrum workflow...
IMO, there is a difference between wanting guardrails and wanting roadblocks.
And I consider scrum the latter.
If there is one problem we do NOT suffer from, it is "moving too quickly".
sure, it stands of falls with the acceptance of the people.
It was my idea to prevent a mess that *could* happen when now more and
more commits goes into the code.
BTW:
A concept of guarding and SCRUM are 2 different worlds. At least with my
logic.
Marcus
On Nov 6, 2026, at 6:43 AM, Marcus <[email protected]> wrote:
Am 06.11.26 um 09:07 schrieb Petko.apache.org <https://petko.apache.org/> via
dev:
Am 05.11.2026 um 21:43 schrieb Arrigo Marchiori via dev:
Hello All,
On Thu, Nov 05, 2026 at 06:52:47PM +0100, Marcus wrote:
Am 05.11.26 um 12:14 schrieb Jim Jagielski:
Since the focus is on getting AOO5 out, we should assume that anything added to
`trunk` is a candidate for backport to `AOO50X`.
i the past we did this by strictly work with squash commits. one commit we
thought done went into trunk and could be cherry picked.
If there are long-term, "experimental" work efforts, then we don't want to stop
them, but, IMO at least, maybe they should be done in branches off of `trunk` and not
folded _into_ trunk. One reason why work on 4.2.X stagnated was because of that exact
reason: that trunk and AOO42X just diverged way, way too much.
This is not correct. The issue was no one who did the development cares about
what was on the list for doing. And in my eyes this has not changed.
Does that make sense?
in theory yes.
If we do this why maintain a v5 branch.
It makes sense to me too.
I think we could also accept force-pushes to such separate
branches... but that may be worth a separate discussion.
If we add this we need to make sure that PRs get accepted. We have PRs that
received no attention.
Some are simply not ready. And we should concider that if work through PRs
development discussion shift into PR.
(away from the list)
It would work good when every dev thinks / remember always
and in every situation this role - also in 12 month.
I am not sure I understand what you mean?
To support this, maybe it be better when we have a role that takes care of
the release management in general.
One task is to keep an eye on the commits of every branch inkl. trunk.
As an increase, every dev has to ask if committing / merging in a branch is
ok, before doing so.
Pull requests should be issued in the Review-then-Commit spirit and
thus serve to this purpose... shouldn't they?
I am sceptical if we can do this. And if we have a broad commitment for this.
We can try of course. but honestly i think adapting scrum to our frame would
make more sense, then add hierarchy.
I don't see the hierarchy behind the idea (btw: it's 1 role and not more ;-) ).
It's more about the protection we could get for the branches. Then they are
much more clean and always buildable.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
