>>> 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
I'm favor of that. Now why neither marcus me or esteban do not use it? May be because we are afraid that if something break we are at loss. At least this is a stress to integrate a fix (even fullllllllly automated - the prove is that our wonderful staged process lets me publish cs while it should not else you would not complain that the system produced new items without corresponding images) In which languages are the scripts and logic written? What I like with ScriptLoader is that I can debug and change the process. And I will not use bash or ruby to do boring things - I do not want to invest in any thing that does not have a decent debugger. I'm sorry I do not have the time for that. > 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. Yes! >> 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]. in which the SmalltalkHub project is the monkey hosted? I would like to read the code (if this is in ruby no need to send me the info I will not look at it - my plate is full not time. I'm learning Ada parsing, Python semantics and JS security and this is enough for me right now). >>> 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 git repository. Because I do not know how to access the file server and the file server has protection…. >> 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. I know that! I know the staged process. Now in that case we should have a way to remove entries in the updates.list. This is exactly because we cannot remove entries that you get the extra images that are not found and that you complain about. If the process is automated it should also handle the failure well. Else we are at loss and you need to know that yes modifying this file on the server…… balblbalbalbalbalb And now 1/3 of the integrators does not know how to do it! But I can also not integrate fixes and enjoy looking smart building great new things. It is also better for the ego. > 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. Camillo please stop to brainwash me. Please I *****KNOW******* all the good arguments. I like them. I'm in favor of them but please give me a break. This is me that is losing time when I integrate a change that does not work (and that the wonderful process should not let in (which surprisingly it did) --- so I have to handle the consequences of something that I do not fully have access to - really frustrating. >> 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/ cool that this is in Pharo ./pharo Pharo.image eval " updates := (ZnEasy get: 'http://files.pharo.org/updates/pharo3.0/updates30.list') contents lines. updates := updates reject: [ :each | each beginsWith: '#' ]. staged := 'updates30.staged' asFileReference readStream contents asString lines. staged := staged reject: [ :each | each beginsWith: '#' ]. updates := (updates, staged) asSet asArray sorted. 'updates30.list' asFileReference ensureDeleted writeStreamDo: [ :output | output nextPutAll: '#Pharo3.0'; cr. updates do: [ :each | output nextPutAll: each; cr ]]. Smalltalk snapshot: false andQuit: true." So how can I publish on files.pharo.org SSH: Connecting from host [pharo-linux64] SSH: Connecting with configuration [files.pharo.org] ... SSH: EXEC: STDOUT/STDERR from command [rm /appli/files.pharo.org/updates/pharo3.0/updates30.staged || echo "NO updates30.staged FOUND"] ... SSH: EXEC: completed after 201 ms SSH: Disconnecting configuration [files.pharo.org] ... SSH: Transferred 1 file(s) is not meaningful to me. I thought that I could learn in the copied jenkins job but this is not the case. set -e wget updates.pharo.org/pharo3.0/updates30.staged wget -O- get.pharo.org/30+vm | bash ./pharo Pharo.image update --from-file=updates30.staged ./pharo Pharo.image printVersion > 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. HOW TO REMOVE AN ENTRY IN THE UPDATE LIST!!!! Now with my fix to the scriptLoader (less than 1 min) we will not have problem with popup on load on the server but still. I still do not understand why the staged development let me create new update. -- I do not fully understand why the check to verify the sync between the update and the image did not catch the problem and proposed me a new update. Probably because silently loading the latest image and loading empty updates and checking the last item (which was correct) => the check make sure that the updateXXX corresponds to the latest one in the update30 but nothing else. I got the problem some how. In addition I do not understand why the jenkins job were not red and let the update continue Stef
