>Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ
seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the release of 1.3? Providing these builds might lead to people using them, and in commercial development we mostly use released versions to base on. Within much time are we expected to migrate after a new release? Stephan Eggermont |
On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote: >> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ > > seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the > release of 1.3? We did it with 1.1... the problem is that the build server is getting really full if we keep everything. And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged), does that make sense? We can keep it if people need... but this time we switch servers in addition, so links will change anyway. > Providing these builds might lead to people using them, and in commercial > development we mostly use released versions to base on. Within much time are we expected to migrate after > a new release? > Nobody removed the release from the archive... just the build server. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
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.
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]] Sent: Wednesday, June 29, 2011 9:37 AM To: [hidden email] Subject: Re: [Pharo-project] Silly tweet On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote: >> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ > > seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the > release of 1.3? We did it with 1.1... the problem is that the build server is getting really full if we keep everything. And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged), does that make sense? We can keep it if people need... but this time we switch servers in addition, so links will change anyway. > Providing these builds might lead to people using them, and in commercial > development we mostly use released versions to base on. Within much time are we expected to migrate after > a new release? > Nobody removed the release from the archive... just the build server. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
On 29 June 2011 15:56, Schwab,Wilhelm K <[hidden email]> 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. > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]] > Sent: Wednesday, June 29, 2011 9:37 AM > To: [hidden email] > Subject: Re: [Pharo-project] Silly tweet > > On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote: > >>> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ >> >> seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the >> release of 1.3? > > We did it with 1.1... the problem is that the build server is getting really full if we keep everything. > And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged), > does that make sense? > > We can keep it if people need... but this time we switch servers in addition, so links will change anyway. > >> Providing these builds might lead to people using them, and in commercial >> development we mostly use released versions to base on. Within much time are we expected to migrate after >> a new release? >> > > Nobody removed the release from the archive... just the build server. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Stephan Eggermont-3
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. Stephan Eggermont |
On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> 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. > That's fine. > > Stephan Eggermont -- Best regards, Igor Stasenko AKA sig. |
Does this imply that older versions are not maintained (e.g. with
1.2.n or 1.3.n releases) which include important bug fixes. It seems so and from a practical point of view there is probably no way around it.... --Hannes On 6/29/11, Igor Stasenko <[hidden email]> wrote: > On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> 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. > > > >> That's fine. >> >> Stephan Eggermont > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
In reply to this post by Igor Stasenko
+1 to Sig's answer. Old builds are great, and we should (and do) keep them around, but they do not need to be on the CI server. As Sig said, the old versions don't change, so CI gets pretty boring.
The old versions are available from an archive (https://gforge.inria.fr/frs/?group_id=1299). See the "file server" link on the downloads page. ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]] Sent: Wednesday, June 29, 2011 6:16 PM To: [hidden email] Subject: Re: [Pharo-project] Silly Tweet On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> 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. > That's fine. > > Stephan Eggermont -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Hannes Hirzel
There are 1.1.1 and 1.2.1 releases. What I do not know is how, for example, 1.2.1 compares with the 1.2 on the CI server??
Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of H. Hirzel [[hidden email]] Sent: Wednesday, June 29, 2011 6:23 PM To: [hidden email] Subject: Re: [Pharo-project] Silly Tweet Does this imply that older versions are not maintained (e.g. with 1.2.n or 1.3.n releases) which include important bug fixes. It seems so and from a practical point of view there is probably no way around it.... --Hannes On 6/29/11, Igor Stasenko <[hidden email]> wrote: > On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> 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. > > > >> That's fine. >> >> Stephan Eggermont > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
In reply to this post by Schwab,Wilhelm K
On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote:
> +1 to Sig's answer. Old builds are great, and we should (and do) > keep them around, but they do not need to be on the CI server. As > Sig said, the old versions don't change, so CI gets pretty boring. There is the option to disable the build job, so that no further builds take place (until there are maintenance releases to build). There is also the option to use the CI server as the build archive as well. You can mark some build numbers as "never remove". Normally, only the last N builds are kept, and the oldest is deleted after the new build completes (unless that oldest build is the last successful build, then it's kept until the next successful build). Whichever builds are marked "never remove" would form the archive. That would eliminate the apparent confusion caused by having the archive at https://gforge.inria.fr/frs/?group_id=1299 The other factor is that a transition to Jenkins from Hudson is happening, which is driving the desire to drop the Hudson based 1.2 builds. |
On 30 June 2011 03:30, Yanni Chiu <[hidden email]> wrote:
> On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote: >> >> +1 to Sig's answer. Old builds are great, and we should (and do) >> keep them around, but they do not need to be on the CI server. As >> Sig said, the old versions don't change, so CI gets pretty boring. > > There is the option to disable the build job, so that no further builds take > place (until there are maintenance releases to build). > > There is also the option to use the CI server as the build archive as well. > You can mark some build numbers as "never remove". Normally, only the last N > builds are kept, and the oldest is deleted after the new build completes > (unless that oldest build is the last successful build, then it's kept until > the next successful build). Whichever builds are marked "never remove" would > form the archive. That would eliminate the apparent confusion caused by > having the archive at https://gforge.inria.fr/frs/?group_id=1299 > > The other factor is that a transition to Jenkins from Hudson is happening, > which is driving the desire to drop the Hudson based 1.2 builds. > 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. -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Yanni Chiu
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. |
In reply to this post by Stephan Eggermont-3
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 > > > > |
In reply to this post by Igor Stasenko
On Thu, Jun 30, 2011 at 12:16 AM, Igor Stasenko <[hidden email]> 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.
-- Mariano http://marianopeck.wordpress.com |
In reply to this post by Stéphane Ducasse
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 <[hidden email]> 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 >> >> >> >> > > > |
In reply to this post by Stéphane Ducasse
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. |
In reply to this post by Igor Stasenko
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. |
In reply to this post by Stephan Eggermont-3
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 |
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. > 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 > > > > |
In reply to this post by Marcus Denker-4
On Jun 30, 2011, at 10:15 , Marcus Denker wrote: > 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... Exactly. When you have systems of the size >1000 classes that have been grown over years and have to work reliably, just "updating a couple of classes [sic] references and uses" is not easy. First of all, you have to figure out *what* to change. Changes like a modified Dictionary/Set hierarchy can subtly break your code (leading to data corruption in our case [1]). Or, just because you are one of the first to use the new code under high load, you see problems others haven't seen before (leading to unresponsive images in our case [2]). Those are obvious external bugs, but we also ran into issues with our code just not being compatible anymore with new semantics (e.g., Number class>>#readFrom:). That's why in a non-trivial setup, upgrading is costly, and at times painful (in particular when you missed problems in testing and then experience them in production). [1] http://code.google.com/p/pharo/issues/detail?id=3658 [2] http://code.google.com/p/pharo/issues/detail?id=3498 Cheers, Adrian |
Free forum by Nabble | Edit this page |