Greetings centos-devel! My name is Mike Ruckman and I'm working with the
Fedora Cloud WG helping coordinate testing. There's been some
discussions on IRC regarding Fedora and CentOS working together and I
was asked to send a mail to the list with times and places for some of
our meetings.
Fedora QA
---------
This is the group the Cloud WG has to work with to ensure that things
are tested well enough - they do the final sign off after the WG has
tested it's release items.
They meet Mondays at 1500 UTC in #fedora-meeting on freenode.
Fedora QA Devel
---------------
This group is currently working on taskotron [0] and they maintain all
of our QA applications. The Cloud WG will be working with them on
getting some automated testing in place sometime in the future.
They meet at 1400 UTC in #fedora-meeting-1 on freenode on Mondays.
Fedora Cloud
------------
This one is pretty explanatory. We work on the cloud products for
Fedora. The base image, docker image, atomic host and Vagrant boxes.
We meet on Wednesdays at 1900 UTC in #fedora-meeting on freenode.
There has also been talk of attempting to do a joint test day [1] for
Atomic sometime in September. If there's enough interest, we can start
planning and advertising for it now.
Thanks! Let me know if you have any questions - or find me on irc. I'm
roshi on freenode.
[0] http://fedoraproject.org/wiki/Taskotron
[1] https://fedoraproject.org/wiki/QA/Test_Days
--
// Mike
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
We have a need to be able to generate embargoed content for SIGs. As an
example, Xen publishes embargoed content where we need to apply patches,
build an SRPM and then binary RPMs.
We can not do this in an open build system as the content must be
embargoed until after the release date.
What I think we need is password protected input and builds in the CBS
and password protected repos for the resultant RPMs. We could then
control access to those specific locations via login.
Does the current version of koji support that?
If not, we could create an embargoed build area(s) in the current CentOS
build system, where the output of the build system is not transferred to
buildlogs.centos.org .. but I would also need to point to the proper
repos in the CBS as well.
Who, besides the Xen rpms in the virt SIG might need this embargoed
build capability?
Thanks,
Johnny Hughes
Hi,
It is been an while from last storage SIG meeting [1] . Lets meet
tomorrow at 15:30 UTC on #centos-devel . We can do a show of hands and
see if we can take the SIG further ahead.
[1] https://www.centos.org/community/calendar/#Storage_SIG
Thanks,
Lala
Hi,
any news about the common release rpm for Virt SIG?
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
Hi everyone,
I was curious about the status of the openafs work with the storage SIG.
What's left to do? What are the blocking items? As I understand, there
is an RPM without kernel modules.
Thanks,
Jason
SCLo SIG meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, 11:00
Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode.
= Topics =
* cbs builds going, sharing status
* dist-git repos creation -- any update?
https://bugs.centos.org/view.php?id=9219
* docker images based on SCL packages built in cbs
how/where to build them?
who can push them into docker hub?
Honza
This place may be more appropriate then centos-list.
My subscription is new therefore sorry, if already asked:
How is the centos policy for EL6 SCL packages? I see some
activities about a sclo7 branch but how is the status for
rhscl especially el6's ones?
Thanks,
LF
Hi All,
We're working on testing instances of FAS for storing our user/group
membership information used by the CBS. I'd like to talk about group
naming and the permissions model to get some input. The goal is to get
these discussions going so we can set up our test environment to mirror
what we'll roll out in production. Consider this a proposal, and please
send comments my way (on-list please!).
Groups will use the convention 'sig-<shortname>', for example: people in
the Cloud SIG will be members of the FAS group 'sig-cloud'. This
convention will allow push access in dist-git to any branch that starts
with sig-cloud (sig-cloud7, sig-cloud7-openstack,
sig-cloud7-openstack-juno) and grant build permissions under the SIG tags
in Koji[0].
FAS has 3 types of membership in a group: Admin, Sponsor, and User. All 3
levels will be granted commit/build permissions, while only Admins and
Sponsors can modify members of the group.
To match our permissions model[1], I propose:
- We populate the 'Accounts' (Global Admin) group with the members of the
CentOS Board.
- The Board member responsible for each SIG will create the appropriate
SIG group in FAS
- The Board member will add him/herself as an admin of the group
- The Board member will sponsor the SIG Chair as a sponsor for the group
- From then on, the SIG Chair and Board member can sponsor others into the
group as users (and optionally add more sponsors to the group)
Anyone have thoughts? Once we reach consensus, I'll get this written up
for the SIG wiki page.
Cheers!
Brian
[0]: http://wiki.centos.org/BrianStinson/GitBranchesandKojiTags
[1]: http://wiki.centos.org/SpecialInterestGroup
Hi All,
We'll be having another meeting to talk about the Commmunity Build
System. Join us in #centos-devel on Freenode.
Proposed Agenda:
- Status Updates
- General
- Central Auth
- Adding remote builders
Cheers!
Brian