[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] Release Planning
|
> 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!).
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
