Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Helios retrospective.

I think one way to improve this is to allow or encourage projects to contribute early "candidates to the staging area with the understanding that their contribution could change up to their projects release date for the milestone (+0, +1, +2, +3). This way we could allow for the early testing you are describing.

Tom



Inactive hide details for Christian Campo ---06/23/2010 08:42:50 AM---So I guess to caught me on the wrong foot since I am unawChristian Campo ---06/23/2010 08:42:50 AM---So I guess to caught me on the wrong foot since I am unaware off all qualifier stuff that you do with integration and nightly b


From:

Christian Campo <christian.campo@xxxxxxxxxxxx>

To:

Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>

Date:

06/23/2010 08:42 AM

Subject:

Re: [rt-pmc] Helios retrospective.




So I guess to caught me on the wrong foot since I am unaware off all qualifier stuff that you do with integration and nightly builds.

The important part is that I am not talking about the equinox repo but about a composite repo of all release train projects. So too me (and maybe I am naive here) that is what the helios Aggregator build on hudson on build.eclipse.org creates. Its true that that not all projects promote their nightly builds to that aggregator and they dont need to. But too me it would be helpful if I either update my own update site say on the way from milestone M5 to M6 and see if the latest Riena with the Eclipse IDE nightly build now installs correctly. For that its important that I have a composite repo with everything (including a new version of Riena).

And it would be helpful if I could update my project (or tell another project to update its content) and see the result in a composite repo and see if it resolves all the dependencies correctly. This is nothing that can easily reproduce on my own computer.

Maybe that is a problem only of downstream projects > +0 like projects consuming equinox, eclipse RCP. I think its pretty specific to EclipseRT for everything that gets installed into the target platform.

Maybe I am confusing everybody now. But all I am saying is that getting the composite repo right is not easy and while we have many nightly builds that we can test against and download (like the SDKs) there only a few shots to the get the composite repo right.......

- christian

Am 23.06.2010 um 15:20 schrieb Thomas Watson:
      On your second point, I completely agree. Hopefully now that David has a set of tools established we can run them much earlier than they were this year.

      On the first point, I know the eclipse/equinox projects do produce repos for each nightly build. The issues we run into is if you are trying to upgrade from a nightly build to an integration build it does not work (we also cannot have nightly builds and integration builds in the same repository). The reason is our version qualifiers between the nightly and integration builds do not increment in the same way. So to p2 a qualifier from a nightly build may not sort correctly with respect to versions from an integration build. I just want to make sure you are suggesting a completely separate repository that could be used for nightly build input. Users of such a repository could use any other "integration" or "production" repository that may contain "real" versions of the bundles with their expected and tagged qualifiers.

      Tom



      <graycol.gif>
      Christian Campo ---06/23/2010 07:59:18 AM---I think what I am saying is that there is a "real life" for consumers of train projects and the train projects themselves. The
      <ecblank.gif>
      From:
      <ecblank.gif>
      Christian Campo <christian.campo@xxxxxxxxxxxx>
      <ecblank.gif>
      To:
      <ecblank.gif>
      Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>
      <ecblank.gif>
      Date:
      <ecblank.gif>
      06/23/2010 07:59 AM
      <ecblank.gif>
      Subject:
      <ecblank.gif>
      Re: [rt-pmc] Helios retrospective.




      I think what I am saying is that there is a "real life" for consumers of train projects and the train projects themselves. The consumers need all the things like multiple versions in "the repo". The train projects download nightly builds from the Eclipse SDK. So they also need an equivalent in the repo space which would be nightly repos or repos on demand in specific cases.....


      christian


      Am 23.06.2010 um 14:48 schrieb Jeff McAffer:
              Great feedback. I agree that having repos available early and often is very beneficial. Having the repo for each build is useful from time to time but in the end our repos are going to have multiple versions in them (think SR1 and SR2) so working with M5, M6, ... is more representative of real life. Without that we would not have found the problems and would be suffering them in Sept...

              Jeff


              On 2010-06-23, at 7:54 AM, Christian Campo wrote:
                      Hi Tom,


                      I have a few things........


                      1) I and a number of other people got hit by the problem, how p2 resolves dependencies from a composite repository. Would it pick RAP or RCP ? What is the correct use of greedy=false and so on. It turned out that we would only test that on each milestone. It also turns out that the Helios composite repository for some time consolidated the bundles of the multiple milestones. So you could find i.e. Riena for M5, M6 and RC1 in the Helios repo at some time which made it even hard to test to find errors and problems.


                      I talked to David about it and it turns out there is actually a complete new Helios composite repo created when the Helios Aggregator Job is run successfully only that this composite Repo doesnt get promoted to become a public URL. He did that once for me and it seems it was only a small step for him and very helpful for me.


                      So i suggest for the future that we have such a nightly repo of the release train components in future releases since it make integration of several project components so much easier to test. That was really sometimes hard in Helios and also "wait for M6 maybe it works there" "nope not yet, we have to do this, maybe it works in M7".


                      I am not saying it should replace the existing repo but it should either be addressable (in the URL) by date or buildnumber (of the HeliosAggregator) or something.....


                      2) A small thing is that David seems to have these wonderful tools to test compliance of the individual bundles with release train rules (signed, pack200, about.html SUV etc.). I like to see them run earlier (starting at RC1) and not in the final build week at +0. I felt this was way too late.....


                      Other than that it went really well and I wouldnt have survived without the help of David every now and then (often in the middle of the night) thanks a lot for that :-)


                      - christian


                      Am 22.06.2010 um 20:09 schrieb Thomas Watson:

                              On the agenda for the planning council July 7th meeting is to spend some time retrospecting about the Helios release ... what went well, what could have been better.

                              As members of the RT PMC and project leads we should go back to the projects we represent and do some retrospecting ourselves. If the teams you represent participated in the Helios release then please meet with your individual teams for a retrospective on the release. Provide me with any items, what could have been better, what went well etc. that you want me to bring forward to the planning council's retrospective meeting.

                              Thanks and let me know if you have any questions.

                              Tom

                              <ATT00001..c>



                      -------------------------------------------------------------
                      compeople AG
                      Untermainanlage 8
                      60329 Frankfurt/Main
                      fon: +49 (0) 69 / 27 22 18 0
                      fax: +49 (0) 69 / 27 22 18 22
                      web:
                      www.compeople.de

                      Vorstand: Jürgen Wiesmaier
                      Aufsichtsratsvorsitzender: Christian Glanz

                      Sitz der Gesellschaft: Frankfurt/Main
                      Handelsregister Frankfurt HRB 56759
                      Ust-Ident.-Nr: DE207665352
                      -------------------------------------------------------------

                      _______________________________________________
                      rt-pmc mailing list

                      rt-pmc@xxxxxxxxxxx
                      https://dev.eclipse.org/mailman/listinfo/rt-pmc

              <ATT00001..c>
      _______________________________________________
      rt-pmc mailing list

      rt-pmc@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/rt-pmc


      <ATT00001..c>
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc


GIF image

GIF image


Back to the top