Skip to main content
[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

Back to the top