[
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
|
Really, I just changed the one line in my target file and checked it in for all my builds. I love Tycho for that :)
________________________________________
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 10:29 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: 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
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
