Update:
I’m now able to successfully run the packaging CI steps on a local Ubuntu
16.04 x86_64 setup, passing all the same tests that run on the official
packaging CI bots. I think we’re literally down to just needing to get the
machines procured, configured and put into the Swift CI pool.
-Todd
On Jun 22, 2016, at 1:07 PM, Todd Fiala <tfiala@apple.com> wrote:
On Jun 22, 2016, at 12:49 PM, Brian Gesiak via swift-lldb-dev < > swift-lldb-dev@swift.org> wrote:
Thanks for raising this discussion, Todd!
Hi Brian,
You must be on my brain wave-length. Now that WWDC is behind us, I just
raised the Ubuntu 16.04 migration process early this morning. Expect to
hear more about this soon once we work out some logistics.
Any input from the core team here? The Swift Android build doesn't
currently work for Ubuntu 14; see https://bugs.swift.org/browse/SR-1321\.
I'd like to know whether I should prioritize fixing this, or whether I
should focus on getting the build ready for Ubuntu 16.
- Brian Gesiak
Well, getting it working for Ubuntu 14.04 is probably still worth it since
we are currently supporting it, and plan to support it until we swap it out
for Ubuntu 16.10 sometime after the October Ubuntu release. There is
probably a good 5 - 6 months of coverage left on Swift Ubuntu 14.04 CI.
Does that help?
-Todd
On Tue, Apr 26, 2016 at 10:57 AM, Todd Fiala via swift-dev < > swift-dev@swift.org> wrote:
Thanks, Ryan. Yes, the intent was to harmonize with the Ubuntu release
philosophy.
I haven’t heard any opposition to this plan. I’m going to move forward
with resourcing and executing on this plan. More communication to follow
once those details are worked out.
Thanks, all!
Sincerely,
Todd Fiala
On Apr 26, 2016, at 6:24 AM, Ryan Lovelett via swift-lldb-dev < >> swift-lldb-dev@swift.org> wrote:
On Thu, Apr 21, 2016, at 01:12 PM, Todd Fiala via swift-lldb-dev wrote:
Hi all,
I wanted to propose how we can go about handling newer Ubuntu releases in
a systematic way. This covers how we handle Ubuntu on our CI, but also
reflects where we'll be focusing effort at any given point. The primary
intent is to support the most recent Ubuntu Long Term Service release and
the absolute latest Ubuntu release, with a bit of overlap when phasing out
the LTS release that is going out of scope.
Since the next release, fast moving or not, is the next Long Term
Stability release, Ubuntu 16.04 LTS (available now), I propose we:
* swap out our 15.10 fast moving release with Ubuntu 16.04 LTS.
* allow 16.04 and 14.04 to co-exist to give our stability-minded
community time to switch over to 16.04.
When 16.10 comes out in October 2016, we drop 14.04 and move 16.10 onto
those builders.
This continues to have us testing against the latest release, which will
be Ubuntu 16.04 LTS when we switch, gives us the latest stable coverage
(also 16.04), and gives our community a little more time with active
coverage on 14.04, the previous long term support version. We’ll then get
back to the normal program in October 2016 when we pick up the latest
fast-moving release, with coverage on Ubuntu 16.10 and Ubuntu 16.04 LTS.
This assumes we want to keep our eyes on no more than two Ubuntu releases
at a time, which matches current CI infrastructure planning.
Looking forward over the next two years, this is the schedule I’m
proposing:
- April 2016: Replace Ubuntu 15.10 with Ubuntu 16.04 (coverage:
Ubuntu 14.04, Ubuntu 16.04 LTS)
- October 2016: Replace Ubuntu 14.04 with Ubuntu 16.10 (coverage:
Ubuntu 16.04 LTS, Ubuntu 16.10)
- April 2017: Replace Ubuntu 16.10 with Ubuntu 17.04 (coverage:
Ubuntu 16.04 LTS, Ubuntu 17.04)
- October 2017: Replace Ubuntu 17.04 with Ubuntu 17.10 (coverage:
Ubuntu 16.04 LTS, Ubuntu 17.10)
- April 2018: Replace Ubuntu 17.10 with Ubuntu 18.04 LTS (coverage:
Ubuntu 16.04, Ubuntu 18.04 LTS)
Thoughts? Once we finalize the plan, I'll coordinate with the
infrastructure teams and round up resources needed to get Ubuntu 16.04
supported and on the CI.
This seems to mostly match up with the guidance provided by Canonical and
the community around Ubuntu. Therefore it seems reasonable to me.
I like it. Consider this a vote in favor.
Thanks!
Sincerely,
Todd Fiala
*_______________________________________________*
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev
_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
