Re: [cross-project-issues-dev] Luna RC4 staging repo is complete

[Doug Schaefer <dschaefer@xxxxxxx>]

For what it's worth, I'm testing our internal product builds against releases/staging, and we're fine with that. We've probably spent more time on this thread than it does to change your target to point at it.

Doug.

________________________________________
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Igor Fedorenko [igor@xxxxxxxxxxxxxx]
Sent: Thursday, June 19, 2014 9:28 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete

I don't believe Tycho approach (and Maven/Nexus in general) is a good
role model. I also don't think it applies to symrel process.

As a symrel consumer, I know that d.e.o/releases/<celestial-object> is
the place to get latest published M/RC build towards the next release
and this is what I am told to use throughout yearly release cycle. Few
weeks before the release, however, I need to switch to another
repository to test with the final RC. This is rather surprising (and I
am quite certain I'll forget about this by next May) and requires
non-trivial amount of work on my part because I need to update all my
build scripts and/or CI jobs to use the staging repository.

If you are really concerned about "releasing" final RC to
releases/<celestial-object> couple of weeks earlier, then I think we
need separate stable prerelease repository URL. This is what we do for
m2e, for example. All M and RC builds go to the same
milestones/<version>/ repository and the final RC is promoted to
releases/<version> repo when the release is declared.

Personally, though, I find concerns about "releasing" early quite silly.
To me "release" is purely marketing event. As a developer I write code
and publish builds as they become available. One of the published builds
is later declared a release, but this has little/no impact on my
development workflow.

--
Regards,
Igor

On 2014-06-19, 8:21, David M Williams wrote:
> The reason we don't do that is because that would be the same as
> "releasing it" ... that, and the URL ..../release/luna is "built in" to
> all prior Luna milestones and candidates, so people with "auto update"
> set would all start hitting 'download.eclipse.org' the moment it was
> there, before there was opportunity to mirror.
>
> I think it's very common for many projects (such as Tycho) to be
> available in a "staging" location for a period, before officially moving
> to the "released" location.
>
> Perhaps this FAQ would help?
> http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_way_to_test_with_the_staging_repository.3F
>
>
> Thanks for suggesting ways to improve the process, though.
>
>
>
>
> From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
> To: cross-project-issues-dev@xxxxxxxxxxx,
> Date: 06/19/2014 07:55 AM
> Subject: Re: [cross-project-issues-dev] Luna RC4 staging repo is complete
> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
> ------------------------------------------------------------------------
>
>
>
> Little late to the party, but I'd like to suggest adding RC4 to Luna
> composite and making this part of symrel process going forward. By
> "hiding" RC4 under obscure URL we artificially limit amount of testing
> it gets and make it harder for downstream projects validate their code
> will still work yearly release comes live next week.
>
> --
> Regards,
> Igor
>
> On 2014-06-11, 23:52, David M Williams wrote:
>  > http://download.eclipse.org/releases/staging/
>  >
>  > As I am sure you all know, this is our final aggregation build for Luna,
>  > unless a blocking issue is found.
>  >
>  > I always like to emphasize, that, at this point, a "blocking issue" that
>  > would lead to a re-spin has to be more than a typical "bad problem" for
>  > a one project ... but more along the lines of something that "destroys
>  > all data in a project or workspace" or "prevents installs or updates of
>  > other projects from occurring" or that sort of thing. If you do find a
>  > bad bug that effects just  your project's function, I encourage you to
>  > a) look for and document "work arounds" and/or b) prepare a "project
>  > level patch"  that you could make available by the time we release, so
>  > users can take advantage of it immediately after they install the
>  > release. This is purely for stability reasons ... that is, it is often
>  > better to "ship" with a known bad bug, than to risk fixing one bug and
>  > exposing something even worse (which would be hard to find in time,
>  > since by then little time left for testing). And just so I don't seem
>  > negative ALL the time ... if you sincerely believe you found a bug that
>  > really would be bad for the reputation of Eclipse as a whole, or
>  > something, discuss with your project and PMC and other Eclipse leaders
>  > and if they all believe it worth mentioning here on cross-project list,
>  > then please do. Even if the answer is "no, no re-build", it doesn't hurt
>  > to keep everyone informed.
>  >
>  > Also important for you to know, this "staging" repo is NOT moved to
>  > .../releases/luna on Friday, like we normally do, since that is Friday
>  > the 13th [JUST KIDDING!]. The real reason it just stays on staging is
>  > that would essentially be "pre-releasing" the whole train. Instead we
>  > always have a "quiet week" for final preparations, final adopter testing
>  > and builds, etc., and then formally release it (make visible) on the
>  > long scheduled date of Wednesday, June 25th.
>  >
>  > I will be sending out a "what to do during quiet week" note in the next
>  > day or two (some version of "Kepler Final Daze
>  > <https://wiki.eclipse.org/Kepler/Final_Daze>" document, updated for
> Luna).
>  >
>  > Let us know if questions or issues, by posting here to this
>  > cross-project list.
>  >
>  > And my personal thanks for those final pushes for improvements in "repo
>  > reports <http://build.eclipse.org/simrel/luna/reporeports/>" -- no
>  > missing "about" files, good improvements in unsigned bundles, and some
>  > improvement in making feature licenses (SUA's) current. We'll continue
>  > to work towards perfection for SR1 and Mars!
>  >
>  > Much thanks to you all,
>  >
>  >
>  >
>  > _______________________________________________
>  > cross-project-issues-dev mailing list
>  > cross-project-issues-dev@xxxxxxxxxxx
>  > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>  >
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev