TechnicalBoardAgenda
This page records the Agenda for the next meeting of the Ubuntu Technical Board. Please see the Ubuntu Governance page for details on participation.
If you have a question to raise with the Board, you can reach the Technical Board members directly by e-mailing technical-board@lists.ubuntu.com. They may decide that your issue should be discussed at the next meeting, in which case they will add it to this page.
The meeting schedule is available on the fridge calendar. We meet in channel #ubuntu-meeting on chat.freenode.net. The agenda will include the following:
- Next meeting (2010-06-15) chair: cjwatson
- Action review
Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz)
- Selection of the Linaro GCC for other architectures (doko)
Scan the mailing list archive for anything we missed
Check up on community bugs (standing item)
- Select a chair for the next meeting
Summarize the meeting for TeamReports
=== Linaro GCC ==
One outcome of the UDS ARM toolchain sessions was to use the Linaro toolchain to build Ubuntu/ARM. The Linaro GCC currently is a snapshot of the upstream 'gcc-4_4-branch' branch, with the changes found in the CodeSourcery GCC applied on top of it. Changes/patches found in the Ubuntu packaging are applied too.
We currently evaluate the builds of this compiler on armel, and on other architectures which are supported by the CodeSourcery GCC (i386, amd64, powerpc) to see, if the Linaro GCC could be used on other architectures as well. One of the arguments for this use is the outcome of a (partial) archive rebuild which we expect to be done next week, another argument is how the use of a branch, which is not the upstream branch, is perceived by the development community.
Linaro itself is set up to work with upstreams and integrate changes directly with upstreams, so that changes which are accepted by upstream are integrated upstream in the trunks/development versions. However using the Linaro GCC might show different results than using the current upstream GCC branch, which maybe are unexpected and maybe are directly reported to the upstream project as a problem in their GCC versions. For at least ARM we will have another compiler version based on the GCC upstream version in the form of a gcc-4.4-branch package (looking like the current gcc-snapshot) package to provide a way to reproduce problems with the upstream GCC versions.
Developers doing upstream development on Ubuntu may see these differences as well, and wrongly attribute them to the wrong version.
Using a different compiler may move us a bit more away from Debian (although we rebuild packages anyway, and using a compiler with hardening defaults turned on).
I'd like ot have some feedback, if such a move to a different compiler version for architectures other than ARM would be accepted by the TB, provided that the compiler doesn't show regressions, and considering that this compiler change maybe "alienates" Ubuntu a bit more from Debian/GCC upstream.
Logs from previous meetings may be found at http://irclogs.ubuntu.com/ or via MootBot.