What happened with those updates? Why are there no images? If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/ We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittle...
Camillo Bruni wrote:
What happened with those updates? Why are there no images?
If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/
We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittle...
Not sure if this is directly related, but I have been considering how the following functionality might be useful in PharoLauncher... From a list, select a Slice, launch an Image inclusive of a startup script that... * Integrated that Slice * Ran tests * Saved the Image and quit. * Fed back to PharoLauncher for it to display that this Image/Slice was now ready to be reviewed - now at just the click of a button. btw, Just want to say that I've been really enjoying using and contributing to PharoLauncher [1]. The code is really accessible and makes a good example for my first exposure to Spec. [1] https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/lastS... cheers -ben
Well, the current process would be that the issue validator runs on all "Fix Review Needed" Slices and marks them as ready. We had a simple UI where you could pick those issues and start an integration with it. The validator can be easily extended with another "publisher" which will create an image with the pending SLICE ready to be integrated. On 2013-10-21, at 17:05, btc@openinworld.com wrote:
Camillo Bruni wrote:
What happened with those updates? Why are there no images?
If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/
We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittle...
Not sure if this is directly related, but I have been considering how the following functionality might be useful in PharoLauncher... From a list, select a Slice, launch an Image inclusive of a startup script that... * Integrated that Slice * Ran tests * Saved the Image and quit. * Fed back to PharoLauncher for it to display that this Image/Slice was now ready to be reviewed - now at just the click of a button. btw, Just want to say that I've been really enjoying using and contributing to PharoLauncher [1]. The code is really accessible and makes a good example for my first exposure to Spec.
[1] https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/lastS...
cheers -ben
On Oct 21, 2013, at 3:08 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
What happened with those updates?
there was a problem because the packages were dirty and we got a popup on the serverâ¦. so we could not integrate simply their saved versions.
Why are there no images?
see above. I could not understand (I could not find and edit the updates.list to remove them) This is not documented!!!!!!!!!!
If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/
probably But there is no documentation (except what I wrote in ScriptLoader comment), so I cannot guess.
We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittleâ¦
And we added more complexity to it. Two years ago I knew where the updates.list file was stored. Not anymore. I could not find it in Pharo-update. So yes THIS IS FRUSTRATING. I spent two hours two integrate two packages and 3 methods! I'm probably an idiot. Stef PS: now scriptLoader will load without warning packages on dirty packages.
On 2013-10-21, at 18:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 21, 2013, at 3:08 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
What happened with those updates?
there was a problem because the packages were dirty and we got a popup on the serverâ¦. so we could not integrate simply their saved versions.
Why are there no images?
see above. I could not understand (I could not find and edit the updates.list to remove them) This is not documented!!!!!!!!!!
If something like this happens, the git exporter needs to be properly reset, otherwise we don't have consecutive numbers :/
probably But there is no documentation (except what I wrote in ScriptLoader comment), so I cannot guess.
I just don't like that all of a sudden things go wild without an announcement, and by chance I detect it, since I monitor all channels...
We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittleâ¦
And we added more complexity to it.
The point is that the integration process is not automated. It might be more complex now, but that's how far we can get with INRIA infrastructure. So the only thing we can do, since we will never have direct access to the file server, and I think this is better that way, is to automate the integration process as much as possible. As I said, we wrote a UI with ben together 2 years ago that does the whole integration without relying one some written specification. 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. 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.
probably But there is no documentation (except what I wrote in ScriptLoader comment), so I cannot guess.
I just don't like that all of a sudden things go wild without an announcement,
what is going wild?
and by chance I detect it, since I monitor all channels...
We really need to invest a couple of sprints in creating an integration UI, ben and I started this 2 years ago and it lies dormant since then. The current way is just too brittleâ¦
And we added more complexity to it.
The point is that the integration process is not automated. It might be more complex now, but that's how far we can get with INRIA infrastructure. So the only thing we can do, since we will never have direct access to the file server, and I think this is better that way, is to automate the integration process as much as possible.
Yes of course. Now if the loader pop ups a stupid dialog in the middle then you get into trouble and previously the solution was based on manual actions. Now we can automate it too. So my change is a progress in the right direction. And it does not have any impact on other people: only help me, marcus and esteban.
As I said, we wrote a UI with ben together 2 years ago that does the whole integration without relying one some written specification.
which written specification are you talking about? Ah you mean a class comment. I can easily remove it if it hurts you :).
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. Now without my change, you can try to load a package on the server in headless mode with a dirty package and you will see that it will not work. 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.
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. I do not understand why it is not in the pharo-update folder 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. Pharo 3.0 Update Files ====================== This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/). Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process. Stef
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.
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
On 2013-10-21, at 22:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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)
I still didn't get what went exactly wrong with the updates. Maybe you can explain the steps you did, so we can prevent such kind of faulty updates in the future. For retracting files you need access to files.pharo.org.
On Oct 21, 2013, at 10:56 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-21, at 22:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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)
I still didn't get what went exactly wrong with the updates. Maybe you can explain the steps you did, so we can prevent such kind of faulty updates in the future.
really simple I commited a package on top of its previous dirty version. graphics was dirty and I save it again to get everything clean now there was a pop up "you will lostâ¦." proceed/cancelâ¦. So I do not understand why it did not fail on the server. Marcus was doing some magic manually to handle this case. Now with my changes we will not have the pop up anymore.
For retracting files you need access to files.pharo.org.
This is what should be written in the readme. Stef
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file? Otherwise you will run into exactly the same trouble the next time...
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart. Stef
Otherwise you will run into exactly the same trouble the next time...
(i am not fully understood what happens there, but here some thought which might be useful). About that popup: - if its a warning, then you can see it in interactive mode. in headless mode all warnings are ignored and program just continues to run. This is equivalent as if user pressed 'proceed' when he sees warning. If you don't want to proceed at such point, then you should throw an error instead of warning, then in headless mode the process abort and quit, and as result, integration will fail. And of course, you can do even smarter things like: Smalltalk isInteractive ifTrue: [ self showWarning ] ifFalse: [ self throwError ]. -- Best regards, Igor Stasenko.
On Oct 23, 2013, at 2:11 PM, Igor Stasenko <siguctua@gmail.com> wrote:
(i am not fully understood what happens there, but here some thought which might be useful).
thanks this is simple. Merging a dirty package always ask the user if it wants to proceed. Now I catch the exception and proceed. Integrators at this stage should know what they are doing. Stef
About that popup: - if its a warning, then you can see it in interactive mode. in headless mode all warnings are ignored and program just continues to run. This is equivalent as if user pressed 'proceed' when he sees warning.
If you don't want to proceed at such point, then you should throw an error instead of warning, then in headless mode the process abort and quit, and as result, integration will fail.
And of course, you can do even smarter things like:
Smalltalk isInteractive ifTrue: [ self showWarning ] ifFalse: [ self throwError ].
-- Best regards, Igor Stasenko.
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
On 2013-10-23, at 16:06, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
Just to get something straight here: You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around). Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't. So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!
Everybody does a lot of work for Pharo, visible and invisible. We are complementary and we need each other - so we have to work together. On 23 Oct 2013, at 18:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 16:06, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
Just to get something straight here:
You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around).
Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't.
So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!
Especially when nobody is running wild and screaming. If this would be case you would hear me from ghent ;D . I'm quite good at that but I decided that I'm in positive energy mode since a long time and that pushy people do not touch me anymore. I'm like Luffy , elastic :) Stef
Everybody does a lot of work for Pharo, visible and invisible. We are complementary and we need each other - so we have to work together.
On 23 Oct 2013, at 18:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 16:06, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
Just to get something straight here:
You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around).
Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't.
So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!
Things got updated: The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has now a version number check + the recent pharo version allows the #update command line handler to detect if wrong update files were specified. Together with Stef's fix to always merge updates the update process should now be more stable. On 2013-10-23, at 20:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Everybody does a lot of work for Pharo, visible and invisible. We are complementary and we need each other - so we have to work together.
On 23 Oct 2013, at 18:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 16:06, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
Just to get something straight here:
You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around).
Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't.
So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!
On Oct 27, 2013, at 6:18 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
Things got updated:
The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has now a version number check + the recent pharo version allows the #update command line handler to detect if wrong update files were specified. Together with Stef's fix to always merge updates the update process should now be more stable. Tx camillo.
Pay attention that my change is to ignore conflict warning so it puts more responsibility on the integrators but ease the production of clean packages after complex merge. Stef
On 2013-10-23, at 20:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Everybody does a lot of work for Pharo, visible and invisible. We are complementary and we need each other - so we have to work together.
On 23 Oct 2013, at 18:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 16:06, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 23, 2013, at 10:52 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 10:44, Camillo Bruni <camillobruni@gmail.com> wrote:
For retracting files you need access to files.pharo.org.
This is what should be written in the readme.
BTW have you tried that you actually have access to the machine? Because I remember that it didn't work for you nor Esteban...
So stef, did you check that you can actually edit the file?
I cannot access it but I least I know that I should not look for it. And next time if there is a problem I just stop integrated and continue hacking on my cool stuff and look smart.
Why can't you access it? What do you want instead? How do we avoid this situation in the future? (happened already before a couple of times)
Just to get something straight here:
You have hardly something to complain... What you see is the tip of the iceberg. I spend roughly 1-2 hours per week maintaining all the jenkins instances with all the slaves and all the jobs that run (and there is Christoph to, regularly fixing and tweaking things all around).
Now running around wild and screaming that everything does not work and is not documented is highly demotivating. Marcus and Esteban work on it on a daily basis. If maintaining jenkins were so much fun, you would do it, but you don't.
So enjoy, and focus on the things you are truly great at: motivating people for a better pharo!
On 2013-10-27, at 20:23, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 27, 2013, at 6:18 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
Things got updated:
The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has now a version number check + the recent pharo version allows the #update command line handler to detect if wrong update files were specified. Together with Stef's fix to always merge updates the update process should now be more stable. Tx camillo.
Pay attention that my change is to ignore conflict warning
I am not fully sure about that, since there are two steps required: 1. MCMergeOrLoadWarning 2. MergeResolutionRequest
From what I got, you only deal with the first one, which asks the user if he wants to merge or not (which for instance in git never happens). The second one actually does the merging. I am pretty much convinced that we don't need the two of them, since I see that we basically spread the following code all over the place:
[aLoadBlock on: MCMergeOrLoadWarning do: [ :request | request merge ]] on: MCMergeResolutionRequest do: [ :request | request autoMerge ]. The real merge conflict is only available in the MCMergeResolutionRequest, before it is a warning that is solely based on whether a package is dirty or not, a very crude approximation of a conflict...
Things got updated:
The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has now a version number check + the recent pharo version allows the #update command line handler to detect if wrong update files were specified. Together with Stef's fix to always merge updates the update process should now be more stable. Tx camillo.
Pay attention that my change is to ignore conflict warning
I am not fully sure about that, since there are two steps required: 1. MCMergeOrLoadWarning 2. MergeResolutionRequest
From what I got, you only deal with the first one,
indeed so this is even better :)
which asks the user if he wants to merge or not (which for instance in git never happens). The second one actually does the merging. I am pretty much convinced that we don't need the two of them, since I see that we basically spread the following code all over the place:
[aLoadBlock on: MCMergeOrLoadWarning do: [ :request | request merge ]] on: MCMergeResolutionRequest do: [ :request | request autoMerge ].
The real merge conflict is only available in the MCMergeResolutionRequest, before it is a warning that is solely based on whether a package is dirty or not, a very crude approximation of a conflict...
On Oct 21, 2013, at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed but instead of getting on your favorite topic, tell me where is the update.list?
on the server files.pharo.org
I do not understand why it is not in the pharo-update folder
because it is generated on the server and to have it in git would mean to have git installed on the server and check it in. We found that too complex and instead treat the updates.list as a cache that is just generated on the server The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory. So and *accessing* files.pharo.org to edit the file is sadly compacted, but that is because Inria admins can't give us anything else. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list (yes, and then this is not in unix line endings⦠so editing is a pain) yes, this all sucks. But what are the options? Doing nothing until it is beautiful and perfect? Marcus
On Oct 22, 2013, at 12:01 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Oct 21, 2013, at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed but instead of getting on your favorite topic, tell me where is the update.list?
on the server files.pharo.org
I do not understand why it is not in the pharo-update folder
because it is generated on the server and to have it in git would mean to have git installed on the server and check it in.
We found that too complex and instead treat the updates.list as a cache that is just generated on the server
The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory.
So and *accessing* files.pharo.org to edit the file is sadly compacted,
complicated (how does one turn off this thing that makes perfectly parsable typos into completely wrong words making people look like idiots?)
On Oct 22, 2013, at 12:00 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Oct 21, 2013, at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Indeed but instead of getting on your favorite topic, tell me where is the update.list?
on the server files.pharo.org
I do not understand why it is not in the pharo-update folder
because it is generated on the server and to have it in git would mean to have git installed on the server and check it in.
We found that too complex and instead treat the updates.list as a cache that is just generated on the server
The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory.
So and *accessing* files.pharo.org to edit the file is sadly compacted, but that is because Inria admins can't give us anything else.
ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list
(yes, and then this is not in unix line endings⦠so editing is a pain)
yes, this all sucks. But what are the options? Doing nothing until it is beautiful and perfect?
No add this info to the readme I added it because I do not have enough braincell to remember all these details.
Pharo 3.0 Update Files ====================== This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/). Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process. The update30.list file is generated on the server and in case of emergency this is the way to modify it. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list Good luck because you should not need it at all.
I changed the readme to be Pharo 3.0 Update Files ====================== This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/). Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process. Here is a bit of an explanation of how the staged and update.list are merged: this is the script of the jenkins job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/ ./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." The update30.list file is generated on the server and in case of emergency this is the way to modify it. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list Good luck because you should not need it at all.
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens. On 2013-10-22, at 08:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I changed the readme to be
Pharo 3.0 Update Files ======================
This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/).
Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process.
Here is a bit of an explanation of how the staged and update.list are merged: this is the script of the jenkins job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/
./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."
The update30.list file is generated on the server and in case of emergency this is the way to modify it.
ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list
Good luck because you should not need it at all.
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you? Stef
On 2013-10-22, at 08:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I changed the readme to be
Pharo 3.0 Update Files ======================
This repository contains a collection of the updates files used for the system-updates of Pharo 3.0. The files are made available on the [file server](http://files.pharo.org/updates/pharo3.0/). The [updates30.list](updates30.list) is contains a list of all update files and is generated by a [jenkins job](https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/).
Do not touch these files manually if you do not know what you are doing. Read the class comments of the `ScriptLoader` class for a complete description of the Pharo integration process.
Here is a bit of an explanation of how the staged and update.list are merged: this is the script of the jenkins job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/
./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."
The update30.list file is generated on the server and in case of emergency this is the way to modify it.
ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list
Good luck because you should not need it at all.
On 2013-10-23, at 13:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you?
well respect at least markdown and make it look properly formatted...
On 2013-10-23, at 15:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you?
well respect at least markdown and make it look properly formatted...
Can you PLEASE take some minutes to make this look properly? https://github.com/pharo-project/pharo-update/blob/30/README.md
On 23 oct. 2013, at 15:58, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 15:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you?
well respect at least markdown and make it look properly formatted...
Can you PLEASE take some minutes to make this look properly?
https://github.com/pharo-project/pharo-update/blob/30/README.md
done
did you push ? I do not see any change :( Ben On 23 Oct 2013, at 16:24, Camille Teruel <camille.teruel@gmail.com> wrote:
On 23 oct. 2013, at 15:58, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 15:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you?
well respect at least markdown and make it look properly formatted...
Can you PLEASE take some minutes to make this look properly?
https://github.com/pharo-project/pharo-update/blob/30/README.md
done
On 23 oct. 2013, at 16:29, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
did you push ?
Yes
I do not see any change :(
I just enclosed the script. That's how I interpreted the request for formatting.
Ben
On 23 Oct 2013, at 16:24, Camille Teruel <camille.teruel@gmail.com> wrote:
On 23 oct. 2013, at 15:58, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 15:53, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-23, at 13:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 22, 2013, at 9:34 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I'll remove the script again, this is silly duplication that is going to be outdated very quickly. It points already to the jenkins job, this is where everything happens.
so I will readd it. Camillo can you respect people that do not think like you?
well respect at least markdown and make it look properly formatted...
Can you PLEASE take some minutes to make this look properly?
https://github.com/pharo-project/pharo-update/blob/30/README.md
done
On 2013-10-23, at 16:44, Camille Teruel <camille.teruel@gmail.com> wrote:
On 23 oct. 2013, at 16:29, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
did you push ?
Yes
I do not see any change :(
I just enclosed the script. That's how I interpreted the request for formatting.
thanks!
participants (8)
-
Benjamin -
btc＠openinworld.com -
Camille Teruel -
Camillo Bruni -
Igor Stasenko -
Marcus Denker -
Stéphane Ducasse -
Sven Van Caekenberghe