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". > 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. > > Marcus > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> -- Jim "This is an outrage!" Tony Harrison
