Hi Folks,
We are able to build packages for new arches we need to propose a workflow to support a new architecture in a SIG project.
Two use cases :
A/ It's an official architecture. -> Sources *must* build for all enable architecture. SIGs are responsible to fix issues for all arches. -> We provide a script that will rebuild existing arch specific packages (scratch build + merge scratch build) if needed. (Note: In case only newer version of your project supports this arch, this step may be skipped.)
=> "On Monday SIG board decided to enable aarch64, and then all new tasks must build for aarch64."
B/ It's a proposed architecture. -> Some person in a SIG would like to work on add an architecture and do the porting work but SIG would not support it as a first citizen until it gets traction. -> Source will be build on a separate tag (a different disttag will be used) -> We provide a script that rebuild srpm (NV must remain the same as original SIG package) and merge the build when architecture is promoted as an "official architecture".
=> "Work on this architecture support and when ready send a proposal to promote your working port to the SIG board"
I think that supporting the two use cases will benefit the community, and allow less common architectures to be supported faster.
At koji level, these modifications can be done per SIG *project*.
Let us know what you think/expect and your feedback.
Hello Thomas,
On Mon, Apr 25, 2016 at 4:50 PM, Thomas Oulevey thomas.oulevey@cern.ch wrote:
Hi Folks,
We are able to build packages for new arches we need to propose a workflow to support a new architecture in a SIG project.
Two use cases :
A/ It's an official architecture. -> Sources *must* build for all enable architecture. SIGs are responsible to fix issues for all arches. -> We provide a script that will rebuild existing arch specific packages (scratch build + merge scratch build) if needed. (Note: In case only newer version of your project supports this arch, this step may be skipped.)
=> "On Monday SIG board decided to enable aarch64, and then all new tasks must build for aarch64."
B/ It's a proposed architecture. -> Some person in a SIG would like to work on add an architecture and do the porting work but SIG would not support it as a first citizen until it gets traction. -> Source will be build on a separate tag (a different disttag will be used) -> We provide a script that rebuild srpm (NV must remain the same as original SIG package) and merge the build when architecture is promoted as an "official architecture".
=> "Work on this architecture support and when ready send a proposal to promote your working port to the SIG board"
I think that supporting the two use cases will benefit the community, and allow less common architectures to be supported faster.
At koji level, these modifications can be done per SIG *project*.
#2 would be awesome. Both of these would be useful to the Storage SIG - at least the Ceph part.
François
On Mon, Apr 25, 2016 at 4:50 PM, Thomas Oulevey thomas.oulevey@cern.ch wrote:
We are able to build packages for new arches we need to propose a workflow to support a new architecture in a SIG project.
Two use cases :
A/ It's an official architecture. -> Sources *must* build for all enable architecture. SIGs are responsible to fix issues for all arches. -> We provide a script that will rebuild existing arch specific packages (scratch build + merge scratch build) if needed. (Note: In case only newer version of your project supports this arch, this step may be skipped.)
=> "On Monday SIG board decided to enable aarch64, and then all new tasks must build for aarch64."
+1 from me on behalf of the Ceph Storage SIG.
François