| Hi,
> The only good way to report a bad state is to fail the build so it doesn't pass review.
That is exactly what I had in mind.
Given Alexander’s arguments, I stand corrected: "release early, release often". For GEF, automation of the process will be advanced further. I want to contribute a newer version only when it adds value.
The only issue I have with the current release process is deciding beforehand what version will be contributed. Maybe I am misunderstanding something about the process, though.
Best regards, Matthias
--
Matthias Wienand B.Sc. Softwaretechnik Software Engineer Telefon: +49 231 9860 202 Telefax: +49 231 9860 211 Mobil: +49 176 248 950 82 matthias.wienand@xxxxxxxxxhttp://www.xing.com/profile/Matthias_Wienand2 http://www.itemis.de itemis AG Niederlassung Lünen Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Abdelghani El-Kacimi Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
Hi all,
+1 for going back to annual releases.
Projects are not forced to do quarterly releases. You can have your project do a yearly release, but it just means that since Platform releases every 3 months, you need to check your project against 2 milestones and 2 RCs of the Platform every 3 months (12 times a year). Which doesn't change much compared to previous state where projects were supposed to be tested against all Platform milestones and RC, ie 11 times a year.\
The work done by Ed M is very appreciated. Ideally, the different checks (e.g. licenses) could be automated to prevent degradation of SimRel quality.
The licence check may be missing, and could be added. Or one can probably just build a similar Maven configuration to run the other analyzers. But the real thing is that what matters is not building the report, but enforcing rules without human intervention. This typically happens only with mechanism that fail the build in case the analyzers see issue. As long as human reading is required, it cost too much effort and time to someone, and feedback loop becomes too long. The only good way to report a bad state is to fail the build so it doesn't pass review.
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
