[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-dev] Release Planning
|
You wrote:
> However, I'm not sure the Eclipse Development Process easily allows
that as we need to manually add releases to the PMI.
So that actually *IS* the "1 team obeying to the same boss" but that
boss is not actually paing me at all nor I get any revenue from this ..
And if people are mad about "endless releases" we just need a process we
can negotiate on, we don't need any planing but some kind of negotiation.
> Why?
You said we should release more often, so once a week is more than once
a month or once a quarter :-)
> What would that change to your development?
> Will you be able to deliver more value faster with this?
1) We simply do not need to mind to get something in until date x, but
will deliver a constant stream of improvements and value.
2) If I know that my change will only be delayed by one week I won't
mind to polish it a bit more.
3) If I have a bug/regression/feature/... I'm more convinced to provide
a PR if I see I can have it official released in a short time and I can
use it (e.g. ask my IT to upgrade to release X instead of asking to be
allowed to use an unclear moving target snapshot version)
4) It is less risky to upgrade from a version with a small set of
changes (including a crucial fix for my usecase)
5) It is less risky if we 'break' something as there is a high chance to
get it fixed soon, if there was a bad change people can go back to the
previous version for some days until it is fixed (and released) instead
of loosing every feature from the previous months.
> I don't think we can really do it without leaving some opportunity to
for PMC and others to review from time to time.
We can have a timed job that creates a release-review request each
month/half a year/ ...
Am 08.02.22 um 11:59 schrieb Mickael Istria:
On Tue, Feb 8, 2022 at 11:48 AM Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
That's the problem, actually 'agile' don't is another term for
unorganized release whenever you think it fits.
I mean agile in the sense "people over process" and other commandments
of the Agile Manifesto. But things like planning, sprints, roadmaps...
all that does apply if there is 1 team obeying to the same boss for the
same product; it's never the case in community OSS. OSS is more diverse
and actually needs less procedural organization, not more, to be successful.
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').
Why? What would that change to your development? Will you be able to
deliver more value faster with this?
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev