> Knowing the a due-date for submissions longer in advance could also
> reduce the endgame rush we just experienced.
That's the problem, actually 'agile' don't is another term for
unorganized release whenever you think it fits.
Especially if we want an agile development process we need clear rules
what happen when (I'm also fine wit 'automatic release each week, please
finish until Friday').
Currently it is more: Get something in and it probably would approach
some time (as literally not every committer can actually do a release
easily!).
^^ That is probably the biggest issue we should be speaking about. What are the issues preventing committers to do a release?
And even if we are not officially bound to the SimRel cycle it just
takes another three month until everything bubbles up as it is not
realistic for everyone to expect they are (allowed!) using snapshots.
> An issue for each action is a bit too fine grain IMHO.
For sure we can polish this a bit, but actually it is not worse to drop
a line what one tries to accomplish you don't have to write a full blown
user-story, I often found that these 'small things' tend to grow bigger
and in the end I always create a ticket just to have it referenced as
the branch-name :-)
Am 08.02.22 um 11:30 schrieb Hannes Wellmann:
> Thank you Christoph for your proposal.
> I support it. It makes the release process more transparent and
> predictable so everybody knows what can be expected.
> Knowing the a due-date for submissions longer in advance could also
> reduce the endgame rush we just experienced.
> I just have one remark to point 1:
> An issue for each action is a bit too fine grain IMHO. For example if I
> just perform some clean ups or similar a issue just adds more noise and
> I have think about an description what is obvious from the code.
> I suggest to have an issue only for each feature or greater work,
> especially if it is a longer running work that is relevant for planning.
> It can then absolutely be possible to have multiple PRs for one issue.
> But if I just find small improvements, apply them and create a PR
> immediately I don't see a benefit from creating an issue. Discussion
> about the code can be done better in a PR and for release planning this
> also not relevant.
> If there is a final agreement about the release process I suggest to
> document it. Maybe in the CONTRIBUTING.md. next to the version-bump
> schema or in a dedicated file (the version rules could then go there as
> well).
> *Gesendet:* Dienstag, 08. Februar 2022 um 11:06 Uhr
> *Von:* "Christoph Läubrich" <laeubi@xxxxxxxxxxxxxx>
> *An:* "Maven Integration for Eclipse developers mailing list"
> <m2e-dev@xxxxxxxxxxx>
> *Betreff:* [m2e-dev] Release Planning
> As the recent discussions and rumor I'd like to propose some kind of
> 'rules' (maybe there are already some and I haven't found them?) to get
> this release stuff more smooth in the future (and even faster releases).
>
> 1) We should create an issue for every action (excluding documentation
> changes) and either:
> - assign the current milestone if we plan to work on this in the
> current release cycle
> - not assign a milestone if we will do it "sometimes"
>
> 2) If we ask for a release, also ask for ultimately marking issues to be
> included within a given time frame (I would suggest one week and thus
> name it "planning week" from now on) and
>
> 3) Then we should discuss in this "planning week" on the marked issues
> if they go into the release or should be postponed if there any
> concerns. If postponed, we should assign the next milestone or remove it
> if we do not want to get this in for the next release.
>
> 4) After this "planning week" we assign a release date (github allows to
> set a due-date on a release) that should be at most two weeks maybe we
> choose then to postpone some things because there is no time to actually
> develop this feature ...
>
> 5) From now on we only add bugs to the current release, if something is
> a bug might be discussed on the ticket.
>
> 6) All features should be finished one week before the release so we
> have a time where we only work on regressions (if any).
>
> That way we always have a clear understanding what is "open" for the
> current release and if there is a risk we miss the date due to the
> current status of the milestone.
>
> Given that, we should be able to release once a month if desired and I
> think that's acceptable as a lower bound.
> _______________________________________________
> m2e-dev mailing list
> m2e-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/m2e-dev
> <https://www.eclipse.org/mailman/listinfo/m2e-dev>
>
> _______________________________________________
> m2e-dev mailing list
> m2e-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev
