[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Luna RC4 staging repo is complete
|
It will take me couple of hours to switch all my CI jobs from
releases/luna to releases/staging and make sure they still work, and
another couple of hours to switch them back to releases/luna next week.
Not a huge amount of time, but I'd prefer not to have to spend it.
If people are passionate about "release" event, lets publish all M and
RC builds to milestones/<celestial-object> and populate
releases/<celestial-object> only after the release has been declared.
--
Regards,
Igor
On 2014-06-19, 10:02, Doug Schaefer wrote:
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
