June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Silly Tweet

by Norbert Hartl

Am 30.06.2011 um 10:32 schrieb Stephan Eggermont: > Stef wrote in response to my: >>> Ok, so you simply do not want the builds to be used by others. >>> That's fine. > >> why do you say that? > > Such a build server can have two purposes: > - to directly help with the development of the software named in the build jobs; > - it can provide a starting point for others to base their work on. > > Both are valuable, and it is acceptable if you want to want to focus on the first. > For the second, as a commercial developer I have to be able to make my upgrade > schedule as independent as possible from that of the projects I depend on. > Depending on artifacts with an unknown availability is not possible. > Exactly. And that is the reason why it will be very hard not to have your own CI server. The official distribution will rarely match your requirements. We all patch packages here and there. That you can only deal with in your own setting. All CI servers that I know (most of big development teams) face sooner or later the same thing. You might think disk space is endless or CPU but it is not. I don't know any bigger CI server that still builds all commits. It is just not possible because CPU and disk space isn't there enough. From that angle it is even more important to remove the things that aren't really needed. I think you are actually looking for a reliable download location and the CI server is the wrong place for it. That's why there are last successful builds. The can be copied to a download server and rest forever. my 2 cents, Norbert >> What is the point to have a build server build all the time the same same same same same >> same same image? > > A build server is used as we've learned there is no such thing as the same same image. > There have been regressions because of vm changes or operating system updates, > and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside > change. > > Stephan > > > >

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Stephan Eggermont

Stef wrote in response to my: >> Ok, so you simply do not want the builds to be used by others. >>That's fine. >why do you say that? Such a build server can have two purposes: - to directly help with the development of the software named in the build jobs; - it can provide a starting point for others to base their work on. Both are valuable, and it is acceptable if you want to want to focus on the first. For the second, as a commercial developer I have to be able to make my upgrade schedule as independent as possible from that of the projects I depend on. Depending on artifacts with an unknown availability is not possible. >What is the point to have a build server build all the time the same same same same same >same same image? A build server is used as we've learned there is no such thing as the same same image. There have been regressions because of vm changes or operating system updates, and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside change. Stephan

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Marcus Denker

On Jun 30, 2011, at 9:53 AM, Mariano Martinez Peck wrote: > > What I understood is that there could be activity and changes not in pharo, but in the other project that is build/tested in Pharo. > Say I am still quite developing Fuel, and I am commiting every day. No matter if it is on Pharo 1.2 or 1.3 what I want to say is that there is activity. > Ok, the resources let us to that with the latest Pharo, so that we can test both at the same time: pharo itself and the third party. > If you want third part with old pharo images, then you should get your own IC server. > It would be nice to have CI infrastructure available for everyone to just use. But this can not be me who edits text files by hand for such a service... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Marcus Denker

On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote: > Why do people still use an older image? Even as older as Pharo1.1 and 1.2. > > It doesn't take much to update to Pharo1.3 or Pharo1.4, and its > totally worth the nuisance of updating a couple of classes references > and uses, because of the many many many improvements that get > integrated ( thanks for Marcus and Stef for the continuos improvements > integration and fixes) In a commercial setting, things are different... people need to really think hard to move to a new system. Time is money, bugs are expensive, there is always a deadline more important... One thing we want to do with Pharo over the next years is to actually make it easy to stay at an old version. And easy to gradually move to new versions. It's an interesting question how a language and system can support software evolution *for real*. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Fernando Olivero

Why do people still use an older image? Even as older as Pharo1.1 and 1.2. It doesn't take much to update to Pharo1.3 or Pharo1.4, and its totally worth the nuisance of updating a couple of classes references and uses, because of the many many many improvements that get integrated ( thanks for Marcus and Stef for the continuos improvements integration and fixes) Fernando On Thu, Jun 30, 2011 at 9:10 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 29, 2011, at 11:12 PM, Stephan Eggermont wrote: > >> Igor wrote: >>> On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server. Â Sounds great. >>> >>> Indeed. If people would like to use older releases, they should look >>> for another place, not for build server. >>> Since build server are there to build & test bleeding-edge (under >>> development) versions, but not ones which already released and years >>> old. >> >> Ok, so you simply do not want the builds to be used by others. >> That's fine. > > why do you say that? > > What is the point to have a build server build all the time the same same same same same > same same image? > > For the sake of it? > > Stef > >> >> Stephan Eggermont >> >> >> >> > > >

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Mariano Martinez Peck

On Thu, Jun 30, 2011 at 12:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 June 2011 00:12, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Igor wrote: > >>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: > >>> Having an archive seems sufficient - those who need old versions for > use or research can get them; they don't have to be clogging up the build > server. Sounds great. > >> > >>Indeed. If people would like to use older releases, they should look > >>for another place, not for build server. > >>Since build server are there to build & test bleeding-edge (under > >>development) versions, but not ones which already released and years > >>old. > > > > Ok, so you simply do not want the builds to be used by others. > > Its not about that we don't want users to download older versions > (they are available for download at pharo official site). > > No. Builds purpose is to follow a development process: new update -> new > build. > Now since we're done with 1.2 (and even almost done with 1.3) there > will be no new versions for these lines, > since all development is now in 1.4. > So, there is no reason to keep jobs for 1.2 and then 1.3 on build > server, because there will be no activity around it. > > What I understood is that there could be activity and changes not in pharo, but in the other project that is build/tested in Pharo. Say I am still quite developing Fuel, and I am commiting every day. No matter if it is on Pharo 1.2 or 1.3 what I want to say is that there is activity. Ok, the resources let us to that with the latest Pharo, so that we can test both at the same time: pharo itself and the third party. If you want third part with old pharo images, then you should get your own IC server. > > > > That's fine. > > > > Stephan Eggermont > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

June 30, 2011

Re: [Pharo-project] Silly Tweet

by StÃ©phane Ducasse

On Jun 29, 2011, at 11:12 PM, Stephan Eggermont wrote: > Igor wrote: >> On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server. Sounds great. >> >> Indeed. If people would like to use older releases, they should look >> for another place, not for build server. >> Since build server are there to build & test bleeding-edge (under >> development) versions, but not ones which already released and years >> old. > > Ok, so you simply do not want the builds to be used by others. > That's fine. why do you say that? What is the point to have a build server build all the time the same same same same same same same image? For the sake of it? Stef > > Stephan Eggermont > > > >

June 30, 2011

[Pharo-project] [update 1.4] #14021

by Marcus Denker

14021 ----- Issue 4474: DNU when displaying search results in Comments http://code.google.com/p/pharo/issues/detail?id=4474 Issue 4473: About HTTP proxies, settings and MacOS http://code.google.com/p/pharo/issues/detail?id=4473 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 30, 2011

Re: [Pharo-project] missing packages in Pharo14 repository

by Marcus Denker

On Jun 29, 2011, at 10:45 PM, Pavel Krivanek wrote: > Hi Marcus, > > I guess you are aware of this. I looked at Undeclared in the reloaded > Core and I found out that one method that makes it is different in the > latest Pharo 1.4 and belongs to newer version of the package > (Settings-System v.17). This version is not present in the Pharo > repository but what is more interesting - it is not present also in > the Pharo14 repository. > Oh, I will fix... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Marcus Denker

On Jun 30, 2011, at 3:06 AM, Igor Stasenko wrote: > > Another aspect of it, that build servers has a limited space (Marcus > has to cut the number of builds , since they taking too much space). > While on gforge we can afford to keep much more. > Of course keeping latest 'frozen' build doesn't takes too much , > except of a little nuisiance after a couple of years > every time you open a jenkins, you will see a very long list of jobs, > where only few of them actually needed. > That's why i thinking that moving things to archive is preferable. > > In any way, i think everyone understands that nobody wants to hide > existing versions from public eyes. > Its only a question of finding appropriate place for them, after > development is done. Yes... we can keep 1.2 a bit. But what I don't want to keep are builds *on top* of 1.2. (the only left now is AIDA, but I removed already some). The amount of project on the build server is already very high: https://pharo-ic.lille.inria.fr/hudson/ and that with almost all 1.2 clients deleted and stuff moved to Jenkins: https://ci.lille.inria.fr/pharo/ But it's fun how something is seen as indespensable that we did not have some month ago (and that some people thought is not important *and* in the Squeak past even actively blocked from happening). How times change... ;-) What this shows is that what Jenkins/Hudson provide is essential, and we should think about to move that somehow deeper into our language... (nice research topic) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 30, 2011