>> It is fundamentally wrong to rely on written description of processes (not >> to be confused with documentation). We script, we >> write code, we do not read prose. > > Sorry but the integration requires human intervention at least to make sure > we do not merge bullshits or checking conflicts just before. > Right now this is like that. Then even a script should be commented and > documented. When I read you, you give the impression to > the rest of the world that we are idiots doing everything manually. But this > is not the case. We are doing only 2%: checking conflicts, > writing the log and closing the bugs. Of course we should continue and make > it fully automate.
Which is something we solved with Ben 2 years ago. It did not do everything automatically, but as much as you can: - it list the issues that can be integrated - it lets you select the issues to be integrated - it shows the diff of the integrated changes - it triggers a new update cycle That means, not more manually copying over issue descriptions, no more manually closing issues. I guess it doesn't work anymore since nobody used it since then, but that is definitely something that should be taken care of. > To me the bottleneck is that the process is not concurrent and that conflicts > are not automatically detected once we qualify a fix > as ready to include. Since another changes can be made in parallel we can > have conflict and it means that the automated approach > should recheck all the pending fixes to make sure that none of them got into > conflict since the last integration. This is exactly how the monkey works. it checks for each release again if all the pending fixes integrate cleanly. For each check it will add a tag, [validated in 30xxx]. >> And the scriptloader comment is, and never was complete either, since it >> excluded the >> interaction on the bug tracker. Issues have to be closed after integrating >> them, well >> marcus did that job yesterday, but this has to be done automatically in the >> integration process. > > Indeed but instead of getting on your favorite topic, tell me where is the > update.list? > So that I can edit it. => see further down, it is here: http://files.pharo.org/updates/pharo3.0/ > I do not understand why it is not in the pharo-update folder Because it is generated, you do not touch it. Look at it some sort of code duplication. And furthermore it is separated into two parts, staged updates (which are not public) and the public updates (updates.list). If the staged updates fail, the updates.list never even gets modified, hence you do not have to manually edit it. This is far less error prone than the previous update process and requires almost never a manual retraction of an update, since it never even gets released when the update doesn't work. So all in all less work. > Because any scripted actions should also support full rollback and so far I > cannot rollback > a change even manually because I do not know where this file is and how I can > edit it. > > This comment does not help. - it tells you exactly where the file is(answering your above question): http://files.pharo.org/updates/pharo3.0/ - again forwarding to the proper jenkins jobs from files.pharo.org - it also tells you where the file is generated: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/ So the next step is to read the description of the jenkins jobs: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-0-Prepare/ https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ ... and so forth, Unlike what you say, it is properly documented, not centralized, but in all places where the things happen. I really wonder what is missing. Yes, there are some dangling links on jenkins since the update process go recently modified, but these are things that happen.
signature.asc
Description: Message signed with OpenPGP using GPGMail
