All thinks I would fully agree ... but we don't have the automated CI build yet that can do this, and we *must* deliver stable and reliable API's.
So please consider that there are some "not agile" practices we *must* follow until we have a fully automated solution in CI.
It is not fun, it does not increase the diversity or attract new contributors, this is just work that *must* be done.
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
Gesendet: Donnerstag, 09. Mai 2019 um 10:21 Uhr
Von: "Mickael Istria" <mist...@redhat.com>
An: "Eclipse platform general developers list." <platform-dev@eclipse.org>
Betreff: Re: [platform-dev] API changes in SDK
Von: "Mickael Istria" <mist...@redhat.com>
An: "Eclipse platform general developers list." <platform-dev@eclipse.org>
Betreff: Re: [platform-dev] API changes in SDK
Hi,
While I understand Andrey and others and fully agree with them on the necessity and value of project respecting API rules and process for that -while I am one of the "worst citizen" on that matter in practice-, I think any proposal that involves enforcing developers to use or setup anything specific beyond the obvious is likely to fail. We cultivate diversity in the project and the community, and by this, we also cultivate "deviation" which ultimately drives to innovation which is something we're seeking.
So to me, enforcing a process to developers is 1. unrealistic because there will always be deviant people that we still want to feel welcome as they provide value and 2. not really desired as we want to constantly "lower the entry barrier" or "reduce maintenance effort" and such heavy process can really be expensive or blockers.
I also have the impression that this story is an instance of the agile's "People over process and tools" motto. Proposals that involve people to do thing differently are "process over people", proposals that enforce people to use a tools are "tools over people". Both should be avoided as final solution.
We see our community of contributors and committers very happy with Gerrit, good discussions happening here, people enjoy the review flow and the automated CI builds. So that's where people are and want to be when it comes to interacting and ensuring quality gates. This is where we should try to hook things; and since CI is just an instance of a build, it seems like putting some focus on automation of check at submission-time is something that would both reduce the need to follow a process and reduce the enforcement of tools. That is IMO the silver-bullet and where all consideration and effort on the topic of API versioning automation should be put. Let's continue the technical discussion about this silver-bullet in the related bugs ;)
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
