From c3b3e1ec20ee8ef41a727e739d69c0f854e15372 Mon Sep 17 00:00:00 2001 From: Jim Perrin Date: Sep 25 2014 14:54:08 +0000 Subject: update stuff --- diff --git a/content/index.erb b/content/index.erb index a92d9e8..98a275f 100644 --- a/content/index.erb +++ b/content/index.erb @@ -44,6 +44,15 @@ $(document).ready(function () { ...
+

cPanel Conference - Houston, Texas 29 Sept - 1 Oct 2014

+

Come join the CentOS team at Hands On Houston, by cPanel!

+
+ + +
+ + ... +

CentOS Dojo - Barcelona, Spain 29 Oct 2014

Come join the CentOS team in Barcelona

Sponsored by CSUC

diff --git a/content/sponsors/securedservers.erb b/content/sponsors/securedservers.erb index a6eafe5..23e4d58 100644 --- a/content/sponsors/securedservers.erb +++ b/content/sponsors/securedservers.erb @@ -3,6 +3,6 @@ name: Phoenix NAP sponsor: true country: usa is_hidden: true -img: /images/sponsors/PNAP-Logo-CMYK.JPG -url: http://securedservers.com +img: /images/sponsors/PNAP_Banner.gif +url: http://www.securedservers.com/landing/linux-hosting/ --- diff --git a/media.erb b/media.erb new file mode 100644 index 0000000..5f6a168 --- /dev/null +++ b/media.erb @@ -0,0 +1,29 @@ +--- +title: Media +presentation_title: CentOS Board Meeting +presenter: CentOS Project +iframe_url: +event: Office Hours +stream: true +--- +<% if @item[:stream] %> + + <% if @item[:presentation_title] %> +

<%= @item[:presentation_title] %>

+ <% end %> + <% if @item[:presenter] %> +

Presenter: <%= @item[:presenter] %> + <% end %> +
+
+ <%= @item[:iframe_url] %> + + <% if @item[:event] %> +

Stream of: <%= @item[:event] %> + <% end %> +<% else %> +

No Live Broadcast

+

Videos from Past Events

+ +<% end %> + diff --git a/static/images/sponsors/PNAP_Banner.gif b/static/images/sponsors/PNAP_Banner.gif new file mode 100644 index 0000000..278dad0 Binary files /dev/null and b/static/images/sponsors/PNAP_Banner.gif differ diff --git a/static/minutes/2014/april/centos-devel.2014-04-02-21.55.html b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.html new file mode 100644 index 0000000..5bd6437 --- /dev/null +++ b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.html @@ -0,0 +1,158 @@ + + + + +#centos-devel: CentOS Board meeting - SIG proposals & other business + + + + +

#centos-devel: CentOS Board meeting - SIG proposals & other business

+ +Meeting started by quaid at 21:55:53 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. We have a quorum of Board members, safe to + proceed :) (quaid, + 21:58:58)
      2. +
    +
    2. +
  2. Desktop SIG proposal (quaid, 21:59:20) +
      +
    1. current boundaries for the SIG are to include + alternate desktop environments (DEs) with the future expansion in to + styling (quaid, + 22:18:46)
      2. +
    2. a SIG boundary is to not include non-open + source nor software with potential or real legal issues (quaid, + 22:19:21)
      3. +
    3. SIG may carry packages that are later than what + is in EPEL if it feels the need (quaid, + 22:20:05)
      4. +
    4. target for CentOS 7* to start, back to CentOS + 6* as time and interest permits (quaid, + 22:25:00)
      5. +
    5. ACTION: smooge to + work up a formal proposal (quaid, + 22:50:46)
      6. +
    6. ACTION: SIG needs to + consider what release formats to use (ISO, netinstall, + all-in-one-spins, etc.) (quaid, + 22:51:57)
      7. +
    7. IDEA: project wide work + on Anaconda to fold in all groups/variants will help the Desktop SIG + needs for respins, etc. (quaid, + 22:53:33)
      8. +
    8. IDEA: discuss about + respins using packages not built on centos infra and so not signed + by us (Arrfab, + 22:56:56)
      9. +
    +
    3. +
+

+ + + + +Meeting ended at 23:08:36 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. smooge to work up a formal proposal
    2. +
  2. SIG needs to consider what release formats to use (ISO, netinstall, all-in-one-spins, etc.)
    3. +
+

+ + + +

Action items, by person

+
    +
  1. smooge
      +
    1. smooge to work up a formal proposal
      2. +
    2. +
+

+ + + +

People present (lines said)

+
    +
  1. dan408 (46)
    2. +
  2. quaid (42)
    3. +
  3. smooge (40)
    4. +
  4. Evolution (34)
    5. +
  5. kbsingh (19)
    6. +
  6. hughesjr (12)
    7. +
  7. Arrfab (11)
    8. +
  8. centbot (3)
    9. +
  9. tru_tru (3)
    10. +
  10. cctrieloff (2)
    11. +
  11. wolfy (1)
    12. +
  12. range (0)
    13. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.html b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.html new file mode 100644 index 0000000..6fa978d --- /dev/null +++ b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.html @@ -0,0 +1,240 @@ + + + + +#centos-devel log + + + + +
21:55:53 <quaid> #startmeeting CentOS Board meeting - SIG proposals & other business
+21:55:53 <centbot> Meeting started Wed Apr  2 21:55:53 2014 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
+21:55:53 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+21:56:16 <quaid> #chair Evolution tru_tru range kbsingh hughesjr cctrieloff Arrfab
+21:56:16 <centbot> Current chairs: Arrfab Evolution cctrieloff hughesjr kbsingh quaid range tru_tru
+21:56:31 <quaid> all users can use most of the actions, such as #info and #idea
+21:56:43 <quaid> chairs can do the #agreed, not sure if #action is restricted
+21:56:52 <quaid> anything before we jump in to the first topic?
+21:57:04 <kbsingh> show of hands ?
+21:57:22 * tru_tru raises hand
+21:57:34 * hughesjr shows his hand :D
+21:57:53 <smooge> here
+21:58:05 <Arrfab> same here
+21:58:06 <kbsingh> me too
+21:58:16 <Evolution> yep
+21:58:58 <quaid> #info We have a quorum of Board members, safe to proceed :)
+21:59:08 <quaid> first topic is Desktop SIG?
+21:59:19 <Evolution> sure.
+21:59:20 <quaid> #topic Desktop SIG proposal
+21:59:38 <quaid> (channel title hasn't changed because centbot doesn't have ops, but it's changed in the log)
+21:59:51 <quaid> also, you don't  need to use #link, just post the URL in the channel and it's the same thing
+22:01:11 <Arrfab> Evolution: you already started a discussion with smooge about a desktop SIG, right ? what's the status and so the "proposal" ?
+22:01:20 <Evolution> smooge: you proposed the desktop sig. want to lay out your ideas?
+22:01:24 <smooge> I would like to propose a Desktop Special Interest Group that would cater towards alternative desktops to the main CentOS one.
+22:02:16 <Evolution> smooge: is the thought just to provide alternative desktops such as mate, or would you add additional 'desktop' style packages as well?
+22:02:24 <smooge> Its main goal would be to make sure that working desktops that cater to other users needs are made available, tested, working and periodically updated
+22:02:57 <smooge> my first goal would be to provide just alternate desktops and then from that gauge growth inot additional desktop style packages.
+22:03:06 <smooge> s/inot/into/
+22:03:29 <smooge> I would like to have an initial goal we can reach and build momentum from
+22:03:52 <hughesjr> smooge: is the inital focus of this desktop for all active versions of CentOS or only for a specific CentOS
+22:04:43 <smooge> My initial focus would be 7. The ability to build desktops to older releases will require extra effort and testing
+22:05:15 <smooge> as the solutions may require some things like SCL's or other "we aren't replacing core stuff.. but we are." type solutions
+22:05:43 <Evolution> most desktop users seem to migrate to newer versions reasonably quickly
+22:05:44 <quaid> are there other desktop-like activities you might include in the SIG other than alternative DEs and styling? for example, UX testing.
+22:05:56 <hughesjr> smooge: and you have some kind of plan to make sure we are not running afowl of patent issues (like mp3)
+22:06:01 <smooge> I apologize for the wishy washy ness of this. I want to get some questions answered so that I can better focus a finished proposal to you.
+22:06:01 <Arrfab> smooge: do you see that as a "coordination" effort between existing desktop environments ? (for example EPEL providing already alternatives)
+22:06:41 <Evolution> Arrfab: I think part of it certainly should be.
+22:06:46 <smooge> hughesjr, I do not plan to put anything in that could not be shipped in Fedora. Things like VLC etc will have to be done by an associated group which would not be troubled like I personally would be
+22:07:14 <Evolution> mate and cinnamon are already in epel. we should certainly appropriate that effort and help where we can.
+22:08:22 <smooge> the items that will be a further focus is how to package these items for older releases. I would like to have it that people who need to develop/run EL5 could have a better experience but not replacing certain core items like glibc/gcc/kernel :)
+22:09:01 <smooge> Arrfab, I see it as partially coordination. I am worried that EPEL may not be the best place for itmes which change every 6-12 months.
+22:09:57 <quaid> smooge: are there other desktop-like activities you might include in the SIG other than alternative DEs and styling? for example, UX testing. -- alternately, I'm not asking if you'll do that work per se but if you are receptive to that work happening within the SIG? Is there a boundary where it's not SIG-relevant?
+22:10:05 <smooge> If it turns out that EPEL is not the best place then it is on building the group which will be a better ground.
+22:11:10 <smooge> quaid, to answer that I needed to reverse it. How strong a boundary is the board looking for SIGs to have.
+22:12:01 <hughesjr> smooge: SIGs already have the ability to go higher in version for things that are part of even the "Core" OS .. so it would be fine for newer things that in EPEL they choose not to maintain a version that we need
+22:12:30 <smooge> Well the EPEL issue is that it can't replace stuff that is in Core.
+22:12:39 <hughesjr> right
+22:12:51 <hughesjr> but the SIG can, if requried
+22:13:56 <Evolution> so epel for some things, and then possibly a 'desktop' repository or whatever for things not suited for epel, but maitained by the sig
+22:14:01 <smooge> so my question was "Is the board looking for well defined boundaries that a SIG has in place from the beginning" or is it wanting a lose rule of thumb
+22:14:04 <quaid> smooge: it's a fair question you reversed to -- we're interested in it being a wider focus, so "Mate SIG" isn't right, but "Desktop SIG that includes Mate" is ... at that point, the boundary should be what the SIG wants to support and thinks their community needs
+22:14:30 <quaid> I think loose rule of thumb is better, let it grow organically
+22:14:39 <hughesjr> WRT the board question about SIGs, we will have at least one board member in the SIG ... so we will give SIGs as much lattitude as possible
+22:14:43 <quaid> I was mainly curious if you saw that in the future (cf. styling) or thought it was out of scope
+22:14:50 <smooge> also is the board wanting me to do a PRD or similar tools to have ready as a full fleshed proposal
+22:15:09 <quaid> you can use the existing proposals as a template, but yes, we do want something concrete to vote on
+22:15:48 <smooge> quaid, I haven't been presented with any examples of items yet for desktop tools that weren't redlines (VLC, mp3 plugins, etc)
+22:15:55 <smooge> so I can't answer clearly yet
+22:17:26 <cctrieloff> I'm here but distracted.
+22:17:27 <smooge> can someone send me a link for an existing SIG? I will work from that and have something for you asap
+22:18:00 <Evolution> smooge: http://wiki.centos.org/SpecialInterestGroup/CloudInstance
+22:18:06 <Evolution> unless kbsingh has a better one.
+22:18:16 <smooge> okie dokie
+22:18:18 <Evolution> strip CloudInstance off for a list of others.
+22:18:46 <quaid> #info current boundaries for the SIG are to include alternate desktop environments (DEs) with the future expansion in to styling
+22:18:58 <Evolution> smooge: based on your email to the list, I roughed out http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop but it needs some work.
+22:19:21 <quaid> #info a SIG boundary is to not include non-open source nor software with potential or real legal issues
+22:19:52 <kbsingh> thats it
+22:19:56 <smooge> Evolution, thank you.
+22:20:05 <quaid> #info SIG may carry packages that are later than what is in EPEL if it feels the need
+22:21:44 <smooge> I would like to be able to let interested people work on unified theming etc.. but there will be no 'forced' theming (eg people who want alternative desktops usually do their desktops there way thank you very much.)
+22:22:21 <kbsingh> i missed if this is going to only target el7 or el6 as well ?
+22:22:42 <Evolution> kbsingh: 7 to start. 6 if interest/time permists.
+22:22:52 <Evolution> iirc
+22:23:00 <smooge> kbsingh, I am initially going to focus on el7. The el6 may require me to use software collections or similar tools which I need to study more before I give a I will do that.
+22:23:11 <smooge> If others are willing I am up with doing 6 and 5.
+22:23:27 <smooge> does that make sense?
+22:23:34 <kbsingh> sure
+22:25:00 <smooge> My main rules on 'desktops' and such being supported is that they will be shipped as long as people are willing to work on them. I don't want abandon ware (eg tvtwm compiles.. good enough)
+22:25:00 <quaid> #info target for CentOS 7* to start, back to CentOS 6* as time and interest permits
+22:26:12 <smooge> When is the next board meeting?
+22:26:36 <Evolution> week after next.
+22:27:28 <smooge> OK I will make sure I have a finished document with you guys by next wednessday and will work with Evolution and dan408 on it
+22:27:47 <smooge> are there any other questions?
+22:27:56 <Evolution> smooge: leigh expressed a passing interest as well (as the cinnamon maintainer)
+22:28:26 <kbsingh> how is this going to layer on top of EPEL ?
+22:28:37 <kbsingh> i mean, a chunk of the work might actually be possible to get done there right ?
+22:28:49 <Evolution> kbsingh: some is done there, yes.
+22:28:57 <Evolution> mate/cinnamon exist there already
+22:28:58 <kbsingh> ( apart from when $person wants something newer, they can fork it - but will that code then be forked in git.fedora or git.centos )
+22:30:38 <smooge> kbsingh, I believe the initial work can be done in EPEL. However if the changes to later versions are invasive etc then it will need changes in either how EPEL is structured or a different build infrastructure.
+22:30:55 <smooge> kbsingh, in that case I would be working on making that happen.
+22:31:02 <dan408> Evolution: hey
+22:31:08 <dan408> sorry i got dragged out
+22:31:23 * dan408 reads scrollback
+22:31:48 <smooge> kbsingh, in the case where it wouldn't work for EPEL (say Mate in EL5) but could be done via a different packaging system then we would work on solving that problem
+22:32:01 <kbsingh> ok
+22:32:24 <kbsingh> so essentially : fix problems as we see them - there is flexibility from packager and buildsystem side. epel to bootstrap into
+22:33:52 <smooge> correct. I expect we will need to change over time, but to meet a can we have a solution in 3-6 months the proven existing method to start from.
+22:35:10 <dan408> so the biggest roadblock I'm personally seeing is getting Anaconda to read directly from EPEL for yum groups
+22:35:11 <kbsingh> is there any drive to also maintain some part of the docs aronud this on say wiki.centos.org/blah/howto/desktops
+22:35:12 <Arrfab> smooge: that sounds good to me .. but indeed some choices will have to be made, like for example if CentOS 7 32bits becomes real
+22:35:25 <kbsingh> or is the focus purely on delivering rpms, let the community at large do that
+22:35:25 <dan408> I just finished building the MATE stack of packages on EPEL
+22:35:54 <kbsingh> dan408: anaconda... should be fairly simple, with an add-repo at install time right ?
+22:36:28 <dan408> kbsingh: well ideally EPEL would just be there out of the box, and you would see MATE as a choice of available desktops
+22:37:12 <dan408> so for example you choose "desktop" and then you can pick Gnome, KDE, or Cinnamon, etc
+22:37:27 <kbsingh> that shouldnt be hard to do - but how many groups does EPEL host ? we'd have a minor flood
+22:37:27 <dan408> otherwise you end up having to install Gnome or KDE and then MATE or cinnamon
+22:37:47 <dan408> I'm pretty sure Anaconda can handle it
+22:37:50 <smooge> kbsingh, I would like to make sure that we have guides and howtos as part of any 'desktop' solution added. If only on how one logs out, finds certain apps etc.
+22:38:07 <Evolution> honestly I think we might consider just stealing the groups we want from epel, and then adding epel-release as a mandatory package for the desktop spin
+22:38:14 <Evolution> that would limit the groups visible in anaconda.
+22:39:03 <hughesjr> Evolution: as long as they are responsive to updates
+22:39:09 <dan408> wait what do you mean spin?
+22:39:24 <smooge> I had not thought about spins per se at the moment. For me it is a "if I have the time"... unless that is a required SIG deliverable.
+22:39:46 <dan408> I was thinking netinstall/DVD not spin
+22:40:18 <dan408> or just DVD I don't think you guys do a netinstall do you
+22:40:25 <quaid> so no ISO compose?
+22:40:38 <dan408> wll
+22:40:39 <Evolution> well, the core provided by the core sig won't change.
+22:40:39 <dan408> well
+22:40:40 <quaid> minimal install is the most popular download iirc, it's basically a netinstall isn't it?
+22:40:51 <dan408> no
+22:41:12 <dan408> so i'm coming from the Fedora side so I may be a little bit confused
+22:41:22 <dan408> but on Fedora side you can install anything with a 200mb iso image
+22:41:23 <Evolution> dan408: we do netinstalls, as well as minimals and something similar to boot.fedora
+22:41:28 * quaid a bit lost in terminology too
+22:41:28 <dan408> right
+22:41:49 <dan408> okay
+22:42:06 <wolfy> quaid: the minimal.iso bypasses the package selection step and installs @base . all the needed packages are included in the iso
+22:42:06 <Evolution> however for a desktop side, I would think some folks would want a usb/iso based install for a desktop
+22:42:07 <tru_tru> why just not a desktop-SIG.repo or repo --name=desktop-SIG --baseurl=http:// --cost=XXX ?
+22:42:07 <dan408> for the DVD it wouldnt work if you didnt have a network connection
+22:42:23 <kbsingh> if the work is done in a contained repo, regardless of how the install starts, its all just a case of adding the repo line, comps will get parsed and options show up in the gui
+22:42:26 <Evolution> tru_tru: entirely doable as well.
+22:42:34 <Evolution> dan408: right. which is why I was thinking spin.
+22:42:53 <Evolution> kbsingh: true
+22:42:59 <hughesjr> in the past, when we have had alternative desktops (ie xfce on 5 and 4 :D) we did yum groups in a repo ... that will also work
+22:43:02 <kbsingh> we can also ship an additional repo on the DVD ( if it fits! ) with the repo line disabled and a media:/// url
+22:43:21 <dan408> Evolution: well I guess that would be easier and accomplish the goal of a) not having to change base and b) being able to install the desktop you want without having to install a desktop you dont want
+22:43:46 <kbsingh> it does not need to end up in the os/ directory, and it need not be enabled by force, but just a checkbox to enable it from DVD might be a great option
+22:43:51 <quaid> wolfy: thanks
+22:43:52 <kbsingh> the trick is going to be making it fit
+22:43:57 <hughesjr> dan408: minimal install and yum grops cando that too :)
+22:43:57 <dan408> hughesjr: what if you wanted to install xfce on a fresh install?
+22:44:06 <dan408> hughesjr: no
+22:44:30 <dan408> hughesjr: Say I want to put media in choose xfce, and install once and be done
+22:45:09 <dan408> your process is a 2 step process
+22:45:18 <hughesjr> dan408: you can create a specific DVD for that too in the SIG
+22:45:33 <dan408> hughesjr: Right that's what we're discussing with spins
+22:46:00 <dan408> alright
+22:46:15 <dan408> this is gunna require some hacking but
+22:46:48 <hughesjr> I was just pointing out that an ISO is not the only alternative .. but the SIGs can do that too
+22:47:22 <quaid> ultimately the SIG needs to chose delivery methods that make sense for it's community, these questions are somewhat about what the rest of us think makes sense ...
+22:48:02 <dan408> i guess if it worked like this: 1) User downloads CentOS 7 MATE spin which can be burnt to CD or written to USB 2) User boots spin, starts Anaconda installer 3) Anaconda functiosn in the exact same way as the DVD or netinstall and can install the same things .. so user chooses say base, standard and "web server", chooses partitioning and hits "install". What they should end up with is a MATE desktop with the options they picked
+22:48:45 <Evolution> right.
+22:48:52 <dan408> Again, I don't know if this is possible with the current anaconda
+22:49:25 <kbsingh> right guys, i need to rebase over. thanks
+22:49:28 <Evolution> I don't see why it wouldn't be. it's similar to whate fedora's done with it in the last couple releases.
+22:49:46 <Arrfab> dan408: I haven't looked at anaconda from 7 (yet) but I guess using the updates.img still works for that
+22:49:47 <Evolution> I've got to bail in about 5 minutes as well
+22:50:03 <dan408> Evolution: Not necessarily. On a spin you just hit "install" and it installs whatever was included with the spin. You don't get to pick any additional options
+22:50:31 <Evolution> ah, fair enough.
+22:50:45 <dan408> Arrfab: Sure. I'm no anaconda expert here but I'm just throwing this stuff out there
+22:50:46 <quaid> #action smooge to work up a formal proposal
+22:51:57 <quaid> #action SIG needs to consider what release formats to use (ISO, netinstall, all-in-one-spins, etc.)
+22:51:57 <dan408> Evolution: That's why I'm thinking there might be some hacking needed because these packages are already in Fedora base.
+22:52:12 <Arrfab> dan408: we'll have to have a deep look into anaconda to also combine all the groups/variants into one (like we did for centos 6) so I'm sure that once it will be mastered, it will be easy to modify it again for each SIG respin
+22:52:25 <dan408> Arrfab: +1
+22:52:27 <Evolution> dan408: yeah. I'm starting to see what you mean.
+22:52:36 <dan408> Evolution: cool
+22:52:45 <quaid> fwiw, I'm comfortable with usinage latest bits in Fedora as upstream that we pull in to git.centos.org (if I'm thinking correctly here); Fedora (and EPEL) are trustworthy upstreams
+22:52:59 <dan408> Evolution: The easiest thing is just to import the packages to base, but I completely understand that you don't want to change base.
+22:53:26 <dan408> Evolution: And that's fine, but workarounds are needed. :D
+22:53:33 <quaid> #idea project wide work on Anaconda to fold in all groups/variants will help the Desktop SIG needs for respins, etc.
+22:53:40 <Evolution> yeah. we'll have to figure that out. base won't change.
+22:54:37 <dan408> Right. Well I'm glad I was able to help put everyone on the same page on how it should be presented to the end user for installation
+22:55:16 <dan408> I mean that's how I'd want it personally
+22:55:19 <Arrfab> Evolution: yeah but the desktop sig proposal we have here is quite different from the cloud/storage ones in a sense that we'd build packages with the same key (or alternate key but still from our side) while the idea seems to be here to just consume packages built/signed by EPEL
+22:55:47 <Evolution> Arrfab: that's the initial starting point, but by no means the end goal.
+22:55:56 <dan408> Arrfab: it's a little bit more than that
+22:56:04 <Evolution> anyway, off for family. bbiab
+22:56:11 <dan408> cya Evolution
+22:56:34 <quaid> ok, I'm ready to close out as we are runnning out of Board members and the sponsor just left :)
+22:56:38 <quaid> anything else for the record?
+22:56:41 <tru_tru> Evolution: ciao
+22:56:45 * quaid will close in 60 seconds otherwise
+22:56:56 <Arrfab> #idea discuss about respins using packages not built on centos infra and so not signed by us
+22:57:00 <quaid> btw, dan408, good to see ya
+22:57:04 <dan408> For the record: The entire MATE stack is finished building and I'm going to add a group in to EPEL7 for comps
+22:57:09 <dan408> quaid: good to see you too
+22:57:19 <quaid> Arrfab: yeah, we need to really consider that around EPEL in general, right?
+22:57:48 <Arrfab> quaid: yeah, EPEL or other repositories too I guess.
+22:59:14 <smooge> I am ok with closing.
+22:59:16 <dan408> If anyone has any questions feel free to contact me here (I prefer IRC over email)
+22:59:27 <Arrfab> dan408, smooge : what about starting as a documentation on how to install those packages from epel on a running c7. then we'd have to see how to respin specific medias and in the meantime we'll have discussed the "do we rebuild/sign those packages or do we just import those" question
+22:59:35 <cctrieloff> thx
+23:00:07 <smooge> okie dokie.
+23:00:14 <dan408> sure thing I'll work with smooge on that.
+23:00:16 <Arrfab> thanks everyone for the meeting
+23:00:22 <dan408> thanks for hosting!
+23:07:18 <smooge> quaid, remember to #endmeeting
+23:08:03 * quaid was distracted, thanks
+23:08:10 <smooge> np
+23:08:10 <quaid> typical!
+23:08:18 <quaid> going in 5
+23:08:20 <quaid> 4
+23:08:21 <quaid> 3
+23:08:24 <quaid> 2
+23:08:24 <quaid> 1
+23:08:36 <quaid> #endmeeting
+ diff --git a/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.txt b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.txt new file mode 100644 index 0000000..cb333c9 --- /dev/null +++ b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.log.txt @@ -0,0 +1,213 @@ +21:55:53 #startmeeting CentOS Board meeting - SIG proposals & other business +21:55:53 Meeting started Wed Apr 2 21:55:53 2014 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. +21:55:53 Useful Commands: #action #agreed #help #info #idea #link #topic. +21:56:16 #chair Evolution tru_tru range kbsingh hughesjr cctrieloff Arrfab +21:56:16 Current chairs: Arrfab Evolution cctrieloff hughesjr kbsingh quaid range tru_tru +21:56:31 all users can use most of the actions, such as #info and #idea +21:56:43 chairs can do the #agreed, not sure if #action is restricted +21:56:52 anything before we jump in to the first topic? +21:57:04 show of hands ? +21:57:22 * tru_tru raises hand +21:57:34 * hughesjr shows his hand :D +21:57:53 here +21:58:05 same here +21:58:06 me too +21:58:16 yep +21:58:58 #info We have a quorum of Board members, safe to proceed :) +21:59:08 first topic is Desktop SIG? +21:59:19 sure. +21:59:20 #topic Desktop SIG proposal +21:59:38 (channel title hasn't changed because centbot doesn't have ops, but it's changed in the log) +21:59:51 also, you don't need to use #link, just post the URL in the channel and it's the same thing +22:01:11 Evolution: you already started a discussion with smooge about a desktop SIG, right ? what's the status and so the "proposal" ? +22:01:20 smooge: you proposed the desktop sig. want to lay out your ideas? +22:01:24 I would like to propose a Desktop Special Interest Group that would cater towards alternative desktops to the main CentOS one. +22:02:16 smooge: is the thought just to provide alternative desktops such as mate, or would you add additional 'desktop' style packages as well? +22:02:24 Its main goal would be to make sure that working desktops that cater to other users needs are made available, tested, working and periodically updated +22:02:57 my first goal would be to provide just alternate desktops and then from that gauge growth inot additional desktop style packages. +22:03:06 s/inot/into/ +22:03:29 I would like to have an initial goal we can reach and build momentum from +22:03:52 smooge: is the inital focus of this desktop for all active versions of CentOS or only for a specific CentOS +22:04:43 My initial focus would be 7. The ability to build desktops to older releases will require extra effort and testing +22:05:15 as the solutions may require some things like SCL's or other "we aren't replacing core stuff.. but we are." type solutions +22:05:43 most desktop users seem to migrate to newer versions reasonably quickly +22:05:44 are there other desktop-like activities you might include in the SIG other than alternative DEs and styling? for example, UX testing. +22:05:56 smooge: and you have some kind of plan to make sure we are not running afowl of patent issues (like mp3) +22:06:01 I apologize for the wishy washy ness of this. I want to get some questions answered so that I can better focus a finished proposal to you. +22:06:01 smooge: do you see that as a "coordination" effort between existing desktop environments ? (for example EPEL providing already alternatives) +22:06:41 Arrfab: I think part of it certainly should be. +22:06:46 hughesjr, I do not plan to put anything in that could not be shipped in Fedora. Things like VLC etc will have to be done by an associated group which would not be troubled like I personally would be +22:07:14 mate and cinnamon are already in epel. we should certainly appropriate that effort and help where we can. +22:08:22 the items that will be a further focus is how to package these items for older releases. I would like to have it that people who need to develop/run EL5 could have a better experience but not replacing certain core items like glibc/gcc/kernel :) +22:09:01 Arrfab, I see it as partially coordination. I am worried that EPEL may not be the best place for itmes which change every 6-12 months. +22:09:57 smooge: are there other desktop-like activities you might include in the SIG other than alternative DEs and styling? for example, UX testing. -- alternately, I'm not asking if you'll do that work per se but if you are receptive to that work happening within the SIG? Is there a boundary where it's not SIG-relevant? +22:10:05 If it turns out that EPEL is not the best place then it is on building the group which will be a better ground. +22:11:10 quaid, to answer that I needed to reverse it. How strong a boundary is the board looking for SIGs to have. +22:12:01 smooge: SIGs already have the ability to go higher in version for things that are part of even the "Core" OS .. so it would be fine for newer things that in EPEL they choose not to maintain a version that we need +22:12:30 Well the EPEL issue is that it can't replace stuff that is in Core. +22:12:39 right +22:12:51 but the SIG can, if requried +22:13:56 so epel for some things, and then possibly a 'desktop' repository or whatever for things not suited for epel, but maitained by the sig +22:14:01 so my question was "Is the board looking for well defined boundaries that a SIG has in place from the beginning" or is it wanting a lose rule of thumb +22:14:04 smooge: it's a fair question you reversed to -- we're interested in it being a wider focus, so "Mate SIG" isn't right, but "Desktop SIG that includes Mate" is ... at that point, the boundary should be what the SIG wants to support and thinks their community needs +22:14:30 I think loose rule of thumb is better, let it grow organically +22:14:39 WRT the board question about SIGs, we will have at least one board member in the SIG ... so we will give SIGs as much lattitude as possible +22:14:43 I was mainly curious if you saw that in the future (cf. styling) or thought it was out of scope +22:14:50 also is the board wanting me to do a PRD or similar tools to have ready as a full fleshed proposal +22:15:09 you can use the existing proposals as a template, but yes, we do want something concrete to vote on +22:15:48 quaid, I haven't been presented with any examples of items yet for desktop tools that weren't redlines (VLC, mp3 plugins, etc) +22:15:55 so I can't answer clearly yet +22:17:26 I'm here but distracted. +22:17:27 can someone send me a link for an existing SIG? I will work from that and have something for you asap +22:18:00 smooge: http://wiki.centos.org/SpecialInterestGroup/CloudInstance +22:18:06 unless kbsingh has a better one. +22:18:16 okie dokie +22:18:18 strip CloudInstance off for a list of others. +22:18:46 #info current boundaries for the SIG are to include alternate desktop environments (DEs) with the future expansion in to styling +22:18:58 smooge: based on your email to the list, I roughed out http://wiki.centos.org/SpecialInterestGroup/AlternativeDesktop but it needs some work. +22:19:21 #info a SIG boundary is to not include non-open source nor software with potential or real legal issues +22:19:52 thats it +22:19:56 Evolution, thank you. +22:20:05 #info SIG may carry packages that are later than what is in EPEL if it feels the need +22:21:44 I would like to be able to let interested people work on unified theming etc.. but there will be no 'forced' theming (eg people who want alternative desktops usually do their desktops there way thank you very much.) +22:22:21 i missed if this is going to only target el7 or el6 as well ? +22:22:42 kbsingh: 7 to start. 6 if interest/time permists. +22:22:52 iirc +22:23:00 kbsingh, I am initially going to focus on el7. The el6 may require me to use software collections or similar tools which I need to study more before I give a I will do that. +22:23:11 If others are willing I am up with doing 6 and 5. +22:23:27 does that make sense? +22:23:34 sure +22:25:00 My main rules on 'desktops' and such being supported is that they will be shipped as long as people are willing to work on them. I don't want abandon ware (eg tvtwm compiles.. good enough) +22:25:00 #info target for CentOS 7* to start, back to CentOS 6* as time and interest permits +22:26:12 When is the next board meeting? +22:26:36 week after next. +22:27:28 OK I will make sure I have a finished document with you guys by next wednessday and will work with Evolution and dan408 on it +22:27:47 are there any other questions? +22:27:56 smooge: leigh expressed a passing interest as well (as the cinnamon maintainer) +22:28:26 how is this going to layer on top of EPEL ? +22:28:37 i mean, a chunk of the work might actually be possible to get done there right ? +22:28:49 kbsingh: some is done there, yes. +22:28:57 mate/cinnamon exist there already +22:28:58 ( apart from when $person wants something newer, they can fork it - but will that code then be forked in git.fedora or git.centos ) +22:30:38 kbsingh, I believe the initial work can be done in EPEL. However if the changes to later versions are invasive etc then it will need changes in either how EPEL is structured or a different build infrastructure. +22:30:55 kbsingh, in that case I would be working on making that happen. +22:31:02 Evolution: hey +22:31:08 sorry i got dragged out +22:31:23 * dan408 reads scrollback +22:31:48 kbsingh, in the case where it wouldn't work for EPEL (say Mate in EL5) but could be done via a different packaging system then we would work on solving that problem +22:32:01 ok +22:32:24 so essentially : fix problems as we see them - there is flexibility from packager and buildsystem side. epel to bootstrap into +22:33:52 correct. I expect we will need to change over time, but to meet a can we have a solution in 3-6 months the proven existing method to start from. +22:35:10 so the biggest roadblock I'm personally seeing is getting Anaconda to read directly from EPEL for yum groups +22:35:11 is there any drive to also maintain some part of the docs aronud this on say wiki.centos.org/blah/howto/desktops +22:35:12 smooge: that sounds good to me .. but indeed some choices will have to be made, like for example if CentOS 7 32bits becomes real +22:35:25 or is the focus purely on delivering rpms, let the community at large do that +22:35:25 I just finished building the MATE stack of packages on EPEL +22:35:54 dan408: anaconda... should be fairly simple, with an add-repo at install time right ? +22:36:28 kbsingh: well ideally EPEL would just be there out of the box, and you would see MATE as a choice of available desktops +22:37:12 so for example you choose "desktop" and then you can pick Gnome, KDE, or Cinnamon, etc +22:37:27 that shouldnt be hard to do - but how many groups does EPEL host ? we'd have a minor flood +22:37:27 otherwise you end up having to install Gnome or KDE and then MATE or cinnamon +22:37:47 I'm pretty sure Anaconda can handle it +22:37:50 kbsingh, I would like to make sure that we have guides and howtos as part of any 'desktop' solution added. If only on how one logs out, finds certain apps etc. +22:38:07 honestly I think we might consider just stealing the groups we want from epel, and then adding epel-release as a mandatory package for the desktop spin +22:38:14 that would limit the groups visible in anaconda. +22:39:03 Evolution: as long as they are responsive to updates +22:39:09 wait what do you mean spin? +22:39:24 I had not thought about spins per se at the moment. For me it is a "if I have the time"... unless that is a required SIG deliverable. +22:39:46 I was thinking netinstall/DVD not spin +22:40:18 or just DVD I don't think you guys do a netinstall do you +22:40:25 so no ISO compose? +22:40:38 wll +22:40:39 well, the core provided by the core sig won't change. +22:40:39 well +22:40:40 minimal install is the most popular download iirc, it's basically a netinstall isn't it? +22:40:51 no +22:41:12 so i'm coming from the Fedora side so I may be a little bit confused +22:41:22 but on Fedora side you can install anything with a 200mb iso image +22:41:23 dan408: we do netinstalls, as well as minimals and something similar to boot.fedora +22:41:28 * quaid a bit lost in terminology too +22:41:28 right +22:41:49 okay +22:42:06 quaid: the minimal.iso bypasses the package selection step and installs @base . all the needed packages are included in the iso +22:42:06 however for a desktop side, I would think some folks would want a usb/iso based install for a desktop +22:42:07 why just not a desktop-SIG.repo or repo --name=desktop-SIG --baseurl=http:// --cost=XXX ? +22:42:07 for the DVD it wouldnt work if you didnt have a network connection +22:42:23 if the work is done in a contained repo, regardless of how the install starts, its all just a case of adding the repo line, comps will get parsed and options show up in the gui +22:42:26 tru_tru: entirely doable as well. +22:42:34 dan408: right. which is why I was thinking spin. +22:42:53 kbsingh: true +22:42:59 in the past, when we have had alternative desktops (ie xfce on 5 and 4 :D) we did yum groups in a repo ... that will also work +22:43:02 we can also ship an additional repo on the DVD ( if it fits! ) with the repo line disabled and a media:/// url +22:43:21 Evolution: well I guess that would be easier and accomplish the goal of a) not having to change base and b) being able to install the desktop you want without having to install a desktop you dont want +22:43:46 it does not need to end up in the os/ directory, and it need not be enabled by force, but just a checkbox to enable it from DVD might be a great option +22:43:51 wolfy: thanks +22:43:52 the trick is going to be making it fit +22:43:57 dan408: minimal install and yum grops cando that too :) +22:43:57 hughesjr: what if you wanted to install xfce on a fresh install? +22:44:06 hughesjr: no +22:44:30 hughesjr: Say I want to put media in choose xfce, and install once and be done +22:45:09 your process is a 2 step process +22:45:18 dan408: you can create a specific DVD for that too in the SIG +22:45:33 hughesjr: Right that's what we're discussing with spins +22:46:00 alright +22:46:15 this is gunna require some hacking but +22:46:48 I was just pointing out that an ISO is not the only alternative .. but the SIGs can do that too +22:47:22 ultimately the SIG needs to chose delivery methods that make sense for it's community, these questions are somewhat about what the rest of us think makes sense ... +22:48:02 i guess if it worked like this: 1) User downloads CentOS 7 MATE spin which can be burnt to CD or written to USB 2) User boots spin, starts Anaconda installer 3) Anaconda functiosn in the exact same way as the DVD or netinstall and can install the same things .. so user chooses say base, standard and "web server", chooses partitioning and hits "install". What they should end up with is a MATE desktop with the options they picked +22:48:45 right. +22:48:52 Again, I don't know if this is possible with the current anaconda +22:49:25 right guys, i need to rebase over. thanks +22:49:28 I don't see why it wouldn't be. it's similar to whate fedora's done with it in the last couple releases. +22:49:46 dan408: I haven't looked at anaconda from 7 (yet) but I guess using the updates.img still works for that +22:49:47 I've got to bail in about 5 minutes as well +22:50:03 Evolution: Not necessarily. On a spin you just hit "install" and it installs whatever was included with the spin. You don't get to pick any additional options +22:50:31 ah, fair enough. +22:50:45 Arrfab: Sure. I'm no anaconda expert here but I'm just throwing this stuff out there +22:50:46 #action smooge to work up a formal proposal +22:51:57 #action SIG needs to consider what release formats to use (ISO, netinstall, all-in-one-spins, etc.) +22:51:57 Evolution: That's why I'm thinking there might be some hacking needed because these packages are already in Fedora base. +22:52:12 dan408: we'll have to have a deep look into anaconda to also combine all the groups/variants into one (like we did for centos 6) so I'm sure that once it will be mastered, it will be easy to modify it again for each SIG respin +22:52:25 Arrfab: +1 +22:52:27 dan408: yeah. I'm starting to see what you mean. +22:52:36 Evolution: cool +22:52:45 fwiw, I'm comfortable with usinage latest bits in Fedora as upstream that we pull in to git.centos.org (if I'm thinking correctly here); Fedora (and EPEL) are trustworthy upstreams +22:52:59 Evolution: The easiest thing is just to import the packages to base, but I completely understand that you don't want to change base. +22:53:26 Evolution: And that's fine, but workarounds are needed. :D +22:53:33 #idea project wide work on Anaconda to fold in all groups/variants will help the Desktop SIG needs for respins, etc. +22:53:40 yeah. we'll have to figure that out. base won't change. +22:54:37 Right. Well I'm glad I was able to help put everyone on the same page on how it should be presented to the end user for installation +22:55:16 I mean that's how I'd want it personally +22:55:19 Evolution: yeah but the desktop sig proposal we have here is quite different from the cloud/storage ones in a sense that we'd build packages with the same key (or alternate key but still from our side) while the idea seems to be here to just consume packages built/signed by EPEL +22:55:47 Arrfab: that's the initial starting point, but by no means the end goal. +22:55:56 Arrfab: it's a little bit more than that +22:56:04 anyway, off for family. bbiab +22:56:11 cya Evolution +22:56:34 ok, I'm ready to close out as we are runnning out of Board members and the sponsor just left :) +22:56:38 anything else for the record? +22:56:41 Evolution: ciao +22:56:45 * quaid will close in 60 seconds otherwise +22:56:56 #idea discuss about respins using packages not built on centos infra and so not signed by us +22:57:00 btw, dan408, good to see ya +22:57:04 For the record: The entire MATE stack is finished building and I'm going to add a group in to EPEL7 for comps +22:57:09 quaid: good to see you too +22:57:19 Arrfab: yeah, we need to really consider that around EPEL in general, right? +22:57:48 quaid: yeah, EPEL or other repositories too I guess. +22:59:14 I am ok with closing. +22:59:16 If anyone has any questions feel free to contact me here (I prefer IRC over email) +22:59:27 dan408, smooge : what about starting as a documentation on how to install those packages from epel on a running c7. then we'd have to see how to respin specific medias and in the meantime we'll have discussed the "do we rebuild/sign those packages or do we just import those" question +22:59:35 thx +23:00:07 okie dokie. +23:00:14 sure thing I'll work with smooge on that. +23:00:16 thanks everyone for the meeting +23:00:22 thanks for hosting! +23:07:18 quaid, remember to #endmeeting +23:08:03 * quaid was distracted, thanks +23:08:10 np +23:08:10 typical! +23:08:18 going in 5 +23:08:20 4 +23:08:21 3 +23:08:24 2 +23:08:24 1 +23:08:36 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/april/centos-devel.2014-04-02-21.55.txt b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.txt new file mode 100644 index 0000000..ef52075 --- /dev/null +++ b/static/minutes/2014/april/centos-devel.2014-04-02-21.55.txt @@ -0,0 +1,78 @@ +==================================================================== +#centos-devel: CentOS Board meeting - SIG proposals & other business +==================================================================== + + +Meeting started by quaid at 21:55:53 UTC. The full logs are available at +centos-devel/2014/centos-devel.2014-04-02-21.55.log.html . + + + +Meeting summary +--------------- +* We have a quorum of Board members, safe to proceed :) (quaid, + 21:58:58) +* Desktop SIG proposal (quaid, 21:59:20) + * current boundaries for the SIG are to include alternate desktop + environments (DEs) with the future expansion in to styling (quaid, + 22:18:46) + * a SIG boundary is to not include non-open source nor software with + potential or real legal issues (quaid, 22:19:21) + * SIG may carry packages that are later than what is in EPEL if it + feels the need (quaid, 22:20:05) + * target for CentOS 7* to start, back to CentOS 6* as time and + interest permits (quaid, 22:25:00) + * ACTION: smooge to work up a formal proposal (quaid, 22:50:46) + * ACTION: SIG needs to consider what release formats to use (ISO, + netinstall, all-in-one-spins, etc.) (quaid, 22:51:57) + * IDEA: project wide work on Anaconda to fold in all groups/variants + will help the Desktop SIG needs for respins, etc. (quaid, 22:53:33) + * IDEA: discuss about respins using packages not built on centos infra + and so not signed by us (Arrfab, 22:56:56) + +Meeting ended at 23:08:36 UTC. + + + + +Action Items +------------ +* smooge to work up a formal proposal +* SIG needs to consider what release formats to use (ISO, netinstall, + all-in-one-spins, etc.) + + + + +Action Items, by person +----------------------- +* smooge + * smooge to work up a formal proposal +* **UNASSIGNED** + * SIG needs to consider what release formats to use (ISO, netinstall, + all-in-one-spins, etc.) + + + + +People Present (lines said) +--------------------------- +* dan408 (46) +* quaid (42) +* smooge (40) +* Evolution (34) +* kbsingh (19) +* hughesjr (12) +* Arrfab (11) +* centbot (3) +* tru_tru (3) +* cctrieloff (2) +* wolfy (1) +* range (0) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/february/centos-devel.2014-02-10-15.59.html b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.html new file mode 100644 index 0000000..9d28e61 --- /dev/null +++ b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.html @@ -0,0 +1,195 @@ + + + + +#centos-devel Meeting + + + + +

#centos-devel Meeting

+ +Meeting started by quaid at 15:59:35 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. Agenda (quaid, 16:00:20) +
    2. +
  2. Quick summary (quaid, 16:01:08) +
      +
    1. http://wiki.centos.org/GSoC/2014/Application + (quaid, + 16:07:36)
      2. +
    2. IDEA: time based tasks + are not always the best idea (quaid, + 16:13:51)
      3. +
    3. IDEA: don't put a + student on a blocking component (quaid, + 16:14:03)
      4. +
    4. AGREED: must fit in + to a discrete task (quaid, + 16:14:35)
      5. +
    5. IDEA: the more we leave + open for students to find something that is interesting to them, the + more successful they more (quaid, + 16:15:10)
      6. +
    6. IDEA: mentoring is also + working on application process with students (quaid, + 16:17:16)
      7. +
    7. IDEA: deliver a + xen/centos6/image installer delivered (kbsingh, + 16:17:54)
      8. +
    8. IDEA: openstack livecd, + pre-setup to run and scale in a diskless environ (kbsingh, + 16:18:27)
      9. +
    9. IDEA: docker + deps/images/projects (Evolution, + 16:19:11)
      10. +
    10. IDEA: docker + deps/images/projects (Evolution, + 16:19:49)
      11. +
    11. IDEA: different levels + of tasks out there (quaid, + 16:21:12)
      12. +
    12. AGREED: students may + not have a good concept of what they can do -- push or reign them + in (quaid, + 16:21:41)
      13. +
    13. IDEA: build and + automate the in-cloud update/managent infra (kbsingh, + 16:21:41)
      14. +
    14. http://www.google-melange.com/gsoc/events/google/gsoc2014 + (quaid, + 16:24:10)
      15. +
    15. IDEA: explore bootstrap + for diff arch (kbsingh, + 16:25:49)
      16. +
    16. IDEA: those with time + to help the SIGs already can assist mentors (quaid, + 16:25:50)
      17. +
    17. IDEA: open project + ideas around ARM to interest hardware hackers (quaid, + 16:30:59)
      18. +
    18. ACTION: need to write + a marketing plan (quaid, + 16:31:14)
      19. +
    19. ACTION: interested + mentors to hang out on existing GSoC channel (quaid, + 16:31:48)
      20. +
    20. expectations need to be set up front with + students (quaid, + 16:35:22)
      21. +
    21. http://en.flossmanuals.net/melange/org-application-period/ + (quaid, + 16:35:47)
      22. +
    +
    3. +
+

+ + + + +Meeting ended at 16:37:29 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. need to write a marketing plan
    2. +
  2. interested mentors to hang out on existing GSoC channel
    3. +
+

+ + + +

People present (lines said)

+
    +
  1. quaid (28)
    2. +
  2. kbsingh (14)
    3. +
  3. Evolution (10)
    4. +
  4. Jeff_S (8)
    5. +
  5. centbot (3)
    6. +
  6. tigalch (1)
    7. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.html b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.html new file mode 100644 index 0000000..35c2226 --- /dev/null +++ b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.html @@ -0,0 +1,91 @@ + + + + +#centos-devel log + + + + +
15:59:35 <quaid> #startmeeting
+15:59:35 <centbot> Meeting started Mon Feb 10 15:59:35 2014 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
+15:59:35 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+15:59:42 <Jeff_S> kbsingh: just sat down in a coffee shop
+15:59:48 <quaid> hey Jeff_S
+16:00:07 <Jeff_S> stealing wifi from the bar next door =/
+16:00:10 <kbsingh> jeff pm
+16:00:20 <quaid> #topic Agenda
+16:00:26 <quaid> Quick summary of what Google Summer of Code (GSoC) is.
+16:00:27 <quaid> Overview of what is possible to do with GSoC for CentOS.
+16:00:27 <quaid> What we have so far.
+16:00:27 <quaid> What we need to work on now (this week), next (following few weeks), and for the summer (full program length.)
+16:00:30 <quaid> How to be successful & work within this community
+16:00:40 <kbsingh> going live
+16:01:01 <Jeff_S> kbsingh: thanks
+16:01:08 <quaid> #topic Quick summary
+16:01:14 <Jeff_S> had to tether from my phone, back now
+16:02:11 <kbsingh> who has the player going as well ?
+16:02:40 <Evolution> not me.
+16:02:52 <kbsingh> there is a massive echo thing going on
+16:03:12 <Jeff_S> sound is fine for me
+16:03:22 <Jeff_S> (I'm on mute too cause it's kinda loud here)
+16:03:37 <tigalch> as a listener - sound is fine
+16:03:44 <kbsingh> ok
+16:07:36 <quaid> http://wiki.centos.org/GSoC/2014/Application
+16:13:11 <kbsingh> Jeff_S: good video link.. is that off your phone /
+16:13:51 <quaid> #idea time based tasks are not always the best idea
+16:14:03 <quaid> #idea don't put a student on a blocking component
+16:14:35 <quaid> #agreed must fit in to a discrete task
+16:15:10 <quaid> #idea the more we leave open for students to find something that is interesting to them, the more successful they more
+16:17:16 <quaid> #idea mentoring is also working on application process with students
+16:17:54 <kbsingh> #idea deliver a xen/centos6/image installer delivered
+16:18:02 <Jeff_S> kbsingh: yeah, I'm tethering over LTE (but not many bars)
+16:18:16 <Jeff_S> but I'm sitting at my laptop
+16:18:27 <kbsingh> #idea openstack livecd, pre-setup to run and scale in a diskless environ
+16:18:33 <Evolution> should we consider docker as something separate here?
+16:18:43 <kbsingh> Evolution: it could be included
+16:18:48 <Evolution> docker isn't exactly core to what we're doing, but it does tick many current boxes.
+16:18:51 <kbsingh> delivering docker dependancies would be awesome
+16:18:54 <Evolution> and it's not critical to what we're doing.
+16:19:11 <Evolution> #idea docker deps/images/projects
+16:19:36 <quaid> #chair Evolution kbsingh Jeff_S
+16:19:36 <centbot> Current chairs: Evolution Jeff_S kbsingh quaid
+16:19:47 <Evolution> doh
+16:19:49 <Evolution> #idea docker deps/images/projects
+16:19:57 <Evolution> that should be in there now then.
+16:21:12 <quaid> #idea different levels of tasks out there
+16:21:23 <quaid> right, have flexibility in the ideas
+16:21:41 <quaid> #agreed students may not have a good concept of what they can do -- push or reign them in
+16:21:41 <kbsingh> #idea build and automate the in-cloud update/managent infra
+16:21:44 <Evolution> does that email address on the wiki work? centos-gsoc-mentors ?
+16:22:00 <quaid> one engineering manager I worked with said, "Developers always say it will take 2 weeks."
+16:22:09 <kbsingh> quaid: 17 days
+16:24:10 <quaid> http://www.google-melange.com/gsoc/events/google/gsoc2014
+16:25:49 <kbsingh> #idea explore bootstrap for diff arch
+16:25:50 <quaid> #idea those with time to help the SIGs already can assist mentors
+16:30:59 <quaid> #idea open project ideas around ARM to interest hardware hackers
+16:31:14 <quaid> #action need to write a marketing plan
+16:31:48 <quaid> #action interested mentors to hang out on existing GSoC channel
+16:33:44 <kbsingh> cool, so are we all about getting done ?
+16:34:19 <Evolution> I think so.
+16:35:22 <quaid> #info expectations need to be set up front with students
+16:35:47 <quaid> http://en.flossmanuals.net/melange/org-application-period/
+16:37:29 <quaid> #endmeeting
+ diff --git a/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.txt b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.txt new file mode 100644 index 0000000..0e18313 --- /dev/null +++ b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.log.txt @@ -0,0 +1,64 @@ +15:59:35 #startmeeting +15:59:35 Meeting started Mon Feb 10 15:59:35 2014 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. +15:59:35 Useful Commands: #action #agreed #help #info #idea #link #topic. +15:59:42 kbsingh: just sat down in a coffee shop +15:59:48 hey Jeff_S +16:00:07 stealing wifi from the bar next door =/ +16:00:10 jeff pm +16:00:20 #topic Agenda +16:00:26 Quick summary of what Google Summer of Code (GSoC) is. +16:00:27 Overview of what is possible to do with GSoC for CentOS. +16:00:27 What we have so far. +16:00:27 What we need to work on now (this week), next (following few weeks), and for the summer (full program length.) +16:00:30 How to be successful & work within this community +16:00:40 going live +16:01:01 kbsingh: thanks +16:01:08 #topic Quick summary +16:01:14 had to tether from my phone, back now +16:02:11 who has the player going as well ? +16:02:40 not me. +16:02:52 there is a massive echo thing going on +16:03:12 sound is fine for me +16:03:22 (I'm on mute too cause it's kinda loud here) +16:03:37 as a listener - sound is fine +16:03:44 ok +16:07:36 http://wiki.centos.org/GSoC/2014/Application +16:13:11 Jeff_S: good video link.. is that off your phone / +16:13:51 #idea time based tasks are not always the best idea +16:14:03 #idea don't put a student on a blocking component +16:14:35 #agreed must fit in to a discrete task +16:15:10 #idea the more we leave open for students to find something that is interesting to them, the more successful they more +16:17:16 #idea mentoring is also working on application process with students +16:17:54 #idea deliver a xen/centos6/image installer delivered +16:18:02 kbsingh: yeah, I'm tethering over LTE (but not many bars) +16:18:16 but I'm sitting at my laptop +16:18:27 #idea openstack livecd, pre-setup to run and scale in a diskless environ +16:18:33 should we consider docker as something separate here? +16:18:43 Evolution: it could be included +16:18:48 docker isn't exactly core to what we're doing, but it does tick many current boxes. +16:18:51 delivering docker dependancies would be awesome +16:18:54 and it's not critical to what we're doing. +16:19:11 #idea docker deps/images/projects +16:19:36 #chair Evolution kbsingh Jeff_S +16:19:36 Current chairs: Evolution Jeff_S kbsingh quaid +16:19:47 doh +16:19:49 #idea docker deps/images/projects +16:19:57 that should be in there now then. +16:21:12 #idea different levels of tasks out there +16:21:23 right, have flexibility in the ideas +16:21:41 #agreed students may not have a good concept of what they can do -- push or reign them in +16:21:41 #idea build and automate the in-cloud update/managent infra +16:21:44 does that email address on the wiki work? centos-gsoc-mentors ? +16:22:00 one engineering manager I worked with said, "Developers always say it will take 2 weeks." +16:22:09 quaid: 17 days +16:24:10 http://www.google-melange.com/gsoc/events/google/gsoc2014 +16:25:49 #idea explore bootstrap for diff arch +16:25:50 #idea those with time to help the SIGs already can assist mentors +16:30:59 #idea open project ideas around ARM to interest hardware hackers +16:31:14 #action need to write a marketing plan +16:31:48 #action interested mentors to hang out on existing GSoC channel +16:33:44 cool, so are we all about getting done ? +16:34:19 I think so. +16:35:22 #info expectations need to be set up front with students +16:35:47 http://en.flossmanuals.net/melange/org-application-period/ +16:37:29 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/february/centos-devel.2014-02-10-15.59.txt b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.txt new file mode 100644 index 0000000..51a0b14 --- /dev/null +++ b/static/minutes/2014/february/centos-devel.2014-02-10-15.59.txt @@ -0,0 +1,89 @@ +===================== +#centos-devel Meeting +===================== + + +Meeting started by quaid at 15:59:35 UTC. The full logs are available at +centos-devel/2014/centos-devel.2014-02-10-15.59.log.html . + + + +Meeting summary +--------------- +* Agenda (quaid, 16:00:20) + +* Quick summary (quaid, 16:01:08) + * LINK: http://wiki.centos.org/GSoC/2014/Application (quaid, + 16:07:36) + * IDEA: time based tasks are not always the best idea (quaid, + 16:13:51) + * IDEA: don't put a student on a blocking component (quaid, 16:14:03) + * AGREED: must fit in to a discrete task (quaid, 16:14:35) + * IDEA: the more we leave open for students to find something that is + interesting to them, the more successful they more (quaid, + 16:15:10) + * IDEA: mentoring is also working on application process with students + (quaid, 16:17:16) + * IDEA: deliver a xen/centos6/image installer delivered (kbsingh, + 16:17:54) + * IDEA: openstack livecd, pre-setup to run and scale in a diskless + environ (kbsingh, 16:18:27) + * IDEA: docker deps/images/projects (Evolution, 16:19:11) + * IDEA: docker deps/images/projects (Evolution, 16:19:49) + * IDEA: different levels of tasks out there (quaid, 16:21:12) + * AGREED: students may not have a good concept of what they can do -- + push or reign them in (quaid, 16:21:41) + * IDEA: build and automate the in-cloud update/managent infra + (kbsingh, 16:21:41) + * LINK: http://www.google-melange.com/gsoc/events/google/gsoc2014 + (quaid, 16:24:10) + * IDEA: explore bootstrap for diff arch (kbsingh, 16:25:49) + * IDEA: those with time to help the SIGs already can assist mentors + (quaid, 16:25:50) + * IDEA: open project ideas around ARM to interest hardware hackers + (quaid, 16:30:59) + * ACTION: need to write a marketing plan (quaid, 16:31:14) + * ACTION: interested mentors to hang out on existing GSoC channel + (quaid, 16:31:48) + * expectations need to be set up front with students (quaid, + 16:35:22) + * LINK: http://en.flossmanuals.net/melange/org-application-period/ + (quaid, 16:35:47) + +Meeting ended at 16:37:29 UTC. + + + + +Action Items +------------ +* need to write a marketing plan +* interested mentors to hang out on existing GSoC channel + + + + +Action Items, by person +----------------------- +* **UNASSIGNED** + * need to write a marketing plan + * interested mentors to hang out on existing GSoC channel + + + + +People Present (lines said) +--------------------------- +* quaid (28) +* kbsingh (14) +* Evolution (10) +* Jeff_S (8) +* centbot (3) +* tigalch (1) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/january/centos-devel.2014-01-23-16.20.html b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.html new file mode 100644 index 0000000..7794580 --- /dev/null +++ b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.html @@ -0,0 +1,186 @@ + + + + +#centos-devel Meeting + + + + +

#centos-devel Meeting

+ +Meeting started by quaid at 16:20:21 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. around Java jars, all that matters is + redistributability -- if you want to maintain N jars for your users, + that's up to you (quaid, + 16:20:53)
      2. +
    2. IDEA: branding forum to + discuss and resolve, cf. fedora-legal list (quaid, + 16:21:45)
      3. +
    3. ACTION: quaid to talk + with fontana about branding forum (quaid, + 16:22:09)
      4. +
    4. breaking out CLoud Infra and Instance as + different SIGs (quaid, + 16:26:18)
      5. +
    5. yes, oVirt is distributed via RPMs (quaid, + 16:27:12)
      6. +
    6. http://wiki.centos.org/SpecialInterestGroup/CloudInstance + (kbsingh, + 16:27:27)
      7. +
    7. ROD users either packstack or foreman as + separate installers (puppet underneath) (quaid, + 16:27:40)
      8. +
    8. AGREED: worth working + on a pushbutton ISO tool as part of the CentOS Project (quaid, + 16:47:24)
      9. +
    9. IDEA: have upstream + merit be the basis for who gets commit access, rather than CentOS + having to track it (quaid, + 16:49:04)
      10. +
    10. IDEA: within CentOS + Project tools, have it be possible for someone in the SIG to get + tired of greenlighting patches from a known good person, so proposes + that person to the SIG for commit access directly -- this would + happen outside of the upstream's own contributor growth + pathway (quaid, + 16:50:51)
      11. +
    11. the livecd and image from git stuff already + works, so we dont need to block on other stuff. its a simple low + hanging fruit thing that we can use to setup a relationship + with (quaid, + 16:52:13)
      12. +
    12. IDEA: Seed a few + committers to git.centos.org from each upstream, add new commiters + as per $formula_to_be_determined but which could be a combination of + merit-within-CentOS and merit-within-$upstream (quaid, + 16:54:05)
      13. +
    13. IDEA: handle + organically, don't sweat (quaid, + 16:54:41)
      14. +
    14. AGREED: CentOS is + using the meritocracy spotlight, somehow :) (quaid, + 16:54:55)
      15. +
    +
    2. +
+

+ + + + +Meeting ended at 17:17:32 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. quaid to talk with fontana about branding forum
    2. +
+

+ + + +

Action items, by person

+
    +
  1. quaid
      +
    1. quaid to talk with fontana about branding forum
      2. +
    2. +
+

+ + + +

People present (lines said)

+
    +
  1. quaid (43)
    2. +
  2. goozbach (14)
    3. +
  3. kbsingh (9)
    4. +
  4. jzb (6)
    5. +
  5. Evolution (6)
    6. +
  6. centbot (5)
    7. +
  7. hughesjr (5)
    8. +
  8. mburned (5)
    9. +
  9. DrBacchus (5)
    10. +
  10. Bahhumbug (4)
    11. +
  11. mikem23 (3)
    12. +
  12. pixelb (2)
    13. +
  13. samkottler (0)
    14. +
  14. ke4qqq (0)
    15. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.html b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.html new file mode 100644 index 0000000..53cbef7 --- /dev/null +++ b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.html @@ -0,0 +1,134 @@ + + + + +#centos-devel log + + + + +
16:20:21 <quaid> #startmeeting
+16:20:21 <centbot> Meeting started Thu Jan 23 16:20:21 2014 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
+16:20:21 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+16:20:53 <quaid> #info around Java jars, all that matters is redistributability -- if you want to maintain N jars for your users, that's up to you
+16:21:45 <quaid> #idea branding forum to discuss and resolve, cf. fedora-legal list
+16:22:09 <quaid> #action quaid to talk with fontana about branding forum
+16:22:20 <quaid> anyone else who wants to help keep notes from the meeting, go ahead
+16:22:31 <quaid> I'm not sure where the logs write to yet ...
+16:23:00 <DrBacchus> You'll get a URL when you end the meeting.
+16:23:17 <DrBacchus> Several of them, in fact.
+16:23:27 <goozbach> quaid: you'll need to add whoever wants to add notes to #chair
+16:23:50 <quaid> right, the last one I saw from output didn't show the full URL just the local path, not sure what host it's on in other words
+16:24:12 <quaid> goozbach: I think anyone can do #idea and #info, only #agreed and #topic and a few others are saved to chair iirc
+16:25:12 <Evolution> we ( Bahhumbug ) will be improving centbot in the coming days, so there should be some additional improvements
+16:25:20 <DrBacchus> Someone needs to mute.
+16:25:27 <goozbach> There definately is a call for something around rebrandability/interoperability SIG
+16:26:02 <goozbach> Evolution: I've got a patch for meetbot which sends email to a list when finished
+16:26:05 <goozbach> if you're interested
+16:26:18 <quaid> #info breaking out CLoud Infra and Instance as different SIGs
+16:26:55 <quaid> goozbach: that sounds great, my least favorite part of it is having to construct that email at the end :)
+16:27:04 <mburned> does the cloud instance sig exist yet?
+16:27:12 <kbsingh> mburned: yes
+16:27:12 <quaid> #info yes, oVirt is distributed via RPMs
+16:27:13 <pixelb> Yes RDO uses either packstack or foreman as separate installers (puppet underneath)
+16:27:14 * mburned probably needs to pay attention to that too
+16:27:27 <kbsingh> http://wiki.centos.org/SpecialInterestGroup/CloudInstance
+16:27:38 <mburned> kbsingh: thanks
+16:27:40 <quaid> #info ROD users either packstack or foreman as separate installers (puppet underneath)
+16:28:45 <hughesjr> ok, so then for the most part, people just want content installed and then configured later
+16:29:28 <hughesjr> that lends itself to these SIGs just being repos and no changes to anaconda or isos
+16:29:46 <pixelb> hughesjr, I concur
+16:30:21 <hughesjr> that makes the delivery system much easier if we can get away with it
+16:30:25 <kbsingh> yea
+16:30:36 <mburned> i might argue that adding additional repos and/or pre-defined package sets might be useful
+16:30:36 <kbsingh> but that would need to fit into the overall scope
+16:30:41 <DrBacchus> And then variants - liveCDs, perhaps - of preconfigured systems, like the RDO one.
+16:30:42 <Evolution> goozbach: yes please, or send it off as a pull request on github
+16:31:18 <goozbach> for the voip sig (at least for FreePBX) we want an easier way to rebrand/re-relase isos/anaconda
+16:31:37 <mburned> DrBacchus: right
+16:32:09 <goozbach> I think the hardest part of getting a custom "installer" is the lack of documentation/tools on how to create a new spin
+16:32:23 <kbsingh> goozbach: i disagree
+16:32:47 <Bahhumbug> goozbach: Any information you can provide me regarding that patch would be welcome.
+16:33:38 <quaid> ke4qqq: another trick of having your bits in a central yum repo is that, if Foo is in git.centos.org, Foo can be called CentOS - this resolves the question that gregdek had earlier, right?
+16:33:54 <goozbach> kbsingh: ok well the "how" isn't too bad it's the "what" needs to changed to comply with trademark issues
+16:34:07 <quaid> ke4qqq: we're looking at a future leg of the community build system that is Coprs-like - either user Coprs or build it in to Koji, for example
+16:34:13 <goozbach> Bahhumbug, Evolution I'll have the patch up on github shortly
+16:34:25 <Bahhumbug> goozbach: Thank you.
+16:34:47 <Evolution> goozbach: yes. thank you. the more work I can pile on Bahhumbug the better
+16:34:48 <Evolution> :-P
+16:34:59 * Bahhumbug hides
+16:35:14 <quaid> ke4qqq: meaning, we can lower the barrier to doing scratch builds from accepted source, making those repos available, etc.
+16:39:46 <quaid> yeah, folks are already doing all this ship and support bundled libs, not going to be any harder to do in CentOS
+16:41:35 <goozbach> Bahhumbug: Evolution the code as-is is here: https://github.com/gooseproject/meetbot/blob/master/ircmeeting/meeting.py
+16:41:50 <goozbach> don't have a good pull request as it's spread across three different commits
+16:42:12 <goozbach> and I don't have time to re-do it as proper branch/and --squash
+16:44:46 <mikem23> Koji supports building with Maven actually
+16:44:57 <mikem23> though the feature is not used the the Fedora instance
+16:45:47 <Bahhumbug> goozbach: Thank you.
+16:46:09 <quaid> I missed that
+16:46:12 <quaid> what is the common thing therre?
+16:46:23 <quaid> #chair Evolution
+16:46:23 <centbot> Current chairs: Evolution quaid
+16:47:00 <quaid> what was the question KB just got +1 all around for?
+16:47:02 <goozbach> we'd (FreePBX) like the that pushbutton iso dealio too
+16:47:03 <quaid> something about live CD?
+16:47:06 <quaid> ah
+16:47:24 <quaid> #agreed worth working on a pushbutton ISO tool as part of the CentOS Project
+16:48:48 <mikem23> koji also supports building livecds and virt images
+16:49:04 <quaid> #idea have upstream merit be the basis for who gets commit access, rather than CentOS having to track it
+16:49:13 <hughesjr> mikem23: well then set it up :D
+16:50:51 <quaid> #idea within CentOS Project tools, have it be possible for someone in the SIG to get tired of greenlighting patches from a known good person, so proposes that person to the SIG for commit access directly -- this would happen outside of the upstream's own contributor growth pathway
+16:50:59 <quaid> jzb: is the above fair?
+16:51:08 <Evolution> lets get some authentication in place, so that we can do much of this.
+16:51:15 <quaid> #chair jzb ke4qqq mikem23 samkottler
+16:51:15 <centbot> Current chairs: Evolution jzb ke4qqq mikem23 quaid samkottler
+16:51:17 <Evolution> quite a bit of what we're dealing with depends on auth.
+16:51:20 <jzb> quaid: yes
+16:51:24 <quaid> #chair mburned
+16:51:24 <centbot> Current chairs: Evolution jzb ke4qqq mburned mikem23 quaid samkottler
+16:51:44 <kbsingh> the livecd and image from git stuff already works, so we dont need to block on other stuff. its a simple low hanging fruit thing that we can use to setup a relationship with
+16:52:13 <quaid> #info the livecd and image from git stuff already works, so we dont need to block on other stuff. its a simple low hanging fruit thing that we can use to setup a relationship with
+16:53:08 <quaid> ke4qqq: jzb I think we don't have consensus on how to handle merit and commit access to git.centos.org, I suspect it will be a blend of those two ideas; let's continue that discussion in The Usual Places
+16:53:41 <jzb> quaid: might be something to handle organically?
+16:53:55 <jzb> quaid:  as it happens, rather than trying to put all the ideas in place day one?
+16:53:58 <jzb> (day one-ish)
+16:54:05 <quaid> #idea Seed a few committers to git.centos.org from each upstream, add new commiters as per $formula_to_be_determined but which could be a combination of merit-within-CentOS and merit-within-$upstream
+16:54:24 <quaid> jzb: +1 sure, i.e., no-new-thread-needed :)
+16:54:41 <quaid> #idea handle organically, don't sweat
+16:54:55 <quaid> #agreed CentOS is using the meritocracy spotlight, somehow :)
+16:55:25 <goozbach> <-- doing anaconda "stuff" now
+16:56:12 <quaid> sounds like an episode of "Dirty Jobs"
+16:56:55 <hughesjr> :)
+16:57:59 <jzb> quaid, kbsingh is there any thought to creating SIG-specific mailing lists?
+16:58:16 <quaid> jzb: I think we were going to start on devel and split if needd
+16:58:21 <DrBacchus> jzb: As I understood it, it'll be on centos-devel until it gets too noisy.
+16:58:24 <quaid> it's been a rather quiet list
+16:58:33 <quaid> kbsingh: can I help you with getting your notes in to this meetbot instance now?
+16:58:36 <goozbach> quaid: it is a dirty job
+16:59:02 <quaid> DrBacchus: yeah, I refer to that as "standard operating procedure" - wait until it's annoying, then split :)
+16:59:05 <kbsingh> jzb: yes, once the SIG needs it and there is traffic that is SIG specific, lets mailing list it ( eg. CentOS-Virt is a list )
+17:00:43 <jzb> kbsingh: gotcha
+17:03:33 <quaid> kbsingh: do you have any notes for the meeting before I close it?
+17:03:49 <kbsingh> quaid: just that i will write up notes from the call, and propose
+17:10:54 <quaid> kbsingh: OK
+17:10:58 <quaid> closing the meeting in a moment
+17:13:15 <kbsingh> quaid: ta
+17:17:32 <quaid> #endmeeting
+ diff --git a/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.txt b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.txt new file mode 100644 index 0000000..8dc7fb3 --- /dev/null +++ b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.log.txt @@ -0,0 +1,107 @@ +16:20:21 #startmeeting +16:20:21 Meeting started Thu Jan 23 16:20:21 2014 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. +16:20:21 Useful Commands: #action #agreed #help #info #idea #link #topic. +16:20:53 #info around Java jars, all that matters is redistributability -- if you want to maintain N jars for your users, that's up to you +16:21:45 #idea branding forum to discuss and resolve, cf. fedora-legal list +16:22:09 #action quaid to talk with fontana about branding forum +16:22:20 anyone else who wants to help keep notes from the meeting, go ahead +16:22:31 I'm not sure where the logs write to yet ... +16:23:00 You'll get a URL when you end the meeting. +16:23:17 Several of them, in fact. +16:23:27 quaid: you'll need to add whoever wants to add notes to #chair +16:23:50 right, the last one I saw from output didn't show the full URL just the local path, not sure what host it's on in other words +16:24:12 goozbach: I think anyone can do #idea and #info, only #agreed and #topic and a few others are saved to chair iirc +16:25:12 we ( Bahhumbug ) will be improving centbot in the coming days, so there should be some additional improvements +16:25:20 Someone needs to mute. +16:25:27 There definately is a call for something around rebrandability/interoperability SIG +16:26:02 Evolution: I've got a patch for meetbot which sends email to a list when finished +16:26:05 if you're interested +16:26:18 #info breaking out CLoud Infra and Instance as different SIGs +16:26:55 goozbach: that sounds great, my least favorite part of it is having to construct that email at the end :) +16:27:04 does the cloud instance sig exist yet? +16:27:12 mburned: yes +16:27:12 #info yes, oVirt is distributed via RPMs +16:27:13 Yes RDO uses either packstack or foreman as separate installers (puppet underneath) +16:27:14 * mburned probably needs to pay attention to that too +16:27:27 http://wiki.centos.org/SpecialInterestGroup/CloudInstance +16:27:38 kbsingh: thanks +16:27:40 #info ROD users either packstack or foreman as separate installers (puppet underneath) +16:28:45 ok, so then for the most part, people just want content installed and then configured later +16:29:28 that lends itself to these SIGs just being repos and no changes to anaconda or isos +16:29:46 hughesjr, I concur +16:30:21 that makes the delivery system much easier if we can get away with it +16:30:25 yea +16:30:36 i might argue that adding additional repos and/or pre-defined package sets might be useful +16:30:36 but that would need to fit into the overall scope +16:30:41 And then variants - liveCDs, perhaps - of preconfigured systems, like the RDO one. +16:30:42 goozbach: yes please, or send it off as a pull request on github +16:31:18 for the voip sig (at least for FreePBX) we want an easier way to rebrand/re-relase isos/anaconda +16:31:37 DrBacchus: right +16:32:09 I think the hardest part of getting a custom "installer" is the lack of documentation/tools on how to create a new spin +16:32:23 goozbach: i disagree +16:32:47 goozbach: Any information you can provide me regarding that patch would be welcome. +16:33:38 ke4qqq: another trick of having your bits in a central yum repo is that, if Foo is in git.centos.org, Foo can be called CentOS - this resolves the question that gregdek had earlier, right? +16:33:54 kbsingh: ok well the "how" isn't too bad it's the "what" needs to changed to comply with trademark issues +16:34:07 ke4qqq: we're looking at a future leg of the community build system that is Coprs-like - either user Coprs or build it in to Koji, for example +16:34:13 Bahhumbug, Evolution I'll have the patch up on github shortly +16:34:25 goozbach: Thank you. +16:34:47 goozbach: yes. thank you. the more work I can pile on Bahhumbug the better +16:34:48 :-P +16:34:59 * Bahhumbug hides +16:35:14 ke4qqq: meaning, we can lower the barrier to doing scratch builds from accepted source, making those repos available, etc. +16:39:46 yeah, folks are already doing all this ship and support bundled libs, not going to be any harder to do in CentOS +16:41:35 Bahhumbug: Evolution the code as-is is here: https://github.com/gooseproject/meetbot/blob/master/ircmeeting/meeting.py +16:41:50 don't have a good pull request as it's spread across three different commits +16:42:12 and I don't have time to re-do it as proper branch/and --squash +16:44:46 Koji supports building with Maven actually +16:44:57 though the feature is not used the the Fedora instance +16:45:47 goozbach: Thank you. +16:46:09 I missed that +16:46:12 what is the common thing therre? +16:46:23 #chair Evolution +16:46:23 Current chairs: Evolution quaid +16:47:00 what was the question KB just got +1 all around for? +16:47:02 we'd (FreePBX) like the that pushbutton iso dealio too +16:47:03 something about live CD? +16:47:06 ah +16:47:24 #agreed worth working on a pushbutton ISO tool as part of the CentOS Project +16:48:48 koji also supports building livecds and virt images +16:49:04 #idea have upstream merit be the basis for who gets commit access, rather than CentOS having to track it +16:49:13 mikem23: well then set it up :D +16:50:51 #idea within CentOS Project tools, have it be possible for someone in the SIG to get tired of greenlighting patches from a known good person, so proposes that person to the SIG for commit access directly -- this would happen outside of the upstream's own contributor growth pathway +16:50:59 jzb: is the above fair? +16:51:08 lets get some authentication in place, so that we can do much of this. +16:51:15 #chair jzb ke4qqq mikem23 samkottler +16:51:15 Current chairs: Evolution jzb ke4qqq mikem23 quaid samkottler +16:51:17 quite a bit of what we're dealing with depends on auth. +16:51:20 quaid: yes +16:51:24 #chair mburned +16:51:24 Current chairs: Evolution jzb ke4qqq mburned mikem23 quaid samkottler +16:51:44 the livecd and image from git stuff already works, so we dont need to block on other stuff. its a simple low hanging fruit thing that we can use to setup a relationship with +16:52:13 #info the livecd and image from git stuff already works, so we dont need to block on other stuff. its a simple low hanging fruit thing that we can use to setup a relationship with +16:53:08 ke4qqq: jzb I think we don't have consensus on how to handle merit and commit access to git.centos.org, I suspect it will be a blend of those two ideas; let's continue that discussion in The Usual Places +16:53:41 quaid: might be something to handle organically? +16:53:55 quaid: as it happens, rather than trying to put all the ideas in place day one? +16:53:58 (day one-ish) +16:54:05 #idea Seed a few committers to git.centos.org from each upstream, add new commiters as per $formula_to_be_determined but which could be a combination of merit-within-CentOS and merit-within-$upstream +16:54:24 jzb: +1 sure, i.e., no-new-thread-needed :) +16:54:41 #idea handle organically, don't sweat +16:54:55 #agreed CentOS is using the meritocracy spotlight, somehow :) +16:55:25 <-- doing anaconda "stuff" now +16:56:12 sounds like an episode of "Dirty Jobs" +16:56:55 :) +16:57:59 quaid, kbsingh is there any thought to creating SIG-specific mailing lists? +16:58:16 jzb: I think we were going to start on devel and split if needd +16:58:21 jzb: As I understood it, it'll be on centos-devel until it gets too noisy. +16:58:24 it's been a rather quiet list +16:58:33 kbsingh: can I help you with getting your notes in to this meetbot instance now? +16:58:36 quaid: it is a dirty job +16:59:02 DrBacchus: yeah, I refer to that as "standard operating procedure" - wait until it's annoying, then split :) +16:59:05 jzb: yes, once the SIG needs it and there is traffic that is SIG specific, lets mailing list it ( eg. CentOS-Virt is a list ) +17:00:43 kbsingh: gotcha +17:03:33 kbsingh: do you have any notes for the meeting before I close it? +17:03:49 quaid: just that i will write up notes from the call, and propose +17:10:54 kbsingh: OK +17:10:58 closing the meeting in a moment +17:13:15 quaid: ta +17:17:32 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/january/centos-devel.2014-01-23-16.20.txt b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.txt new file mode 100644 index 0000000..4585f16 --- /dev/null +++ b/static/minutes/2014/january/centos-devel.2014-01-23-16.20.txt @@ -0,0 +1,91 @@ +===================== +#centos-devel Meeting +===================== + + +Meeting started by quaid at 16:20:21 UTC. The full logs are available at +centos-devel/2014/centos-devel.2014-01-23-16.20.log.html . + + + +Meeting summary +--------------- +* around Java jars, all that matters is redistributability -- if you + want to maintain N jars for your users, that's up to you (quaid, + 16:20:53) +* IDEA: branding forum to discuss and resolve, cf. fedora-legal list + (quaid, 16:21:45) +* ACTION: quaid to talk with fontana about branding forum (quaid, + 16:22:09) +* breaking out CLoud Infra and Instance as different SIGs (quaid, + 16:26:18) +* yes, oVirt is distributed via RPMs (quaid, 16:27:12) +* LINK: http://wiki.centos.org/SpecialInterestGroup/CloudInstance + (kbsingh, 16:27:27) +* ROD users either packstack or foreman as separate installers (puppet + underneath) (quaid, 16:27:40) +* AGREED: worth working on a pushbutton ISO tool as part of the CentOS + Project (quaid, 16:47:24) +* IDEA: have upstream merit be the basis for who gets commit access, + rather than CentOS having to track it (quaid, 16:49:04) +* IDEA: within CentOS Project tools, have it be possible for someone in + the SIG to get tired of greenlighting patches from a known good + person, so proposes that person to the SIG for commit access directly + -- this would happen outside of the upstream's own contributor growth + pathway (quaid, 16:50:51) +* the livecd and image from git stuff already works, so we dont need to + block on other stuff. its a simple low hanging fruit thing that we can + use to setup a relationship with (quaid, 16:52:13) +* IDEA: Seed a few committers to git.centos.org from each upstream, add + new commiters as per $formula_to_be_determined but which could be a + combination of merit-within-CentOS and merit-within-$upstream (quaid, + 16:54:05) +* IDEA: handle organically, don't sweat (quaid, 16:54:41) +* AGREED: CentOS is using the meritocracy spotlight, somehow :) (quaid, + 16:54:55) + +Meeting ended at 17:17:32 UTC. + + + + +Action Items +------------ +* quaid to talk with fontana about branding forum + + + + +Action Items, by person +----------------------- +* quaid + * quaid to talk with fontana about branding forum +* **UNASSIGNED** + * (none) + + + + +People Present (lines said) +--------------------------- +* quaid (43) +* goozbach (14) +* kbsingh (9) +* jzb (6) +* Evolution (6) +* centbot (5) +* hughesjr (5) +* mburned (5) +* DrBacchus (5) +* Bahhumbug (4) +* mikem23 (3) +* pixelb (2) +* samkottler (0) +* ke4qqq (0) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/march/centos-devel.2014-03-05-21.04.html b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.html new file mode 100644 index 0000000..ea7ce78 --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.html @@ -0,0 +1,204 @@ + + + + +#centos-devel: CentOS Board public meeting + + + + +

#centos-devel: CentOS Board public meeting

+ +Meeting started by quaid at 21:04:16 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. Core S (quaid, 21:07:11) +
    2. +
  2. Core SIG (quaid, 21:07:19) +
      +
    1. although RHEL 7 upstream isn't doing a 32-bit + build, we have reason to do it as part of building the main + distro. (quaid, + 21:08:39)
      2. +
    2. IDEA: 32-bit is part of + Core SIG (quaid, + 21:08:44)
      3. +
    3. IDEA: or 32-bit is it's + own SIG (quaid, + 21:08:49)
      4. +
    4. for 64-bit we don't need to build 32-bit ISOs, + make sure installs work, and make sure kernels work (quaid, + 21:09:37)
      5. +
    5. IDEA: we could do most + of the work in the Core SIG and have the 32-bit SIG focus on the + final ISO building and testing (quaid, + 21:09:54)
      6. +
    6. AGREED: Core SIG can + produce 32-bit RPMs, and 32-bit SIG can focus on building and + testing ISOs; as that SIG gains merit they can gain more access to + do the work; all of the work could be tested as part of the + QA. (quaid, + 21:16:42)
      7. +
    +
    3. +
  3. Virt SIG proposal (quaid, 21:17:09) +
      +
    1. Virt SIG would be for all + virtualization-related updated software needs, bootstrapping with + Xen (quaid, + 21:25:36)
      2. +
    2. IDEA: SIGs should look + to the common e.g. qemu in Virt SIG (even to maybe carry a patch for + them) before carrying their own variation of a package in their own + SIG (quaid, + 21:30:39)
      3. +
    3. IDEA: make it so + everyone can consume from central (quaid, + 21:31:02)
      4. +
    4. IDEA: Virt SIG could be + a good place for carrying the latest upstream KVM for those who want + it (quaid, + 21:31:25)
      5. +
    5. Virt SIG will also need to carry a new + libvirt (quaid, + 21:32:17)
      6. +
    6. http://wiki.centos.org/SpecialInterestGroup/Core + (quaid, + 21:32:57)
      7. +
    7. ACTION: Core SIG + needs to update it's charter & run that by the Board + (quaid, + 21:36:12)
      8. +
    8. 'CentOS' in the Core SIG description means + "CentOS Linux, controls everything not done by other SIGs, is the + core OS" (quaid, + 21:40:25)
      9. +
    9. IDEA: have an Infra SIG + that takes the infrastructure management work off the hands of the + Core SIG, who can then maintian just the build system (or systems + for the community builders) (quaid, + 21:41:38)
      10. +
    10. AGREED: tentatively + agreed to approve Virt SIG proposal as new charter, upcoming content + on the Wiki; need to get input from Tru (quaid, + 21:50:37)
      11. +
    +
    4. +
  4. Any other business? (quaid, 21:50:43) +
      +
    1. In general, we'll be able to bring up + functional SIGs e.g. Documentation, QA, Promo, Artwork, etc.; have a + dependency on an auth system to share resources granularly v. + all-or-nothing (quaid, + 21:56:23)
      2. +
    2. Jim Perrin has been working with FreeIPA and + Fedora Auth System (FAS) to see how they compare; FreeIPA looks + really nice & would be a good reference story; FAS has all the + features we need but is really customized. (quaid, + 22:00:49)
      3. +
    +
    5. +
+

+ + + + +Meeting ended at 22:03:45 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. Core SIG needs to update it's charter & run that by the Board
    2. +
+

+ + + +

People present (lines said)

+
    +
  1. quaid (41)
    2. +
  2. Evolution (15)
    3. +
  3. toracat (12)
    4. +
  4. hughesjr (9)
    5. +
  5. range (4)
    6. +
  6. csieh (4)
    7. +
  7. centbot (3)
    8. +
  8. kbsingh (2)
    9. +
  9. ccmolik (1)
    10. +
  10. Arrfab (1)
    11. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.html b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.html new file mode 100644 index 0000000..ac01173 --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.html @@ -0,0 +1,119 @@ + + + + +#centos-devel log + + + + +
21:04:16 <quaid> #startmeeting CentOS Board public meeting
+21:04:16 <centbot> Meeting started Wed Mar  5 21:04:16 2014 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
+21:04:16 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+21:07:11 <quaid> #topic Core S
+21:07:19 <quaid> #topic Core SIG
+21:07:36 * quaid thinks that is in the log although centbot doesn't have OPs to change the local channel topic
+21:08:39 <quaid> #info although RHEL 7 upstream isn't doing a 32-bit build, we have reason to do it as part of building the main distro.
+21:08:44 <quaid> #idea 32-bit is part of Core SIG
+21:08:49 <quaid> #idea or 32-bit is it's own SIG
+21:09:37 <quaid> #info for 64-bit we don't need to build 32-bit ISOs, make sure installs work, and make sure kernels work
+21:09:54 <quaid> #idea we could do most of the work in the Core SIG and have the 32-bit SIG focus on the final ISO building and testing
+21:16:42 <quaid> #agreed Core SIG can produce 32-bit RPMs, and 32-bit SIG can focus on building and testing ISOs; as that SIG gains merit they can gain more access to do the work; all of the work could be tested as part of the QA.
+21:17:09 <quaid> #topic Virt SIG proposal
+21:25:36 <quaid> #info Virt SIG would be for all virtualization-related updated software needs, bootstrapping with Xen
+21:30:39 <quaid> #idea SIGs should look to the common e.g. qemu in Virt SIG (even to maybe carry a patch for them) before carrying their own variation of a package in their own SIG
+21:31:02 <quaid> #idea make it so everyone can consume from central
+21:31:25 <quaid> #idea Virt SIG could be a good place for carrying the latest upstream KVM for those who want it
+21:31:47 <hughesjr> also a new libvirt is going to be needed
+21:31:56 <ccmolik> +1 on new kvm shinynes
+21:32:14 <csieh> So is there a "charter" for what the Core SIG should do
+21:32:17 <quaid> #info Virt SIG will also need to carry a new libvirt
+21:32:31 <quaid> hughesjr: was that an accurate capture of your statement?
+21:32:53 <hughesjr> yes
+21:32:55 <quaid> csieh: this is the best for now:
+21:32:57 <quaid> http://wiki.centos.org/SpecialInterestGroup/Core
+21:33:12 <quaid> but it could be updated, such as to include the 32-bit discussion for Cent 7
+21:34:15 <Evolution> csieh: is there something in that you'd like to see updated or changed?
+21:35:38 <csieh> just would like the goal to be documented,  if changed that is ok just need to document it so others can know what is going on
+21:36:12 <quaid> #action Core SIG needs to update it's charter & run that by the Board
+21:36:44 <csieh> so the above web page talks about CentOS,  so what really is CentOS as far as this discussion is concerned
+21:37:57 <Evolution> csieh: yeah, we need to word that loads better. I think it needs to reference the packages (and build requirements) for the upstream(rh) packages only.
+21:38:10 <kbsingh> so, CentOS Linux
+21:38:13 <hughesjr> it says CentOS Linux ... so it controls everything that is NON-SIG
+21:38:23 <hughesjr> or CoreOS
+21:39:09 <hughesjr> and manages all infrastructure owned by the project
+21:40:25 <quaid> #info 'CentOS' in the Core SIG description means "CentOS Linux, controls everything not done by other SIGs, is the core OS"
+21:40:43 <quaid> hughesjr: I thought we had the Infra SIG as a different SIG, with Core SIG maintaining the build system(s)?
+21:41:04 <hughesjr> we WILL have one, but not yet
+21:41:08 <quaid> in that I'd like us to be able to add people to Infra SIG without being part of the Core SIG - diff skillsets, merit criteria, etc.
+21:41:12 <quaid> hughesjr: ok, thanks
+21:41:38 <quaid> #idea have an Infra SIG that takes the infrastructure management work off the hands of the Core SIG, who can then maintian just the build system (or systems for the community builders)
+21:42:16 <toracat> who would maintain the source files through git.centos.org ?
+21:42:38 <Evolution> toracat: depends on which code you mean?
+21:42:47 <toracat> RHEL
+21:43:28 <Evolution> we would, the same/similar way we do so now in the private build setup. it'll be read-only and branched
+21:43:57 <Evolution> the rhel code would be able to be branched/forked etc. but  not edited.
+21:44:08 <toracat> we == Core SIG ?
+21:44:10 <hughesjr> the Core SIG will maintain the CentOS Linux source code in git.centos.org ... other SIGs will maintain their code in there
+21:44:19 <Evolution> toracat: yes.
+21:44:24 <toracat> thanks
+21:45:20 <Evolution> toracat: sorry. abusing the 'royal we'
+21:45:41 <toracat> :D
+21:45:43 <hughesjr> we is we and it is everyone who is not they :D
+21:46:30 <Evolution> toracat: good point/question though
+21:46:39 <toracat> I want to hear range talk :) he is too quiet
+21:47:04 <Arrfab> toracat: .eu people are silent and almost sleeping :-p
+21:47:06 <hughesjr> he is asleep
+21:47:17 <toracat> I see now
+21:48:58 <Evolution> $5 says range has a nice lager/ale beside him.
+21:49:02 <quaid> range looks a bit like a monk in his mini-vid inset pic
+21:49:58 <quaid> yeah, I want video voting cards
+21:50:37 <quaid> #agreed tentatively agreed to approve Virt SIG proposal as new charter, upcoming content on the Wiki; need to get input from Tru
+21:50:42 <Evolution> toracat: anything you'd like to hear covered?
+21:50:43 <quaid> #topic Any other business?
+21:50:53 <Evolution> csieh: you as well
+21:50:56 <toracat> Evolution: not for today
+21:51:26 <quaid> what do we want to do about the functional SIGs? e.g. QA in particular
+21:51:52 <csieh> no other business from me
+21:52:21 <toracat> csieh: hi, good to see you here :)
+21:56:18 <kbsingh> range looks very pensive
+21:56:23 <quaid> #info In general, we'll be able to bring up functional SIGs e.g. Documentation, QA, Promo, Artwork, etc.; have a dependency on an auth system to share resources granularly v. all-or-nothing
+21:58:08 <quaid> #info Jim Perring has been working with FreeIPA and Fedora Auth System (FAS) to see how they compare; FreeIPA looks really nice & would be a good reference story; FAS has all the features we need but is really customized.
+22:00:43 <quaid> #undo
+22:00:43 <centbot> Removing item from minutes: <MeetBot.items.Info object at 0x17c0f90>
+22:00:49 <quaid> #info Jim Perrin has been working with FreeIPA and Fedora Auth System (FAS) to see how they compare; FreeIPA looks really nice & would be a good reference story; FAS has all the features we need but is really customized.
+22:00:53 <quaid> hate when I do that to his name
+22:00:58 <Evolution> toracat: I'm sorry if I butched your name
+22:01:07 <toracat> close
+22:01:20 <quaid> btw, others can do #info, #idea, only Chairs can do #agreed, #undo
+22:01:27 <range> Okay, no hoodie next time :)
+22:01:27 <quaid> I'll pass out #chair next time
+22:01:31 <Evolution> toracat: phonetic spelling?
+22:01:36 <Evolution> toracat: how do I say it?
+22:01:45 <quaid> always a good idea to spread chair in case the meeting starter is netsplit
+22:01:48 <toracat> Evolution: yes. ah-keh-me
+22:01:59 <Evolution> ah, so no long ee sound.
+22:02:36 <range> Evolution: No, the lager is on the balcony.
+22:02:48 <range> (I might get one, though).
+22:02:48 <toracat> now range is awake
+22:03:06 <range> Yeah, completely missed this channel :)
+22:03:41 <quaid> ok, closing the minutes/log
+22:03:45 <quaid> #endmeeting
+ diff --git a/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.txt b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.txt new file mode 100644 index 0000000..9d4cebc --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.log.txt @@ -0,0 +1,92 @@ +21:04:16 #startmeeting CentOS Board public meeting +21:04:16 Meeting started Wed Mar 5 21:04:16 2014 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. +21:04:16 Useful Commands: #action #agreed #help #info #idea #link #topic. +21:07:11 #topic Core S +21:07:19 #topic Core SIG +21:07:36 * quaid thinks that is in the log although centbot doesn't have OPs to change the local channel topic +21:08:39 #info although RHEL 7 upstream isn't doing a 32-bit build, we have reason to do it as part of building the main distro. +21:08:44 #idea 32-bit is part of Core SIG +21:08:49 #idea or 32-bit is it's own SIG +21:09:37 #info for 64-bit we don't need to build 32-bit ISOs, make sure installs work, and make sure kernels work +21:09:54 #idea we could do most of the work in the Core SIG and have the 32-bit SIG focus on the final ISO building and testing +21:16:42 #agreed Core SIG can produce 32-bit RPMs, and 32-bit SIG can focus on building and testing ISOs; as that SIG gains merit they can gain more access to do the work; all of the work could be tested as part of the QA. +21:17:09 #topic Virt SIG proposal +21:25:36 #info Virt SIG would be for all virtualization-related updated software needs, bootstrapping with Xen +21:30:39 #idea SIGs should look to the common e.g. qemu in Virt SIG (even to maybe carry a patch for them) before carrying their own variation of a package in their own SIG +21:31:02 #idea make it so everyone can consume from central +21:31:25 #idea Virt SIG could be a good place for carrying the latest upstream KVM for those who want it +21:31:47 also a new libvirt is going to be needed +21:31:56 +1 on new kvm shinynes +21:32:14 So is there a "charter" for what the Core SIG should do +21:32:17 #info Virt SIG will also need to carry a new libvirt +21:32:31 hughesjr: was that an accurate capture of your statement? +21:32:53 yes +21:32:55 csieh: this is the best for now: +21:32:57 http://wiki.centos.org/SpecialInterestGroup/Core +21:33:12 but it could be updated, such as to include the 32-bit discussion for Cent 7 +21:34:15 csieh: is there something in that you'd like to see updated or changed? +21:35:38 just would like the goal to be documented, if changed that is ok just need to document it so others can know what is going on +21:36:12 #action Core SIG needs to update it's charter & run that by the Board +21:36:44 so the above web page talks about CentOS, so what really is CentOS as far as this discussion is concerned +21:37:57 csieh: yeah, we need to word that loads better. I think it needs to reference the packages (and build requirements) for the upstream(rh) packages only. +21:38:10 so, CentOS Linux +21:38:13 it says CentOS Linux ... so it controls everything that is NON-SIG +21:38:23 or CoreOS +21:39:09 and manages all infrastructure owned by the project +21:40:25 #info 'CentOS' in the Core SIG description means "CentOS Linux, controls everything not done by other SIGs, is the core OS" +21:40:43 hughesjr: I thought we had the Infra SIG as a different SIG, with Core SIG maintaining the build system(s)? +21:41:04 we WILL have one, but not yet +21:41:08 in that I'd like us to be able to add people to Infra SIG without being part of the Core SIG - diff skillsets, merit criteria, etc. +21:41:12 hughesjr: ok, thanks +21:41:38 #idea have an Infra SIG that takes the infrastructure management work off the hands of the Core SIG, who can then maintian just the build system (or systems for the community builders) +21:42:16 who would maintain the source files through git.centos.org ? +21:42:38 toracat: depends on which code you mean? +21:42:47 RHEL +21:43:28 we would, the same/similar way we do so now in the private build setup. it'll be read-only and branched +21:43:57 the rhel code would be able to be branched/forked etc. but not edited. +21:44:08 we == Core SIG ? +21:44:10 the Core SIG will maintain the CentOS Linux source code in git.centos.org ... other SIGs will maintain their code in there +21:44:19 toracat: yes. +21:44:24 thanks +21:45:20 toracat: sorry. abusing the 'royal we' +21:45:41 :D +21:45:43 we is we and it is everyone who is not they :D +21:46:30 toracat: good point/question though +21:46:39 I want to hear range talk :) he is too quiet +21:47:04 toracat: .eu people are silent and almost sleeping :-p +21:47:06 he is asleep +21:47:17 I see now +21:48:58 $5 says range has a nice lager/ale beside him. +21:49:02 range looks a bit like a monk in his mini-vid inset pic +21:49:58 yeah, I want video voting cards +21:50:37 #agreed tentatively agreed to approve Virt SIG proposal as new charter, upcoming content on the Wiki; need to get input from Tru +21:50:42 toracat: anything you'd like to hear covered? +21:50:43 #topic Any other business? +21:50:53 csieh: you as well +21:50:56 Evolution: not for today +21:51:26 what do we want to do about the functional SIGs? e.g. QA in particular +21:51:52 no other business from me +21:52:21 csieh: hi, good to see you here :) +21:56:18 range looks very pensive +21:56:23 #info In general, we'll be able to bring up functional SIGs e.g. Documentation, QA, Promo, Artwork, etc.; have a dependency on an auth system to share resources granularly v. all-or-nothing +21:58:08 #info Jim Perring has been working with FreeIPA and Fedora Auth System (FAS) to see how they compare; FreeIPA looks really nice & would be a good reference story; FAS has all the features we need but is really customized. +22:00:43 #undo +22:00:43 Removing item from minutes: +22:00:49 #info Jim Perrin has been working with FreeIPA and Fedora Auth System (FAS) to see how they compare; FreeIPA looks really nice & would be a good reference story; FAS has all the features we need but is really customized. +22:00:53 hate when I do that to his name +22:00:58 toracat: I'm sorry if I butched your name +22:01:07 close +22:01:20 btw, others can do #info, #idea, only Chairs can do #agreed, #undo +22:01:27 Okay, no hoodie next time :) +22:01:27 I'll pass out #chair next time +22:01:31 toracat: phonetic spelling? +22:01:36 toracat: how do I say it? +22:01:45 always a good idea to spread chair in case the meeting starter is netsplit +22:01:48 Evolution: yes. ah-keh-me +22:01:59 ah, so no long ee sound. +22:02:36 Evolution: No, the lager is on the balcony. +22:02:48 (I might get one, though). +22:02:48 now range is awake +22:03:06 Yeah, completely missed this channel :) +22:03:41 ok, closing the minutes/log +22:03:45 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/march/centos-devel.2014-03-05-21.04.txt b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.txt new file mode 100644 index 0000000..aedc4ca --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-05-21.04.txt @@ -0,0 +1,104 @@ +========================================== +#centos-devel: CentOS Board public meeting +========================================== + + +Meeting started by quaid at 21:04:16 UTC. The full logs are available at +centos-devel/2014/centos-devel.2014-03-05-21.04.log.html . + + + +Meeting summary +--------------- +* Core S (quaid, 21:07:11) + +* Core SIG (quaid, 21:07:19) + * although RHEL 7 upstream isn't doing a 32-bit build, we have reason + to do it as part of building the main distro. (quaid, 21:08:39) + * IDEA: 32-bit is part of Core SIG (quaid, 21:08:44) + * IDEA: or 32-bit is it's own SIG (quaid, 21:08:49) + * for 64-bit we don't need to build 32-bit ISOs, make sure installs + work, and make sure kernels work (quaid, 21:09:37) + * IDEA: we could do most of the work in the Core SIG and have the + 32-bit SIG focus on the final ISO building and testing (quaid, + 21:09:54) + * AGREED: Core SIG can produce 32-bit RPMs, and 32-bit SIG can focus + on building and testing ISOs; as that SIG gains merit they can gain + more access to do the work; all of the work could be tested as part + of the QA. (quaid, 21:16:42) + +* Virt SIG proposal (quaid, 21:17:09) + * Virt SIG would be for all virtualization-related updated software + needs, bootstrapping with Xen (quaid, 21:25:36) + * IDEA: SIGs should look to the common e.g. qemu in Virt SIG (even to + maybe carry a patch for them) before carrying their own variation of + a package in their own SIG (quaid, 21:30:39) + * IDEA: make it so everyone can consume from central (quaid, + 21:31:02) + * IDEA: Virt SIG could be a good place for carrying the latest + upstream KVM for those who want it (quaid, 21:31:25) + * Virt SIG will also need to carry a new libvirt (quaid, 21:32:17) + * LINK: http://wiki.centos.org/SpecialInterestGroup/Core (quaid, + 21:32:57) + * ACTION: Core SIG needs to update it's charter & run that by the + Board (quaid, 21:36:12) + * 'CentOS' in the Core SIG description means "CentOS Linux, controls + everything not done by other SIGs, is the core OS" (quaid, + 21:40:25) + * IDEA: have an Infra SIG that takes the infrastructure management + work off the hands of the Core SIG, who can then maintian just the + build system (or systems for the community builders) (quaid, + 21:41:38) + * AGREED: tentatively agreed to approve Virt SIG proposal as new + charter, upcoming content on the Wiki; need to get input from Tru + (quaid, 21:50:37) + +* Any other business? (quaid, 21:50:43) + * In general, we'll be able to bring up functional SIGs e.g. + Documentation, QA, Promo, Artwork, etc.; have a dependency on an + auth system to share resources granularly v. all-or-nothing (quaid, + 21:56:23) + * Jim Perrin has been working with FreeIPA and Fedora Auth System + (FAS) to see how they compare; FreeIPA looks really nice & would be + a good reference story; FAS has all the features we need but is + really customized. (quaid, 22:00:49) + +Meeting ended at 22:03:45 UTC. + + + + +Action Items +------------ +* Core SIG needs to update it's charter & run that by the Board + + + + +Action Items, by person +----------------------- +* **UNASSIGNED** + * Core SIG needs to update it's charter & run that by the Board + + + + +People Present (lines said) +--------------------------- +* quaid (41) +* Evolution (15) +* toracat (12) +* hughesjr (9) +* range (4) +* csieh (4) +* centbot (3) +* kbsingh (2) +* ccmolik (1) +* Arrfab (1) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/march/centos-devel.2014-03-19-20.58.html b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.html new file mode 100644 index 0000000..994c495 --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.html @@ -0,0 +1,281 @@ + + + + +#centos-devel: Board meeting live http://centos.org/media - agenda for today: Storage and Cloud-related SIG proposals + + + + +

#centos-devel: Board meeting live http://centos.org/media - agenda for today: Storage and Cloud-related SIG proposals

+ +Meeting started by quaid at 20:58:13 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. http://www.youtube.com/watch?v=muUOhg12FKs + (kbsingh, + 21:04:26)
      2. +
    +
    2. +
  2. Storage SIG proposal (quaid, 21:07:26) +
      +
    1. http://wiki.centos.org/SpecialInterestGroup/Storage/Proposal + (quaid, + 21:07:28)
      2. +
    2. AGREED: we have a + quorum (quaid, + 21:09:25)
      3. +
    3. SIG members currently include Ceph and + Gluster (quaid, + 21:12:20)
      4. +
    4. SIG members include Patrick Mcgarry (Ceph) and + Lalatendu Mohanty (GlusterFS) and KBSingh (Board + mentor/liaison) (quaid, + 21:13:28)
      5. +
    5. Need to work on repository structure + (quaid, + 21:18:16)
      6. +
    6. qemu dependencies mean work with the Cloud * + SIG who adopts qemu to figure out if it can be worked together, + hierarchical setup, with maintain-your-own the last possible answer + :) (quaid, + 21:18:56)
      7. +
    7. a storage SIG repository could be cleaner and + keep things out of CentOS Extras and CentOS Plus (quaid, + 21:22:45)
      8. +
    8. ACTION: need to + consider best way to handle questions from IRC, Twitter, etc. for + live Board hangouts. (quaid, + 21:27:27)
      9. +
    9. AGREED: start new SIG + work on main -devel and users lists, then branch as needed + (quaid, + 21:36:01)
      10. +
    10. IDEA: having an + all-SIGs-overview mailing list for cross-SIG coordination (esp. if + things move from -devel) (quaid, + 21:36:24)
      11. +
    11. ACTION: make sure new + SIG work gets exposure of ~first 3 months on main centos-devel + list (quaid, + 21:37:18)
      12. +
    12. IDEA: have a SIG + coordinators (or all maintainers) should have a chat every few + weeks, such as a public Hangout or IRC (quaid, + 21:37:45)
      13. +
    13. AGREED: quorum voted + yes to Storage SIG propsals (quaid, + 21:39:48)
      14. +
    14. ACTION: KB to follow + up with Jim and Tru (quaid, + 21:40:00)
      15. +
    15. ACTION: KB to send + call-to-action to -devel list (quaid, + 21:40:11)
      16. +
    16. IDEA: include CentOS + package/build expert, Ceph will bring their maintainer (quaid, + 21:40:41)
      17. +
    17. http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (kbsingh, + 21:42:06)
      18. +
    18. http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (mikem23, + 21:42:08)
      19. +
    +
    3. +
  3. Cloud Instance SIG (quaid, 21:42:22) +
      +
    1. http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (quaid, + 21:42:27)
      2. +
    2. the intention of this SIG is to have folks who + know what they are doing and represent mindshare, come together and + help us build images that work across cloud providers, meet best + practices, development environments, tuned up for + environments. (quaid, + 21:43:24)
      3. +
    3. primary charter is to bring in existing experts + to help us build images (quaid, + 21:43:36)
      4. +
    4. SIG will deliver a basic image that others can + bundle with their RPMs to do their own image (quaid, + 21:49:53)
      5. +
    5. cloud-init, minimizing for certain instances, + perf tuning for certain hypervisors (quaid, + 21:50:13)
      6. +
    6. most of the work will be kickstart files v. + RPMs (quaid, + 21:50:37)
      7. +
    7. IDEA: SIG is focused on + tuning and curating the image, but there is room in the scope to + provide multiple images tuned for various environments (quaid, + 21:51:47)
      8. +
    8. Primary interface will be with the Core + SIG (quaid, + 21:53:40)
      9. +
    9. SIG is requesting cloud.centos.org as a source + (with an API?) for distributing images, cf. mirror.centos.org for + packages (quaid, + 21:54:30)
      10. +
    10. QA for images are basic/essential, may look to + spread out toward different hypervisors (quaid, + 22:00:10)
      11. +
    11. IDEA: having 2 physical + machines ready for a few hours every day for QA (quaid, + 22:00:24)
      12. +
    12. IDEA: it would be nice + to have a process to promote image when they get enough + testing/traction to official installation media. (alphacc, + 22:04:42)
      13. +
    13. AGREED: Vote agrees + to the Cloud Instance SIG proposal; follow-up to happen with Jim and + Tru to confirm their votes (quaid, + 22:07:45)
      14. +
    14. ACTION: KB to + follow-up with Jim and Tru about this vote (quaid, + 22:08:03)
      15. +
    15. ACTION: SIG needs to + define primary point of contact/coordinator (quaid, + 22:08:18)
      16. +
    +
    4. +
+

+ + + + +Meeting ended at 22:09:20 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. need to consider best way to handle questions from IRC, Twitter, etc. for live Board hangouts.
    2. +
  2. make sure new SIG work gets exposure of ~first 3 months on main centos-devel list
    3. +
  3. KB to follow up with Jim and Tru
    4. +
  4. KB to send call-to-action to -devel list
    5. +
  5. KB to follow-up with Jim and Tru about this vote
    6. +
  6. SIG needs to define primary point of contact/coordinator
    7. +
+

+ + + +

People present (lines said)

+
    +
  1. quaid (51)
    2. +
  2. kbsingh (9)
    3. +
  3. Evolution (7)
    4. +
  4. scuttlemonkey (7)
    5. +
  5. alphacc (6)
    6. +
  6. centbot (3)
    7. +
  7. TrevorH (3)
    8. +
  8. range (1)
    9. +
  9. mikem23 (1)
    10. +
  10. hughesjr (0)
    11. +
  11. Arrfab (0)
    12. +
  12. tru_tru (0)
    13. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.html b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.html new file mode 100644 index 0000000..b807501 --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.html @@ -0,0 +1,115 @@ + + + + +#centos-devel log + + + + +
20:58:13 <quaid> #startmeeting Board meeting live http://centos.org/media - agenda for today:  Storage and Cloud-related SIG proposals
+20:58:13 <centbot> Meeting started Wed Mar 19 20:58:13 2014 UTC.  The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot.
+20:58:13 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+20:58:40 <quaid> #chair Evolution hughesjr range tru_tru kbsingh mikem23 Arrfab
+20:58:40 <centbot> Current chairs: Arrfab Evolution hughesjr kbsingh mikem23 quaid range tru_tru
+21:01:26 <kbsingh> scuttlemonkey: around ?
+21:01:38 <scuttlemonkey> kbsingh: yep, watching the stream now
+21:01:45 <alphacc> hi guys, is there a hangout link ?
+21:03:19 <TrevorH> the audio is barely functional :(
+21:03:23 <quaid> just getting ready
+21:03:45 <quaid> alphacc: for watching, you should be able to find it at http://centos.org/media
+21:03:53 <quaid> or on the YouTube channel?
+21:04:01 <Evolution> quaid: not until I get the updated youtube url he can't :-P
+21:04:06 <kbsingh> quaid: that url needs to be updated i think
+21:04:06 <quaid> erps
+21:04:08 <Evolution> I need the url to put on media
+21:04:12 <quaid> you still can't get that in advance?
+21:04:13 <Evolution> er, /media
+21:04:26 <kbsingh> http://www.youtube.com/watch?v=muUOhg12FKs
+21:04:28 <Evolution> the person who starts them sees it
+21:04:31 <Evolution> ah, there we go
+21:04:33 <Evolution> one sec
+21:05:25 <Evolution> okay, pushing now
+21:06:57 <alphacc> youtube link is ok, nothing on media yet. thx !
+21:07:26 <quaid> #topic Storage SIG proposal
+21:07:28 <quaid> http://wiki.centos.org/SpecialInterestGroup/Storage/Proposal
+21:08:31 <quaid> scuttlemonkey == Patrick?
+21:08:39 <scuttlemonkey> yep, that's me
+21:09:25 <quaid> #agreed we have a quorum
+21:10:45 <TrevorH> kbsingh: yes, your audio is much better now, less Herbie Hancock
+21:11:51 <kbsingh> woo!
+21:12:20 <quaid> #info SIG members currently include Ceph and Gluster
+21:13:28 <quaid> #info SIG members include Patrick Mcgarry (Ceph) and Lalatendu Mohanty (GlusterFS) and KBSingh (Board mentor/liaison)
+21:16:14 <quaid> scuttlemonkey: yeah, it's "building bridges" not "burning" them ;-D
+21:16:20 <scuttlemonkey> hehe
+21:16:26 * quaid is Karsten btw
+21:16:37 <scuttlemonkey> sorry, that's my own turn of phrase
+21:16:43 <scuttlemonkey> I shouldn't use that in mixed company
+21:17:20 <scuttlemonkey> I tend to eschew your typical calloquialisms
+21:17:44 <quaid> heh
+21:18:00 <quaid> oh, no, it made sense to me, from the way you phrased it in context :)
+21:18:16 <quaid> #info Need to work on repository structure
+21:18:56 <quaid> #info qemu dependencies mean work with the Cloud * SIG who adopts qemu to figure out if it can be worked together, hierarchical setup, with maintain-your-own the last possible answer :)
+21:22:16 <alphacc> I don't know if I can ask question but can't we consider rhev rebuild for a qemu-kvm that works out of the box(accross sigs). It may not fit gluster team as it ship with some specific gluster version. (it's what we do in prod at CERN)
+21:22:45 <quaid> #info a storage SIG repository could be cleaner and keep things out of CentOS Extras and CentOS Plus
+21:22:52 * quaid hoped he simplified that well
+21:23:54 <scuttlemonkey> yeah, Ceph is already in centos-extras...we were hoping to make it easier to deploy storage options through this effort
+21:24:40 <quaid> alphacc: I think it's relevant, sure; the point around the SIG is a gathering of people around a technology who are willing to maintain and grow community around the technology
+21:25:30 <quaid> alphacc: so my initial thought is, who is offering to maintain that rebuild? and does it fit in one or more existing SIGs? if yes, then those SIGs need to weigh in on how it could work; if not, then is it a standalone SIG?
+21:26:37 <kbsingh> quaid: alphacc: i think the virtsig might be a good place to curate that
+21:26:47 <kbsingh> but can do we discussion
+21:26:59 <alphacc> yes my idea was to solve the qemu-kvm issues this way. HAve an effort to rebuild a cloud oriented qemu-kvm.
+21:27:12 <kbsingh> alphacc: the trick is going to be finding where to host it
+21:27:27 <quaid> #action need to consider best way to handle questions from IRC, Twitter, etc. for live Board hangouts.
+21:27:52 <kbsingh> woo! xen qemu could use ceph
+21:36:01 <quaid> #agreed start new SIG work on main -devel and users lists, then branch as needed
+21:36:24 <quaid> #idea having an all-SIGs-overview mailing list for cross-SIG coordination (esp. if things move from -devel)
+21:37:18 <quaid> #action make sure new SIG work gets exposure of ~first 3 months on main centos-devel list
+21:37:45 <quaid> #idea have a SIG coordinators (or all maintainers) should have a chat every few weeks, such as a public Hangout or IRC
+21:39:48 <quaid> #agreed quorum voted yes to Storage SIG propsals
+21:40:00 <quaid> #action KB to follow up with Jim and Tru
+21:40:11 <quaid> #action KB to send call-to-action to -devel list
+21:40:16 <range> I think the "sig coordinator mailing list" isn't a bad idea. We have the same for the people running the foreign language mailing lists. Not that that list has any traffic at all ...
+21:40:41 <quaid> #idea include CentOS package/build expert, Ceph will bring their maintainer
+21:42:06 <kbsingh> http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal
+21:42:08 <mikem23> http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal
+21:42:22 <quaid> #topic Cloud Instance SIG
+21:42:27 <quaid> http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal
+21:43:24 <quaid> #info the intention of this SIG is to have folks who know what they are doing and represent mindshare, come together and help us build images that work across cloud providers, meet best practices, development environments, tuned up for environments.
+21:43:36 <quaid> #info primary charter is to bring in existing experts to help us build images
+21:49:53 <quaid> #info SIG will deliver a basic image that others can bundle with their RPMs to do their own image
+21:50:13 <quaid> #info cloud-init, minimizing for certain instances, perf tuning for certain hypervisors
+21:50:37 <quaid> #info most of the work will be kickstart files v. RPMs
+21:51:47 <quaid> #idea SIG is focused on tuning and curating the image, but there is room in the scope to provide multiple images tuned for various environments
+21:53:00 <TrevorH> you need an authentication SIG ;)
+21:53:40 <quaid> #info Primary interface will be with the Core SIG
+21:54:30 <quaid> #info SIG is requesting cloud.centos.org as a source (with an API?) for distributing images, cf. mirror.centos.org for packages
+22:00:10 <quaid> #info QA for images are basic/essential, may look to spread out toward different hypervisors
+22:00:24 <quaid> #idea having 2 physical machines ready for a few hours every day for QA
+22:01:29 <alphacc> it would be nice to have a process to promote image when they get enough testing/traction to official installation media.
+22:03:54 <quaid> alphacc: can you repeat that with '#idea' in front? that helps it get in the discussion/minutes from here
+22:04:42 <alphacc> #idea it would be nice to have a process to promote image when they get enough testing/traction to official installation media.
+22:06:37 <quaid> thanks :)
+22:07:45 <quaid> #agreed Vote agrees to the Cloud Instance SIG proposal; follow-up to happen with Jim and Tru to confirm their votes
+22:08:03 <quaid> #action KB to follow-up with Jim and Tru about this vote
+22:08:18 <quaid> #action SIG needs to define primary point of contact/coordinator
+22:09:09 <quaid> finishing ...
+22:09:20 <quaid> #endmeeting
+ diff --git a/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.txt b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.txt new file mode 100644 index 0000000..98dd1ad --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.log.txt @@ -0,0 +1,88 @@ +20:58:13 #startmeeting Board meeting live http://centos.org/media - agenda for today: Storage and Cloud-related SIG proposals +20:58:13 Meeting started Wed Mar 19 20:58:13 2014 UTC. The chair is quaid. Information about MeetBot at http://wiki.debian.org/MeetBot. +20:58:13 Useful Commands: #action #agreed #help #info #idea #link #topic. +20:58:40 #chair Evolution hughesjr range tru_tru kbsingh mikem23 Arrfab +20:58:40 Current chairs: Arrfab Evolution hughesjr kbsingh mikem23 quaid range tru_tru +21:01:26 scuttlemonkey: around ? +21:01:38 kbsingh: yep, watching the stream now +21:01:45 hi guys, is there a hangout link ? +21:03:19 the audio is barely functional :( +21:03:23 just getting ready +21:03:45 alphacc: for watching, you should be able to find it at http://centos.org/media +21:03:53 or on the YouTube channel? +21:04:01 quaid: not until I get the updated youtube url he can't :-P +21:04:06 quaid: that url needs to be updated i think +21:04:06 erps +21:04:08 I need the url to put on media +21:04:12 you still can't get that in advance? +21:04:13 er, /media +21:04:26 http://www.youtube.com/watch?v=muUOhg12FKs +21:04:28 the person who starts them sees it +21:04:31 ah, there we go +21:04:33 one sec +21:05:25 okay, pushing now +21:06:57 youtube link is ok, nothing on media yet. thx ! +21:07:26 #topic Storage SIG proposal +21:07:28 http://wiki.centos.org/SpecialInterestGroup/Storage/Proposal +21:08:31 scuttlemonkey == Patrick? +21:08:39 yep, that's me +21:09:25 #agreed we have a quorum +21:10:45 kbsingh: yes, your audio is much better now, less Herbie Hancock +21:11:51 woo! +21:12:20 #info SIG members currently include Ceph and Gluster +21:13:28 #info SIG members include Patrick Mcgarry (Ceph) and Lalatendu Mohanty (GlusterFS) and KBSingh (Board mentor/liaison) +21:16:14 scuttlemonkey: yeah, it's "building bridges" not "burning" them ;-D +21:16:20 hehe +21:16:26 * quaid is Karsten btw +21:16:37 sorry, that's my own turn of phrase +21:16:43 I shouldn't use that in mixed company +21:17:20 I tend to eschew your typical calloquialisms +21:17:44 heh +21:18:00 oh, no, it made sense to me, from the way you phrased it in context :) +21:18:16 #info Need to work on repository structure +21:18:56 #info qemu dependencies mean work with the Cloud * SIG who adopts qemu to figure out if it can be worked together, hierarchical setup, with maintain-your-own the last possible answer :) +21:22:16 I don't know if I can ask question but can't we consider rhev rebuild for a qemu-kvm that works out of the box(accross sigs). It may not fit gluster team as it ship with some specific gluster version. (it's what we do in prod at CERN) +21:22:45 #info a storage SIG repository could be cleaner and keep things out of CentOS Extras and CentOS Plus +21:22:52 * quaid hoped he simplified that well +21:23:54 yeah, Ceph is already in centos-extras...we were hoping to make it easier to deploy storage options through this effort +21:24:40 alphacc: I think it's relevant, sure; the point around the SIG is a gathering of people around a technology who are willing to maintain and grow community around the technology +21:25:30 alphacc: so my initial thought is, who is offering to maintain that rebuild? and does it fit in one or more existing SIGs? if yes, then those SIGs need to weigh in on how it could work; if not, then is it a standalone SIG? +21:26:37 quaid: alphacc: i think the virtsig might be a good place to curate that +21:26:47 but can do we discussion +21:26:59 yes my idea was to solve the qemu-kvm issues this way. HAve an effort to rebuild a cloud oriented qemu-kvm. +21:27:12 alphacc: the trick is going to be finding where to host it +21:27:27 #action need to consider best way to handle questions from IRC, Twitter, etc. for live Board hangouts. +21:27:52 woo! xen qemu could use ceph +21:36:01 #agreed start new SIG work on main -devel and users lists, then branch as needed +21:36:24 #idea having an all-SIGs-overview mailing list for cross-SIG coordination (esp. if things move from -devel) +21:37:18 #action make sure new SIG work gets exposure of ~first 3 months on main centos-devel list +21:37:45 #idea have a SIG coordinators (or all maintainers) should have a chat every few weeks, such as a public Hangout or IRC +21:39:48 #agreed quorum voted yes to Storage SIG propsals +21:40:00 #action KB to follow up with Jim and Tru +21:40:11 #action KB to send call-to-action to -devel list +21:40:16 I think the "sig coordinator mailing list" isn't a bad idea. We have the same for the people running the foreign language mailing lists. Not that that list has any traffic at all ... +21:40:41 #idea include CentOS package/build expert, Ceph will bring their maintainer +21:42:06 http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal +21:42:08 http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal +21:42:22 #topic Cloud Instance SIG +21:42:27 http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal +21:43:24 #info the intention of this SIG is to have folks who know what they are doing and represent mindshare, come together and help us build images that work across cloud providers, meet best practices, development environments, tuned up for environments. +21:43:36 #info primary charter is to bring in existing experts to help us build images +21:49:53 #info SIG will deliver a basic image that others can bundle with their RPMs to do their own image +21:50:13 #info cloud-init, minimizing for certain instances, perf tuning for certain hypervisors +21:50:37 #info most of the work will be kickstart files v. RPMs +21:51:47 #idea SIG is focused on tuning and curating the image, but there is room in the scope to provide multiple images tuned for various environments +21:53:00 you need an authentication SIG ;) +21:53:40 #info Primary interface will be with the Core SIG +21:54:30 #info SIG is requesting cloud.centos.org as a source (with an API?) for distributing images, cf. mirror.centos.org for packages +22:00:10 #info QA for images are basic/essential, may look to spread out toward different hypervisors +22:00:24 #idea having 2 physical machines ready for a few hours every day for QA +22:01:29 it would be nice to have a process to promote image when they get enough testing/traction to official installation media. +22:03:54 alphacc: can you repeat that with '#idea' in front? that helps it get in the discussion/minutes from here +22:04:42 #idea it would be nice to have a process to promote image when they get enough testing/traction to official installation media. +22:06:37 thanks :) +22:07:45 #agreed Vote agrees to the Cloud Instance SIG proposal; follow-up to happen with Jim and Tru to confirm their votes +22:08:03 #action KB to follow-up with Jim and Tru about this vote +22:08:18 #action SIG needs to define primary point of contact/coordinator +22:09:09 finishing ... +22:09:20 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/march/centos-devel.2014-03-19-20.58.txt b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.txt new file mode 100644 index 0000000..991020f --- /dev/null +++ b/static/minutes/2014/march/centos-devel.2014-03-19-20.58.txt @@ -0,0 +1,141 @@ +====================================================================================================================== +#centos-devel: Board meeting live http://centos.org/media - agenda for today: Storage and Cloud-related SIG proposals +====================================================================================================================== + + +Meeting started by quaid at 20:58:13 UTC. The full logs are available at +centos-devel/2014/centos-devel.2014-03-19-20.58.log.html . + + + +Meeting summary +--------------- +* LINK: http://www.youtube.com/watch?v=muUOhg12FKs (kbsingh, 21:04:26) +* Storage SIG proposal (quaid, 21:07:26) + * LINK: http://wiki.centos.org/SpecialInterestGroup/Storage/Proposal + (quaid, 21:07:28) + * AGREED: we have a quorum (quaid, 21:09:25) + * SIG members currently include Ceph and Gluster (quaid, 21:12:20) + * SIG members include Patrick Mcgarry (Ceph) and Lalatendu Mohanty + (GlusterFS) and KBSingh (Board mentor/liaison) (quaid, 21:13:28) + * Need to work on repository structure (quaid, 21:18:16) + * qemu dependencies mean work with the Cloud * SIG who adopts qemu to + figure out if it can be worked together, hierarchical setup, with + maintain-your-own the last possible answer :) (quaid, 21:18:56) + * a storage SIG repository could be cleaner and keep things out of + CentOS Extras and CentOS Plus (quaid, 21:22:45) + * ACTION: need to consider best way to handle questions from IRC, + Twitter, etc. for live Board hangouts. (quaid, 21:27:27) + * AGREED: start new SIG work on main -devel and users lists, then + branch as needed (quaid, 21:36:01) + * IDEA: having an all-SIGs-overview mailing list for cross-SIG + coordination (esp. if things move from -devel) (quaid, 21:36:24) + * ACTION: make sure new SIG work gets exposure of ~first 3 months on + main centos-devel list (quaid, 21:37:18) + * IDEA: have a SIG coordinators (or all maintainers) should have a + chat every few weeks, such as a public Hangout or IRC (quaid, + 21:37:45) + * AGREED: quorum voted yes to Storage SIG propsals (quaid, 21:39:48) + * ACTION: KB to follow up with Jim and Tru (quaid, 21:40:00) + * ACTION: KB to send call-to-action to -devel list (quaid, 21:40:11) + * IDEA: include CentOS package/build expert, Ceph will bring their + maintainer (quaid, 21:40:41) + * LINK: + http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (kbsingh, 21:42:06) + * LINK: + http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (mikem23, 21:42:08) + +* Cloud Instance SIG (quaid, 21:42:22) + * LINK: + http://wiki.centos.org/SpecialInterestGroup/CloudInstance/Proposal + (quaid, 21:42:27) + * the intention of this SIG is to have folks who know what they are + doing and represent mindshare, come together and help us build + images that work across cloud providers, meet best practices, + development environments, tuned up for environments. (quaid, + 21:43:24) + * primary charter is to bring in existing experts to help us build + images (quaid, 21:43:36) + * SIG will deliver a basic image that others can bundle with their + RPMs to do their own image (quaid, 21:49:53) + * cloud-init, minimizing for certain instances, perf tuning for + certain hypervisors (quaid, 21:50:13) + * most of the work will be kickstart files v. RPMs (quaid, 21:50:37) + * IDEA: SIG is focused on tuning and curating the image, but there is + room in the scope to provide multiple images tuned for various + environments (quaid, 21:51:47) + * Primary interface will be with the Core SIG (quaid, 21:53:40) + * SIG is requesting cloud.centos.org as a source (with an API?) for + distributing images, cf. mirror.centos.org for packages (quaid, + 21:54:30) + * QA for images are basic/essential, may look to spread out toward + different hypervisors (quaid, 22:00:10) + * IDEA: having 2 physical machines ready for a few hours every day for + QA (quaid, 22:00:24) + * IDEA: it would be nice to have a process to promote image when they + get enough testing/traction to official installation media. + (alphacc, 22:04:42) + * AGREED: Vote agrees to the Cloud Instance SIG proposal; follow-up to + happen with Jim and Tru to confirm their votes (quaid, 22:07:45) + * ACTION: KB to follow-up with Jim and Tru about this vote (quaid, + 22:08:03) + * ACTION: SIG needs to define primary point of contact/coordinator + (quaid, 22:08:18) + +Meeting ended at 22:09:20 UTC. + + + + +Action Items +------------ +* need to consider best way to handle questions from IRC, Twitter, etc. + for live Board hangouts. +* make sure new SIG work gets exposure of ~first 3 months on main + centos-devel list +* KB to follow up with Jim and Tru +* KB to send call-to-action to -devel list +* KB to follow-up with Jim and Tru about this vote +* SIG needs to define primary point of contact/coordinator + + + + +Action Items, by person +----------------------- +* **UNASSIGNED** + * need to consider best way to handle questions from IRC, Twitter, + etc. for live Board hangouts. + * make sure new SIG work gets exposure of ~first 3 months on main + centos-devel list + * KB to follow up with Jim and Tru + * KB to send call-to-action to -devel list + * KB to follow-up with Jim and Tru about this vote + * SIG needs to define primary point of contact/coordinator + + + + +People Present (lines said) +--------------------------- +* quaid (51) +* kbsingh (9) +* Evolution (7) +* scuttlemonkey (7) +* alphacc (6) +* centbot (3) +* TrevorH (3) +* range (1) +* mikem23 (1) +* hughesjr (0) +* Arrfab (0) +* tru_tru (0) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/may/centos-devel.2014-05-09-16.52.html b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.html new file mode 100644 index 0000000..c8ac224 --- /dev/null +++ b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.html @@ -0,0 +1,134 @@ + + + + +#centos-devel Meeting + + + + +

#centos-devel Meeting

+ +Meeting started by filippoc at 16:52:43 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. http://wiki.centos.org/SpecialInterestGroup/SLS + (daveloper, + 17:03:27)
      2. +
    2. ACTION: modify sls + wiki page -> Status: proposal (filippoc, + 17:07:40)
      3. +
    3. ACTION: expand + Deliverables section (filippoc, + 17:12:56)
      4. +
    4. https://bugzilla.redhat.com/show_bug.cgi?id=1018312 + (filippoc, + 17:17:26)
      5. +
    5. ACTION: ask for + comments on centos-devel (filippoc, + 17:34:39)
      6. +
    6. ACTION: talk to Jim + for advice on a board member to sponsor the SLS SIG (filippoc, + 17:39:33)
      7. +
    +
    2. +
+

+ + + + +Meeting ended at 17:50:28 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. modify sls wiki page -> Status: proposal
    2. +
  2. expand Deliverables section
    3. +
  3. ask for comments on centos-devel
    4. +
  4. talk to Jim for advice on a board member to sponsor the SLS SIG
    5. +
+

+ + + +

People present (lines said)

+
    +
  1. filippoc (47)
    2. +
  2. kbsingh (43)
    3. +
  3. daveloper (29)
    4. +
  4. omarel (8)
    5. +
  5. reetp (7)
    6. +
  6. pcbaldwin (7)
    7. +
  7. Arrfab (4)
    8. +
  8. centbot (3)
    9. +
  9. davidep (3)
    10. +
  10. gsanchietti (3)
    11. +
  11. JPP_kimsufi (3)
    12. +
  12. rsc (2)
    13. +
  13. Bahhumbug (2)
    14. +
  14. alefattorini (2)
    15. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.html b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.html new file mode 100644 index 0000000..6b9f793 --- /dev/null +++ b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.html @@ -0,0 +1,190 @@ + + + + +#centos-devel log + + + + +
16:52:43 <filippoc> #startmeeting
+16:52:43 <centbot> Meeting started Fri May  9 16:52:43 2014 UTC.  The chair is filippoc. Information about MeetBot at http://wiki.debian.org/MeetBot.
+16:52:43 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+16:53:07 <omarel> Are you trying to expand it to Small Business oriented as well?
+16:53:11 <filippoc> #meetingname SLS-SIG
+16:53:11 <centbot> The meeting name has been set to 'sls-sig'
+16:53:22 <JPP_kimsufi> filippoc: if you need log of this conversation I would be able to provide
+16:54:12 <filippoc> omarel, we are small business oriented
+16:54:14 <JPP_kimsufi> filippoc: but other than that no experience with meetbot
+16:55:04 <omarel> I'm still a bit confused, though. My "branding" issue is still there.  How would someone wanting a small business server find you?
+16:55:35 <daveloper> I don’t think that we need to, of necessity, be business oriented at all. Personally, I think the name presently reflects the nature of what we are trying to do. If simplified is used for business or for home or for hobby, it wouldn’t matter to me.
+16:56:18 <omarel> It may be 2 different gruops with some obvious overlap.  Perhaps dealing with th overlap is the issue.
+16:56:43 <filippoc> daveloper: next steps would involve mandatory collaboration from centos, i.e. importing packages in git, setting up the buildsys, etc
+16:57:24 <gsanchietti> omarel: the SLS SIG is a group of people with common interest. Probably more CentOS variant will born from the SIG. Each variant will have its own brand.
+16:57:27 <filippoc> I'm not sure that more than one group would be beneficial
+16:57:40 <filippoc> more variants are welcome to fill every niche
+16:57:44 <pcbaldwin> I think that a SIG can have a broad scope that covers both home and business.  The potential variants that come out of the SIG can be more focused.
+16:57:49 <JPP_kimsufi> small business oriented is an aspect, but it also adress to home users who wants an easily configurable home server. Thus the reference to what it provides, and not to whom it addresses. But good point to reference it to the public two IMOHA
+16:57:51 <daveloper> agreed, I think we’ve done what they’ve asked for as far as defining the scope of what this SIG is about. I’d hope that they would now follow through and make aspects of their buildsys available to us now.
+16:58:30 <gsanchietti> pcbaldwin: I agree
+16:58:53 <filippoc> I'm not up to date with recent centos decisions about repositories and such
+16:59:11 * Arrfab sees activity and jumps in ...
+16:59:14 <daveloper> Filippoc said, “more variants are welcome to fill every niche”… I totally agree. The point of the SIG is collaboration and standards, not necessarily unification.
+16:59:17 <omarel> I think if there are people with special interests, it amounts to SIG.  It's a demographic issue.  If there's interest, and it's specialized, then the group of people decide.
+16:59:59 <kbsingh> omarel: in the CentOS ecosystem a SIG is a group of people looking to either curate or deliver something based on and around a technology
+17:00:03 <omarel> I think from my point of view, I'm not so much interesting in a broad target.  I'd rather narrowly target it to businesses and institutions.
+17:00:29 <daveloper> demographics can be a SIG, sure, but this SIG is about “[providing] a common platform for delivering turnkey CentOS-based solutions that are managed via a web and/or REST-based interface.”
+17:00:33 <kbsingh> key being tech and code and deliver
+17:00:48 <omarel> I think personally I need to find other people with similar interests.  If the interest is there, we have another sig.
+17:00:49 <kbsingh> ( this isnt orthogonal to what you were saying omarel, but i wanted to quantify that )
+17:02:01 <omarel> Remember, this is just me, and people have different points of view, but the issues I deal with on a daily basis are different than I think SLS is dealing with.
+17:02:07 <davidep> hi all
+17:02:28 <kbsingh> omarel: a SIG can deliver more than one end result :D
+17:02:39 * alefattorini jumps in too
+17:02:42 <filippoc> omarel, your idea is totally different from the SLS SIG proposal? Or similar and could be addressed with minor modifications to SLS?
+17:02:45 <kbsingh> there is no reason why the Small business SIG cant be doing more than SLS - actually, every SIG would
+17:03:04 <kbsingh> also, i dont think its going to be called SLS SIG, is it ?
+17:03:24 <filippoc> :-)
+17:03:27 <daveloper> http://wiki.centos.org/SpecialInterestGroup/SLS
+17:03:55 <omarel> Yes it can.  You know I need to sit down and write out what I have in mind and my motivation for it.  It's more than can be elaborated her in this chat format.
+17:03:55 <kbsingh> ok, pretty sure its going to get rejected by the board
+17:04:09 <kbsingh> also, you need to make sure it clearly states that this is a proposed SIG, not accepted as yet
+17:04:21 <Arrfab> kbsingh: also worth noting that it's still a proposal, indeed
+17:04:36 <daveloper> What criteria are we missing Karanbir?
+17:04:49 <kbsingh> SIG's are interest and tech driven, not a specific deliverable
+17:04:54 <kbsingh> eg. its not the XEN SIG - its the Virt SIG
+17:05:04 <kbsingh> and its not the GLUSTER SIG- its the Storage SIG
+17:05:19 <kbsingh> the virt-sig is already working with a upstream qemu onramp and openvz is making efforts in
+17:05:27 <kbsingh> similarly the storage sig already includes ceph and gluster
+17:06:00 <pcbaldwin> The "tech" is moving from CLI and X-Windows based systems to API/REST-based interfaces.
+17:06:03 <daveloper> What specific technology are we advocating. I’m pretty sure the individual members all use different technologies to deliver a wide array of deliverables.
+17:06:22 <daveloper> For example, Filippo’s project doesn’t do what my project does and vice, versa.
+17:06:27 <kbsingh> so in that mindsetup Simplified Linux Server does not fit into the larger model at all - a Small Office SIG can however work to deliver a simplified SOHO server install set ( as an example )
+17:07:35 <kbsingh> things like this are far too ambigious "The SIG members are involved in the development and maintenance of turnkey solutions based on CentOS. "
+17:07:40 <filippoc> #action modify sls wiki page -> Status: proposal
+17:07:59 <kbsingh> what does that mean ? are you guys also working on the MIPS vlsi poc using centos in an embedded role for industrial automation ?
+17:08:03 <daveloper> SOHO seems to be more of a deliverable than Simplified Linux Server. For example, I can simplify the process for provisioning large directory services based on an array of different backends and that would not be a SOHO application. But it would still be ‘Simplified’ through a web UI.
+17:09:06 <daveloper> I don’t know about Filippo but we’ve discussed applying what we are doing to other architectures including MIPS.
+17:09:36 <filippoc> we'd like to have arm support, but we'll follow upstream
+17:09:59 <kbsingh> my understanding of this sig is that the aim is to deliver a set of solutions for small business , new linux users doing entry level admin work in small offices / soho environs
+17:11:08 <kbsingh> seondly, who is proposing the SIG to the board ? I dont see any of the CentOS Board guys on the who's involved list
+17:11:44 <daveloper> But the reason for bringing this together is to come up with common build needs and processes that are common among our technologies. For example, Filippo’s team and our team benefit from an accelarated path to getting newer PHP code. Others involved don’t need that but there are crossover needs at multiple levels.
+17:11:48 <kbsingh> what i would recommend is actually working the proposal to include specific deliverables
+17:11:53 <kbsingh> and remove stuff like "Software Maintenance - This SIG will co-ordinate maintenance of common upstream packages in order to avoid duplication and provide a better experience for all CentOS users. "
+17:12:16 <kbsingh> and "Quality Assurance - This SIG provides solutions with tight integration amongst the various applications in CentOS. This provides a unique opportunity to provide additional QA testing (e.g. Samba + OpenLDAP). "
+17:12:26 <kbsingh> basically, that deliverables section - someone needs to write one
+17:12:56 <filippoc> #action expand Deliverables section
+17:13:11 <daveloper> Are we required to have board sponsorship in order to get a SIG approved. Who can we contact then to have an advocate?
+17:13:55 <kbsingh> daveloper: the list of board members is listed on the centos website - you should be ok to contact any / all of them if you want
+17:13:56 <filippoc> I hope that Evolution could help us
+17:14:06 <kbsingh> i think he's i brazil at the moment
+17:14:07 <Arrfab> daveloper: well, the board needs to approve a SIG proposal during a board meeting, so if you don't ask, nothing will be discussed :-)
+17:14:53 <daveloper> correct, but karanbir seems to indicate that we need to have a board member on our SIG team in order for this to be a reality. I did not know that this was a requirement.
+17:15:03 <kbsingh> daveloper: it is
+17:15:24 <pcbaldwin> I thought it was a member of the dev team.  That's what's on the Wiki page.
+17:15:40 <kbsingh> a completely mature SIG, is able to do their own  process work - but we esitmate a 2 yr span from going onboard to maturity for a highly organised sig
+17:15:42 <Arrfab> daveloper: http://wiki.centos.org/SpecialInterestGroup/ but all Devteam members are on the board
+17:15:48 <filippoc> we probably need to "polish" the proposal before asking for approval
+17:16:22 <kbsingh> stuff like Clam from EPEL - but does this sig have access to influence that build in EPEL ? if not, you are already creating deadends
+17:16:30 <kbsingh> filippoc: yes please
+17:16:36 <pcbaldwin> No matter.  At this stage, we're still trying to figure out the whole role/scope of a SIG.  Even looking through the wiki and centos-devel list, there seems to be a lot of unknowns.  That's expected given that it's the early days!
+17:16:45 <Bahhumbug> Arrfab: The web page probably needs to be cleared up in that regard.
+17:17:26 <filippoc> https://bugzilla.redhat.com/show_bug.cgi?id=1018312
+17:18:30 <kbsingh> filippoc: so you need rsc to join the SIG
+17:18:48 <kbsingh> pcbaldwin: Bahhumbug: please submit patch
+17:18:56 <kbsingh> or an issue report at bugs.centos.org
+17:19:06 <filippoc> kbsingh: probably a good idea
+17:19:45 <pcbaldwin> kbsingh: patch for the wiki page??
+17:20:02 <rsc> kbsingh: hm?
+17:20:07 <Bahhumbug> It's a wiki page.  It's a 30 second edit.
+17:21:56 <kbsingh> submit patch, a community notion of saying 'come help fix that which needs attention, and since you have the attention..'
+17:21:56 <filippoc> omarel: could you write your ideas on a mail to centos-devel?
+17:22:20 <kbsingh> filippoc: daveloper: its also important to highlight what exactly is going to get done
+17:23:10 <kbsingh> eg. the QA stuff might be : develop as a part of the SIG, a test suite that can be run on a nightly basis from ci.dev.centos.org to validate a spec ( also to be developed as a part of the SIG ) - QA test harness being a precursor to code development in the SIG
+17:23:19 <filippoc> we will release rpms
+17:23:22 <daveloper> Looking at the requirements: We don’t have overlap with other SIGs so far as I can tell. We’ve opened a discussion topic and have solicited comments. Have we requested a new mailing list? We do have a wiki section. We will need version control setup. We are listed as a SIG on the SIG page. We need one Devteam member to join the team. Is there anything I missed?
+17:23:52 <filippoc> we will write a testsuite
+17:24:09 <rsc> kbsingh, filippoc: How can I help regarding RHBZ#1018312? Or what is with which SIG?
+17:24:10 <filippoc> davidep is already working on it
+17:24:11 <kbsingh> filippoc: quantifying that on the proposal will help
+17:24:44 <davidep> Arrfab, kbsingh: what about the CI platform for SIGs? any progress on it?
+17:24:45 <filippoc> rsc: sorry, it was an bad example to show that we work with epel
+17:24:52 <kbsingh> also, who is going to run the SIG, what or how are you going to bring more members in, what licenses are you guys going to use - what is the downstream going to be etc.
+17:24:59 <reetp> Filippo, you may have seen that we have been got some basic testing working....
+17:25:13 <kbsingh> get as much of this pre-done, better chances to get in through the board review
+17:25:29 <filippoc> rretp, I meant t_functional on ci.centos
+17:25:41 <filippoc> reetp sorry
+17:25:50 <kbsingh> filippoc: it does not need to be in t_functional. it can be a completely different suite
+17:26:03 <daveloper> Which SIGs have already been approved?
+17:26:11 <kbsingh> eg. the virt-sig is starting the t_xen.git suite
+17:26:21 <filippoc> I thought it was better trying to extend t_functional and improve ci.centos
+17:26:32 <filippoc> but ok
+17:26:34 * kbsingh off, call time, back in a few hours
+17:26:56 <reetp> Have a chat with Ian when you get a minute and see where they are at.
+17:26:59 <kbsingh> filippoc: thats ok as well - but ci.d.c.o can run more tests than just that
+17:28:28 <filippoc> daveloper, I'll try to exapnd the Deliverables section of our proposal
+17:28:59 <daveloper> Thanks Filippo, I’ll work with you on that in the shared doc if you like.
+17:29:26 <filippoc> maybe I could simply list rpm packages from your web page
+17:29:53 <daveloper> I’m curious as to who already has been approved so we can know what to follow or emulate.
+17:29:57 <reetp> Can you share the doc with other members of our Board ? I can give you addresses
+17:30:21 <filippoc> only virt sig I think
+17:30:44 <filippoc> reetp: sure
+17:31:02 <filippoc> I'll give you full control
+17:31:53 <daveloper> Are there any other objectives to cover here?
+17:32:02 <filippoc> mmh, we should probably start a new doc, that old one is already a wiki page
+17:32:03 <reetp> Thanks -I'm sure some of the others will chime in.
+17:32:11 <pcbaldwin> I have to head out.  At a fundamental level, it would be nice for all of us (NethServer, SME Server, ClearOS and potentially others) to have a working relationship with CentOS/RHEL.   We're part of the ecosystem and I personally have always felt like an outsider.  I'm certainly not getting the warm and fuzzies, but maybe that's just because it's IRC.  Or maybe there's a lot on the CentOS team's plate right now.  Oh well, I'll keep on
+17:32:16 <daveloper> agreed.
+17:32:36 <filippoc> agreed
+17:32:41 <pcbaldwin> keep on trucking = keep on trying to build the relationship
+17:32:50 <daveloper> Thanks Peter. I get that sense as well.
+17:33:07 <reetp> We're agreed on something then :-)
+17:33:34 <daveloper> Also a call would be good. I’ll try to set that up next week sometime.
+17:34:02 <reetp> An obvious note is that perhaps their documentation and expectation s are not really clear enough and they should address that. WE can only work to what they give us.
+17:34:06 <filippoc> I'll try to solicit comments to our sig proposal on the centos-devel ml
+17:34:39 <filippoc> #action ask for comments on centos-devel
+17:35:33 <reetp> I gotta go - only 45 mins late. Interesting and will look back through this later.
+17:35:48 <daveloper> Filippo, have we formally requested version control for our SIG?
+17:36:22 <filippoc> not sure if we did formally
+17:36:37 <daveloper> Also, we need to secure a mailing list for ourselves.
+17:36:43 <filippoc> we asked tough
+17:36:58 <daveloper> I’m not sure who we do that with on the centos team.
+17:38:21 <filippoc> keeping discussion on centos-devel for a while will probably be beneficial
+17:38:48 <filippoc> but I'm sure we need to have our ml sooner than later
+17:39:22 <kbsingh> filippoc: you need to get approved first
+17:39:33 <filippoc> #action talk to Jim for advice on a board member to sponsor the SLS SIG
+17:39:34 <kbsingh> then the resources become available immediately
+17:39:49 <filippoc> got it
+17:40:37 <daveloper> Getting a mailing list is listed as a requirement before approval.
+17:40:48 <daveloper> seemed backwards to me too
+17:41:14 <daveloper> so then the only thing we need is a devteam member on our group and then we can present, yeah?
+17:41:25 <daveloper> We’ll clean up our proposal though first.
+17:43:43 <davidep> quoting kbsingh: "key being tech and code and deliver"
+17:45:06 <filippoc> daveloper: I will ask for editing permission for you on centos wiki
+17:45:18 <daveloper> thanks
+17:45:23 <filippoc> register and send me your username
+17:46:20 <gsanchietti> daveloper, filippoc: I think we also need to extend the section about how to join the SIG and who is in charge to evaluate new members
+17:46:40 <filippoc> I'll ask for permissions for you too
+17:46:59 <filippoc> gsanchietti: register and so on...
+17:48:42 <filippoc> I'd end this meeting, but I'd like to schedule next week
+17:49:38 <alefattorini> we have a lot of stuff to do:-)
+17:50:22 <filippoc> have a nice weekend
+17:50:28 <filippoc> #endmeeting
+ diff --git a/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.txt b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.txt new file mode 100644 index 0000000..6820eaa --- /dev/null +++ b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.log.txt @@ -0,0 +1,163 @@ +16:52:43 #startmeeting +16:52:43 Meeting started Fri May 9 16:52:43 2014 UTC. The chair is filippoc. Information about MeetBot at http://wiki.debian.org/MeetBot. +16:52:43 Useful Commands: #action #agreed #help #info #idea #link #topic. +16:53:07 Are you trying to expand it to Small Business oriented as well? +16:53:11 #meetingname SLS-SIG +16:53:11 The meeting name has been set to 'sls-sig' +16:53:22 filippoc: if you need log of this conversation I would be able to provide +16:54:12 omarel, we are small business oriented +16:54:14 filippoc: but other than that no experience with meetbot +16:55:04 I'm still a bit confused, though. My "branding" issue is still there. How would someone wanting a small business server find you? +16:55:35 I don’t think that we need to, of necessity, be business oriented at all. Personally, I think the name presently reflects the nature of what we are trying to do. If simplified is used for business or for home or for hobby, it wouldn’t matter to me. +16:56:18 It may be 2 different gruops with some obvious overlap. Perhaps dealing with th overlap is the issue. +16:56:43 daveloper: next steps would involve mandatory collaboration from centos, i.e. importing packages in git, setting up the buildsys, etc +16:57:24 omarel: the SLS SIG is a group of people with common interest. Probably more CentOS variant will born from the SIG. Each variant will have its own brand. +16:57:27 I'm not sure that more than one group would be beneficial +16:57:40 more variants are welcome to fill every niche +16:57:44 I think that a SIG can have a broad scope that covers both home and business. The potential variants that come out of the SIG can be more focused. +16:57:49 small business oriented is an aspect, but it also adress to home users who wants an easily configurable home server. Thus the reference to what it provides, and not to whom it addresses. But good point to reference it to the public two IMOHA +16:57:51 agreed, I think we’ve done what they’ve asked for as far as defining the scope of what this SIG is about. I’d hope that they would now follow through and make aspects of their buildsys available to us now. +16:58:30 pcbaldwin: I agree +16:58:53 I'm not up to date with recent centos decisions about repositories and such +16:59:11 * Arrfab sees activity and jumps in ... +16:59:14 Filippoc said, “more variants are welcome to fill every niche”… I totally agree. The point of the SIG is collaboration and standards, not necessarily unification. +16:59:17 I think if there are people with special interests, it amounts to SIG. It's a demographic issue. If there's interest, and it's specialized, then the group of people decide. +16:59:59 omarel: in the CentOS ecosystem a SIG is a group of people looking to either curate or deliver something based on and around a technology +17:00:03 I think from my point of view, I'm not so much interesting in a broad target. I'd rather narrowly target it to businesses and institutions. +17:00:29 demographics can be a SIG, sure, but this SIG is about “[providing] a common platform for delivering turnkey CentOS-based solutions that are managed via a web and/or REST-based interface.” +17:00:33 key being tech and code and deliver +17:00:48 I think personally I need to find other people with similar interests. If the interest is there, we have another sig. +17:00:49 ( this isnt orthogonal to what you were saying omarel, but i wanted to quantify that ) +17:02:01 Remember, this is just me, and people have different points of view, but the issues I deal with on a daily basis are different than I think SLS is dealing with. +17:02:07 hi all +17:02:28 omarel: a SIG can deliver more than one end result :D +17:02:39 * alefattorini jumps in too +17:02:42 omarel, your idea is totally different from the SLS SIG proposal? Or similar and could be addressed with minor modifications to SLS? +17:02:45 there is no reason why the Small business SIG cant be doing more than SLS - actually, every SIG would +17:03:04 also, i dont think its going to be called SLS SIG, is it ? +17:03:24 :-) +17:03:27 http://wiki.centos.org/SpecialInterestGroup/SLS +17:03:55 Yes it can. You know I need to sit down and write out what I have in mind and my motivation for it. It's more than can be elaborated her in this chat format. +17:03:55 ok, pretty sure its going to get rejected by the board +17:04:09 also, you need to make sure it clearly states that this is a proposed SIG, not accepted as yet +17:04:21 kbsingh: also worth noting that it's still a proposal, indeed +17:04:36 What criteria are we missing Karanbir? +17:04:49 SIG's are interest and tech driven, not a specific deliverable +17:04:54 eg. its not the XEN SIG - its the Virt SIG +17:05:04 and its not the GLUSTER SIG- its the Storage SIG +17:05:19 the virt-sig is already working with a upstream qemu onramp and openvz is making efforts in +17:05:27 similarly the storage sig already includes ceph and gluster +17:06:00 The "tech" is moving from CLI and X-Windows based systems to API/REST-based interfaces. +17:06:03 What specific technology are we advocating. I’m pretty sure the individual members all use different technologies to deliver a wide array of deliverables. +17:06:22 For example, Filippo’s project doesn’t do what my project does and vice, versa. +17:06:27 so in that mindsetup Simplified Linux Server does not fit into the larger model at all - a Small Office SIG can however work to deliver a simplified SOHO server install set ( as an example ) +17:07:35 things like this are far too ambigious "The SIG members are involved in the development and maintenance of turnkey solutions based on CentOS. " +17:07:40 #action modify sls wiki page -> Status: proposal +17:07:59 what does that mean ? are you guys also working on the MIPS vlsi poc using centos in an embedded role for industrial automation ? +17:08:03 SOHO seems to be more of a deliverable than Simplified Linux Server. For example, I can simplify the process for provisioning large directory services based on an array of different backends and that would not be a SOHO application. But it would still be ‘Simplified’ through a web UI. +17:09:06 I don’t know about Filippo but we’ve discussed applying what we are doing to other architectures including MIPS. +17:09:36 we'd like to have arm support, but we'll follow upstream +17:09:59 my understanding of this sig is that the aim is to deliver a set of solutions for small business , new linux users doing entry level admin work in small offices / soho environs +17:11:08 seondly, who is proposing the SIG to the board ? I dont see any of the CentOS Board guys on the who's involved list +17:11:44 But the reason for bringing this together is to come up with common build needs and processes that are common among our technologies. For example, Filippo’s team and our team benefit from an accelarated path to getting newer PHP code. Others involved don’t need that but there are crossover needs at multiple levels. +17:11:48 what i would recommend is actually working the proposal to include specific deliverables +17:11:53 and remove stuff like "Software Maintenance - This SIG will co-ordinate maintenance of common upstream packages in order to avoid duplication and provide a better experience for all CentOS users. " +17:12:16 and "Quality Assurance - This SIG provides solutions with tight integration amongst the various applications in CentOS. This provides a unique opportunity to provide additional QA testing (e.g. Samba + OpenLDAP). " +17:12:26 basically, that deliverables section - someone needs to write one +17:12:56 #action expand Deliverables section +17:13:11 Are we required to have board sponsorship in order to get a SIG approved. Who can we contact then to have an advocate? +17:13:55 daveloper: the list of board members is listed on the centos website - you should be ok to contact any / all of them if you want +17:13:56 I hope that Evolution could help us +17:14:06 i think he's i brazil at the moment +17:14:07 daveloper: well, the board needs to approve a SIG proposal during a board meeting, so if you don't ask, nothing will be discussed :-) +17:14:53 correct, but karanbir seems to indicate that we need to have a board member on our SIG team in order for this to be a reality. I did not know that this was a requirement. +17:15:03 daveloper: it is +17:15:24 I thought it was a member of the dev team. That's what's on the Wiki page. +17:15:40 a completely mature SIG, is able to do their own process work - but we esitmate a 2 yr span from going onboard to maturity for a highly organised sig +17:15:42 daveloper: http://wiki.centos.org/SpecialInterestGroup/ but all Devteam members are on the board +17:15:48 we probably need to "polish" the proposal before asking for approval +17:16:22 stuff like Clam from EPEL - but does this sig have access to influence that build in EPEL ? if not, you are already creating deadends +17:16:30 filippoc: yes please +17:16:36 No matter. At this stage, we're still trying to figure out the whole role/scope of a SIG. Even looking through the wiki and centos-devel list, there seems to be a lot of unknowns. That's expected given that it's the early days! +17:16:45 Arrfab: The web page probably needs to be cleared up in that regard. +17:17:26 https://bugzilla.redhat.com/show_bug.cgi?id=1018312 +17:18:30 filippoc: so you need rsc to join the SIG +17:18:48 pcbaldwin: Bahhumbug: please submit patch +17:18:56 or an issue report at bugs.centos.org +17:19:06 kbsingh: probably a good idea +17:19:45 kbsingh: patch for the wiki page?? +17:20:02 kbsingh: hm? +17:20:07 It's a wiki page. It's a 30 second edit. +17:21:56 submit patch, a community notion of saying 'come help fix that which needs attention, and since you have the attention..' +17:21:56 omarel: could you write your ideas on a mail to centos-devel? +17:22:20 filippoc: daveloper: its also important to highlight what exactly is going to get done +17:23:10 eg. the QA stuff might be : develop as a part of the SIG, a test suite that can be run on a nightly basis from ci.dev.centos.org to validate a spec ( also to be developed as a part of the SIG ) - QA test harness being a precursor to code development in the SIG +17:23:19 we will release rpms +17:23:22 Looking at the requirements: We don’t have overlap with other SIGs so far as I can tell. We’ve opened a discussion topic and have solicited comments. Have we requested a new mailing list? We do have a wiki section. We will need version control setup. We are listed as a SIG on the SIG page. We need one Devteam member to join the team. Is there anything I missed? +17:23:52 we will write a testsuite +17:24:09 kbsingh, filippoc: How can I help regarding RHBZ#1018312? Or what is with which SIG? +17:24:10 davidep is already working on it +17:24:11 filippoc: quantifying that on the proposal will help +17:24:44 Arrfab, kbsingh: what about the CI platform for SIGs? any progress on it? +17:24:45 rsc: sorry, it was an bad example to show that we work with epel +17:24:52 also, who is going to run the SIG, what or how are you going to bring more members in, what licenses are you guys going to use - what is the downstream going to be etc. +17:24:59 Filippo, you may have seen that we have been got some basic testing working.... +17:25:13 get as much of this pre-done, better chances to get in through the board review +17:25:29 rretp, I meant t_functional on ci.centos +17:25:41 reetp sorry +17:25:50 filippoc: it does not need to be in t_functional. it can be a completely different suite +17:26:03 Which SIGs have already been approved? +17:26:11 eg. the virt-sig is starting the t_xen.git suite +17:26:21 I thought it was better trying to extend t_functional and improve ci.centos +17:26:32 but ok +17:26:34 * kbsingh off, call time, back in a few hours +17:26:56 Have a chat with Ian when you get a minute and see where they are at. +17:26:59 filippoc: thats ok as well - but ci.d.c.o can run more tests than just that +17:28:28 daveloper, I'll try to exapnd the Deliverables section of our proposal +17:28:59 Thanks Filippo, I’ll work with you on that in the shared doc if you like. +17:29:26 maybe I could simply list rpm packages from your web page +17:29:53 I’m curious as to who already has been approved so we can know what to follow or emulate. +17:29:57 Can you share the doc with other members of our Board ? I can give you addresses +17:30:21 only virt sig I think +17:30:44 reetp: sure +17:31:02 I'll give you full control +17:31:53 Are there any other objectives to cover here? +17:32:02 mmh, we should probably start a new doc, that old one is already a wiki page +17:32:03 Thanks -I'm sure some of the others will chime in. +17:32:11 I have to head out. At a fundamental level, it would be nice for all of us (NethServer, SME Server, ClearOS and potentially others) to have a working relationship with CentOS/RHEL. We're part of the ecosystem and I personally have always felt like an outsider. I'm certainly not getting the warm and fuzzies, but maybe that's just because it's IRC. Or maybe there's a lot on the CentOS team's plate right now. Oh well, I'll keep on +17:32:16 agreed. +17:32:36 agreed +17:32:41 keep on trucking = keep on trying to build the relationship +17:32:50 Thanks Peter. I get that sense as well. +17:33:07 We're agreed on something then :-) +17:33:34 Also a call would be good. I’ll try to set that up next week sometime. +17:34:02 An obvious note is that perhaps their documentation and expectation s are not really clear enough and they should address that. WE can only work to what they give us. +17:34:06 I'll try to solicit comments to our sig proposal on the centos-devel ml +17:34:39 #action ask for comments on centos-devel +17:35:33 I gotta go - only 45 mins late. Interesting and will look back through this later. +17:35:48 Filippo, have we formally requested version control for our SIG? +17:36:22 not sure if we did formally +17:36:37 Also, we need to secure a mailing list for ourselves. +17:36:43 we asked tough +17:36:58 I’m not sure who we do that with on the centos team. +17:38:21 keeping discussion on centos-devel for a while will probably be beneficial +17:38:48 but I'm sure we need to have our ml sooner than later +17:39:22 filippoc: you need to get approved first +17:39:33 #action talk to Jim for advice on a board member to sponsor the SLS SIG +17:39:34 then the resources become available immediately +17:39:49 got it +17:40:37 Getting a mailing list is listed as a requirement before approval. +17:40:48 seemed backwards to me too +17:41:14 so then the only thing we need is a devteam member on our group and then we can present, yeah? +17:41:25 We’ll clean up our proposal though first. +17:43:43 quoting kbsingh: "key being tech and code and deliver" +17:45:06 daveloper: I will ask for editing permission for you on centos wiki +17:45:18 thanks +17:45:23 register and send me your username +17:46:20 daveloper, filippoc: I think we also need to extend the section about how to join the SIG and who is in charge to evaluate new members +17:46:40 I'll ask for permissions for you too +17:46:59 gsanchietti: register and so on... +17:48:42 I'd end this meeting, but I'd like to schedule next week +17:49:38 we have a lot of stuff to do:-) +17:50:22 have a nice weekend +17:50:28 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/may/centos-devel.2014-05-09-16.52.txt b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.txt new file mode 100644 index 0000000..c53df7d --- /dev/null +++ b/static/minutes/2014/may/centos-devel.2014-05-09-16.52.txt @@ -0,0 +1,71 @@ +===================== +#centos-devel Meeting +===================== + + +Meeting started by filippoc at 16:52:43 UTC. The full logs are available +at centos-devel/2014/centos-devel.2014-05-09-16.52.log.html . + + + +Meeting summary +--------------- +* LINK: http://wiki.centos.org/SpecialInterestGroup/SLS (daveloper, + 17:03:27) +* ACTION: modify sls wiki page -> Status: proposal (filippoc, 17:07:40) +* ACTION: expand Deliverables section (filippoc, 17:12:56) +* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1018312 (filippoc, + 17:17:26) +* ACTION: ask for comments on centos-devel (filippoc, 17:34:39) +* ACTION: talk to Jim for advice on a board member to sponsor the SLS + SIG (filippoc, 17:39:33) + +Meeting ended at 17:50:28 UTC. + + + + +Action Items +------------ +* modify sls wiki page -> Status: proposal +* expand Deliverables section +* ask for comments on centos-devel +* talk to Jim for advice on a board member to sponsor the SLS SIG + + + + +Action Items, by person +----------------------- +* **UNASSIGNED** + * modify sls wiki page -> Status: proposal + * expand Deliverables section + * ask for comments on centos-devel + * talk to Jim for advice on a board member to sponsor the SLS SIG + + + + +People Present (lines said) +--------------------------- +* filippoc (47) +* kbsingh (43) +* daveloper (29) +* omarel (8) +* reetp (7) +* pcbaldwin (7) +* Arrfab (4) +* centbot (3) +* davidep (3) +* gsanchietti (3) +* JPP_kimsufi (3) +* rsc (2) +* Bahhumbug (2) +* alefattorini (2) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/september/centos-devel.2014-09-15-13.01.html b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.html new file mode 100644 index 0000000..9f91753 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.html @@ -0,0 +1,143 @@ + + + + +#centos-devel Meeting + + + + +

#centos-devel Meeting

+ +Meeting started by bstinson at 13:01:06 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. Is this a good time to meet? (bstinson, 13:02:45) +
      +
    1. AGREED: Weekly + meetings on Monday at 13:00 UTC (bstinson, + 13:05:18)
      2. +
    +
    2. +
  2. SIG/Developer authentication (bstinson, 13:06:54) +
      +
    1. Next meeting: Monday 22-Sept 2014 13:00 + UTC (bstinson, + 13:57:21)
      2. +
    2. We will be doing 6 weekly meetings, then moving + to a bi-weekly schedule (bstinson, + 13:58:12)
      3. +
    3. ACTION: MerlinTHP_ + Research lookaside cache authentication and upload + permissions (bstinson, + 13:59:21)
      4. +
    4. ACTION: alphacc + investigate koji policy for cbs. (alphacc, + 14:03:00)
      5. +
    5. send agenda items for next week to the + centos-devel@centos.org (bstinson, + 14:03:53)
      6. +
    +
    3. +
+

+ + + + +Meeting ended at 14:05:31 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. MerlinTHP_ Research lookaside cache authentication and upload permissions
    2. +
  2. alphacc investigate koji policy for cbs.
    3. +
+

+ + + +

Action items, by person

+
    +
  1. alphacc
      +
    1. alphacc investigate koji policy for cbs.
      2. +
    2. +
  2. MerlinTHP_
      +
    1. MerlinTHP_ Research lookaside cache authentication and upload permissions
      2. +
    3. +
+

+ + + +

People present (lines said)

+
    +
  1. MerlinTHP_ (96)
    2. +
  2. kbsingh (67)
    3. +
  3. bstinson (34)
    4. +
  4. alphacc (29)
    5. +
  5. gwd (7)
    6. +
  6. Evolution (7)
    7. +
  7. Arrfab (5)
    8. +
  8. centbot (4)
    9. +
  9. lalatenduM (3)
    10. +
  10. wolfy (1)
    11. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.html b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.html new file mode 100644 index 0000000..5633662 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.html @@ -0,0 +1,280 @@ + + + + +#centos-devel log + + + + +
13:01:06 <bstinson> #startmeeting
+13:01:06 <centbot> Meeting started Mon Sep 15 13:01:06 2014 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
+13:01:06 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+13:01:27 <bstinson> #meetingname CBS-Infra-2014-09-15
+13:01:27 <centbot> The meeting name has been set to 'cbs-infra-2014-09-15'
+13:01:52 <bstinson> #chair alphacc Arrfab kbsingh bstinson MerlinTHP_
+13:01:52 <centbot> Current chairs: Arrfab MerlinTHP_ alphacc bstinson kbsingh
+13:02:45 <bstinson> #topic Is this a good time to meet?
+13:02:54 <MerlinTHP_> Well, it works for me :)
+13:03:51 <alphacc> Me too if we keep it under 30 min
+13:04:01 <bstinson> Good, I think we should make this a regular thing (weekly, or every-other-week) for a while until we run out of things to talk about
+13:04:09 * MerlinTHP_ nods.
+13:04:11 <bstinson> short meetings are good
+13:04:17 <alphacc> I think weekly is good for now.
+13:04:39 <MerlinTHP_> Agreed, i imagine we can find things to talk about
+13:04:57 <wolfy> works for me too. although I am just a lurker
+13:05:18 <bstinson> #agreed Weekly meetings on Monday at 13:00 UTC
+13:06:36 * lalatenduM is here too
+13:06:54 <bstinson> #topic SIG/Developer authentication
+13:07:39 <alphacc> so far cbs has his own CA, I don't know the status of git.c.o auth
+13:07:53 * MerlinTHP_ assumes it's ssh key auth
+13:07:59 <MerlinTHP_> Can anyone confirm?
+13:08:08 * kbsingh is here
+13:08:14 * gwd is here
+13:08:17 <bstinson> we also need to worry about the lookaside cache
+13:08:42 <MerlinTHP_> I'd be tempted to start from a default position of "what does fedora infra do?"
+13:09:01 <MerlinTHP_> If only that they've solved a lot of this stuff, and have existing tooling
+13:09:10 <bstinson> I think FAS is on the radar
+13:09:24 <kbsingh> i am not sure if FAS is indeed on the store for CentOS though - is it ?
+13:09:38 <MerlinTHP_> I've heard it mentioned, but nothing conclusive.
+13:09:49 <kbsingh> there certainly hasent been any movement on that front - FAS was brought up a few times, but only in line with other potential solutions as well
+13:09:49 <gwd> What's FAS?
+13:09:57 <Arrfab> alphacc: atm git.c.o uses his internal auth DB
+13:09:58 <kbsingh> gwd: the Fedora Accounting System
+13:09:59 <MerlinTHP_> Fedora Account System
+13:10:24 <MerlinTHP_> I'm not sure we really want to build something from scratch.
+13:10:33 <alphacc> Arrfab: but gitblit does support ssl cert ?
+13:10:45 <kbsingh> git.centos.org can more or less do anything, includiung ldap, krb, shared certs, shared ca, pub certs, internal pipe backend for auth or even static files
+13:10:51 <kbsingh> alphacc: yes
+13:10:57 <MerlinTHP_> What does g.c.o do now?
+13:11:13 <kbsingh> MerlinTHP_: flat file, internal auth
+13:11:24 <MerlinTHP_> I suppose we're at the point of not having a huge userbase to reeducate
+13:12:24 <kbsingh> are we talking purely in the context of git.centos.org + cbs.centos.org ? I guess having FAS like system would help if were to come up system wide for all of .centos.org - and we can move wiki + bugs + forums + other things to it as well
+13:12:41 <MerlinTHP_> I'd suggest that ideally the latter
+13:13:15 <MerlinTHP_> In addition to FAS, I'd be tempted to throw IPA into the ring as an option too.
+13:13:48 <MerlinTHP_> I spend a fair amount of time in $dayjob getting stuff to auth against our IPA instace.
+13:14:04 <Arrfab> MerlinTHP_: such discussion started too, but the scope is wider than just cbs+git which is supposed to be the "to be discussed points" today
+13:14:06 <alphacc> kbsingh: yes. In term of interaction between cbs/git we just need people to be able to create branches at the git level
+13:14:26 <MerlinTHP_> Arrfab: agreed.
+13:14:38 <MerlinTHP_> Seems silly to build something just for cbs & git, though
+13:15:34 <kbsingh> how would branches in git.c.o work - at the moment, the distro brach is locked - noone can commit to those. and I've been working to have branch name be the sig name for someone
+13:15:37 <alphacc> MerlinTHP_: I think it's better to test the workflow for building and defer auth for later.
+13:15:54 <kbsingh> eg. VirtSig people will need to work with their own branch - but wont be able to create and push to other ones, unless they had acl's for other sig's as well
+13:16:21 <MerlinTHP_> alphacc: I'm just a bit worried about getting people too familiar with something that we might well change later
+13:16:21 <Arrfab> MerlinTHP_: agreed too, but it would be good to know what are the blockers now on the git/cbs status. and if common auth is the real issue, then another meeting around centralized auth can be foreseen :-)
+13:17:19 <alphacc> MerlinTHP_: the koji part won't change, and educate user to access git with pass or ssh key doesn't seems an issue for our audience
+13:17:27 <MerlinTHP_> alphacc: fair enough
+13:17:40 <gwd> kbsingh: So I think we need to be able to have dev branches from which we can issue a pull request.
+13:17:50 <alphacc> MerlinTHP_: I would agree if it was for everybody.
+13:18:29 <MerlinTHP_> alphacc: I'm a bit worried that you don't scale, though ;)
+13:18:37 <MerlinTHP_> alphacc: you're doing all the account creation by hand atm?
+13:19:04 <alphacc> MerlinTHP_: correct. this is part of this week documentation effort.
+13:19:05 <Arrfab> MerlinTHP_: yes, but afaik less than 10 people have access through approved SIGs
+13:19:17 <kbsingh> in terms of forward-looking-planning, my estimate on user accounts to end of the year 2014 is 50
+13:19:27 <MerlinTHP_> OK
+13:19:27 <kbsingh> and in the next 18 momths, is to grow that to 150
+13:19:44 <bstinson> which is not so bad
+13:20:10 <kbsingh> most SIG's are only going to have a few people commiting into git.centos.org right ? I'm counting on the biggest ones having 10
+13:20:18 <Evolution> I still think long-term it should be automated, rather than blocking on a specific person
+13:20:27 <Evolution> or group of people.
+13:20:31 <MerlinTHP_> Mm
+13:20:48 <MerlinTHP_> This is one of those "FAS has already solved this issue" things, tbh
+13:21:04 <kbsingh> gwd: would'nt that be local though ? eg. if come of people want to do local branches ? or are you saying that people will need commit access to git.centos.org where from a 'privileged' account can merge into the production branch and issue a build req ?
+13:21:06 <Evolution> yeah. fas or a bit of scripting around ipa.
+13:21:11 <MerlinTHP_> Evolution: exactly
+13:21:27 <alphacc> Evolution: yes agreed
+13:21:36 <MerlinTHP_> TBH I personally like IPA a lot, but I'm trying not to be too biased ;)
+13:22:01 <kbsingh> gwd: if we want the push coming to git.centos.org - we might need to workout some sort of a convention for personal branches.
+13:22:18 <kbsingh> automate everything
+13:22:49 <gwd> kbsingh: Well it doesn't need to be on git.c.o, if that's what you mean; it could be on gitorious/github/some other public repo.  But wherever it is, we want to be able to build from it.  At least, I assume the burden of testing to make sure it builds properly should be on the person sending the pull request, not on the person potentially doing the pulling. :-)
+13:23:04 <kbsingh> specially, since automation is the only way to really make sure there is a 'user-exiting' cleanup process as well
+13:23:15 <MerlinTHP_> Just bear in mind that koji needs config for each git server you want to pull from
+13:23:26 <kbsingh> MerlinTHP_: it will only pull from git.centos.org
+13:23:27 <MerlinTHP_> I'd recommend only having koji pull from g.c.o
+13:23:33 <MerlinTHP_> Right.
+13:23:39 <alphacc> yes
+13:24:02 <MerlinTHP_> So anything you want to build has to end up in g.c.o, even if people are pushing to github or whatever
+13:24:34 <Arrfab> MerlinTHP_: yes
+13:24:43 <kbsingh> yeah, its a good problem domain to fix, its the classic who CI's and how does the CI queue work
+13:24:46 <alphacc> MerlinTHP_: There is SRPM use case, but I really didn't find any good reason.
+13:24:47 <gwd> MerlinTHP: Then that would imply either 1) sending pull requests from trees that haven't been tested on koji or 2) having development trees on git.c.o so that things could be tested on koji before sending a pull request
+13:25:06 <kbsingh> i wonder if we can have people do scratch builds, and the results be a consideation for people doing the pulls
+13:25:16 <alphacc> gwd: koji should not become a CI.
+13:25:28 <MerlinTHP_> Yeah, koji isn't great for CI
+13:25:37 <kbsingh> i dont think gwd is talking CI though
+13:25:51 <MerlinTHP_> Right.
+13:25:53 <kbsingh> were not testing the code, per se - its just to make sure the branch is buildable
+13:26:04 <kbsingh> maybe --scratch builds might be a middle ground there ?
+13:26:05 <alphacc> Yes just a warning, casue I have koji users :)
+13:26:21 <gwd> Just because it build via an SRPM doesn't mean it will build from a git tree. :-)
+13:26:44 <MerlinTHP_> There's not that much difference between koji building a package and mock on a user box, as long as mock is using the koji repos.
+13:26:54 <kbsingh> gwd: right, but koji only ever builds from a srpm - the git is just where the srpm is stored, were never building from git
+13:27:15 <kbsingh> when koji gets a build-this, it git checksout, make it into an srpm - then does the mock run to build rpms out of it
+13:27:17 <MerlinTHP_> Well, koji pulls the source from git and builds a srpm
+13:27:24 <alphacc> kbsingh: yes
+13:27:24 <MerlinTHP_> Yeah, tha
+13:27:25 <MerlinTHP_> t
+13:28:13 <bstinson> (bringing it back in a little bit) it sounds to me like we aren't quite ready to talk about long-term auth
+13:28:21 <kbsingh> nutshell: gwd's point is that people need to be able to propose changes, without running their own buildsystems. right ?
+13:28:24 * MerlinTHP_ is getting that ;)
+13:28:28 <MerlinTHP_> +feeling
+13:29:30 <bstinson> what can we do in the short term to get people access to the lookaside caches? i know that's come up a couple of times
+13:29:45 <MerlinTHP_> Auth with the same SSL cert they use for koji?
+13:30:10 <alphacc> bstinson: I think we need at least docs on the process will be handled.
+13:30:27 <MerlinTHP_> The upload script for fedora's lookaside is public, and can be easily adapted to our cache
+13:31:07 <MerlinTHP_> I can hunt that out if there's interest
+13:31:07 <alphacc> MerlinTHP_: can it be part of centpkg ?
+13:31:11 <kbsingh> are we talking about https://git.centos.org/sources/ ?
+13:31:26 <bstinson> kbsingh: yes
+13:31:27 <MerlinTHP_> Yeah
+13:31:35 <kbsingh> the privileged path to that store is via ssh or rsync over ssh at the moment
+13:31:42 <Evolution> 868963
+13:31:43 <MerlinTHP_> Hmm
+13:31:58 <kbsingh> but its a flat filesystem, so a cgi script ( like what fedora use ) might be easy to adapt, and we can protect branches at the unix level
+13:32:09 <Evolution> 195082
+13:32:16 <kbsingh> ( ie. I can make sure the buildsystem and distro branches are owned by someone else )
+13:32:27 <kbsingh> Evolution: move your yubi key to a different usb port
+13:32:32 <MerlinTHP_> Heh
+13:32:36 <alphacc> ah ah
+13:32:39 <Evolution> bah, was dialing phone.
+13:32:47 <kbsingh> alternatively, folks - anyone needing to break into Evolution's 2FA accounts, you ahve about 180 seconds to use those two codes
+13:32:48 * Evolution moves laptop
+13:32:50 <MerlinTHP_> No, you weren't ;)
+13:32:55 <bstinson> heh
+13:33:18 <kbsingh> i need a better keyboard, way too many typos
+13:33:31 <bstinson> alphacc: to answer your question, it's already built into rpkg we just need to figure out how to say if a user has upload privs or not
+13:33:32 <kbsingh> so, what / how would centpkg integrate with the sources / lookaside push ?
+13:33:47 <MerlinTHP_> centpkg has upload support
+13:33:57 <MerlinTHP_> It needs tweaking for centos' cache layout
+13:34:11 <MerlinTHP_> It does an HTTPS request with the client cert for auth
+13:34:42 <MerlinTHP_> sorry, rpkg has that, centpkg can override that code
+13:35:02 <alphacc> ok
+13:35:14 <kbsingh> what do we need on the server to support that push ?
+13:35:31 <MerlinTHP_> A CGI script on an HTTPS server with some client auth config
+13:35:41 <MerlinTHP_> So cgi + httpd config
+13:35:47 <kbsingh> what sort of auth backend can that support ?
+13:36:05 <kbsingh> also, upload via https.... is going to need some multipart fluffery
+13:36:40 <MerlinTHP_> That bit is a solved problem, afaik.  rpkg already does it
+13:36:57 <MerlinTHP_> The server validates the client cert against our CA
+13:37:14 <MerlinTHP_> Needs a CRL to be able to revoke certs.
+13:38:14 <kbsingh> right, so this would then share the ca with koji ?
+13:38:19 <MerlinTHP_> Yeah
+13:38:39 <kbsingh> and we'd need to have git.centos.org also then use the same CA
+13:38:47 <MerlinTHP_> Mm
+13:38:55 <MerlinTHP_> IPA getting more attractive by the second...
+13:38:56 <MerlinTHP_> ;)
+13:39:31 <alphacc> if we keep the koji CA (and use it for soemthing else) we may want to move easy_rsa + git-crypt (for scaling issue)
+13:39:37 <alphacc> or FreeIPA ;)
+13:40:36 <gwd> I'm more of a stout man myself...
+13:40:40 <kbsingh> gitblit can maknss calls as well if that makes life easier
+13:40:53 <kbsingh> can make nss
+13:41:22 <kbsingh> from the git.centos.org perspective, we can use pretty much anything and it will consume it .
+13:41:27 * MerlinTHP_ nods.
+13:41:49 <kbsingh> there are 2 things that we need to protect though - (1) there is always going to be a privileged path for rhel sources and buildsystem feedback - both of those can never fail
+13:42:09 <kbsingh> and (2) we need a way to gurantee branch names and commit access to branch names is locked down
+13:42:33 <bstinson> does gitblit currently give you that control?
+13:42:34 <kbsingh> so if the auth setup is going to happen at koji CA - that needs to provide a user:sig name mapping which can be used to map users:branch
+13:42:34 <MerlinTHP_> Can gitblit do that per-branch stuff?
+13:42:38 <kbsingh> bstinson: yes.
+13:42:52 <MerlinTHP_> Hrm
+13:43:20 <MerlinTHP_> We need more than just a CA for this
+13:43:30 <MerlinTHP_> CA + something with groups and things like that.
+13:43:33 <kbsingh> I worked with the author of gitblit ( james moger ) to work that in, and I've made some more tweaks at this end that make it work quite nicely
+13:43:49 <MerlinTHP_> That's cool.
+13:44:10 <kbsingh> for the git code itself, and the lookaside cache - the privleged path is via ssh
+13:44:28 <kbsingh> and gitblit does not mind that, it will happy refresh local git content cache if it finds the underlaying storage changee
+13:44:53 <MerlinTHP_> I'd have assumed that git+ssh was the default push method anyway
+13:45:06 <kbsingh> fwiw, gitolite can also consume and implement a user:branch mapping
+13:45:37 <kbsingh> push mode for git is over https
+13:45:41 <MerlinTHP_> Oh, ok
+13:45:54 <kbsingh> thinking there is that if we need entity verification, an EV cert will give you that
+13:46:31 <MerlinTHP_> Do we have a cert revocation system for the current koji CA?
+13:46:48 <MerlinTHP_> If I lose my laptop with koji cert now, what happens?
+13:47:09 <alphacc> MerlinTHP_: we can revoke access to koji
+13:47:23 <alphacc> MerlinTHP_: no crl right now but agreed it's needed.
+13:47:55 <MerlinTHP_> Is that turn off the user, or turn off the cert?
+13:48:05 <MerlinTHP_> ( so to speak )
+13:48:16 <alphacc> MerlinTHP_: user
+13:48:21 * MerlinTHP_ nods.
+13:49:02 <bstinson> ok, let's start wrapping up
+13:49:07 <alphacc> MerlinTHP_: user-rsa when Arrfab show me it existed. I don't want to reinvent the wheel.
+13:49:16 <MerlinTHP_> alphacc: *nod*
+13:49:23 <alphacc> MerlinTHP_: easy_rsa
+13:49:26 <MerlinTHP_> Being a CA is a PITA.
+13:49:45 <MerlinTHP_> OK, so, do we have any sort of consensus? :)
+13:49:54 <MerlinTHP_> Or anything to have a consensus about
+13:50:34 <MerlinTHP_> koji requires either SSL or KRB auth, and we're using SSL.  Trying to use that for everything we can sounds appropriate?
+13:50:44 <MerlinTHP_> Sounds like g.c.o can use it
+13:51:07 <bstinson> so (if i'm understanding correctly), we want gitblit to talk to the koji CA but we need to work out some name:sig mappings, and we want to look at having the lookaside cache use the fedora-style cgi script
+13:51:08 <MerlinTHP_> We need a way to store cert / user / group / sig info
+13:52:00 <kbsingh> yeah, if we can get some groups info in there that would rock
+13:52:16 <MerlinTHP_> OK
+13:52:16 <kbsingh> if not, we can always store user:group mappings in gitblit itself, and just have it querry the CA for auth
+13:52:31 <MerlinTHP_> I reckon we probably want that centrally too
+13:52:41 <kbsingh> and i presume the upload script can do something with the same CA as well ... if so - then we should trial it - or start trialing it at git.dev.centos.org
+13:52:53 <kbsingh> yeah, ideally all the info would be in one place
+13:53:01 <MerlinTHP_> It's the httpd config rather than the script itself, but yeah
+13:53:40 <kbsingh> ah i see
+13:53:50 <kbsingh> but will that be able to map user's to dir names ?
+13:53:59 <bstinson> once all that's in place we can sculpt centpkg around our setup
+13:54:04 <kbsingh> eg. if someone is locked to branch 'virtsig' they can only upload into <packagename>/virtsig/
+13:54:17 <MerlinTHP_> kbsingh: ok, that bit would need script changes :)
+13:54:40 <MerlinTHP_> the httpd-level stuff is authn, the authz would need to be in the script, I think
+13:55:28 <bstinson> Is MerlinTHP_ volunteering to look at that for the next meeting?
+13:55:36 <MerlinTHP_> Sure
+13:56:30 <bstinson> ok, great!
+13:56:35 <MerlinTHP_> :)
+13:56:47 <MerlinTHP_> Running out of meeting
+13:56:48 <kbsingh> when are we meeting next ?
+13:56:54 <MerlinTHP_> Same time next week?
+13:57:09 <kbsingh> ok, weekly works, but longer term we should think about making it bi-weekly
+13:57:13 <MerlinTHP_> Sure
+13:57:18 <kbsingh> maybe do ~ 6 weekly ones ?
+13:57:21 <bstinson> #info Next meeting: Monday 22-Sept 2014 13:00 UTC
+13:57:36 <bstinson> kbsingh: that's reasonable
+13:57:40 * MerlinTHP_ nods.
+13:58:12 <bstinson> #info We will be doing 6 weekly meetings, then moving to a bi-weekly schedule
+13:58:14 <lalatenduM> works for /Me
+13:58:24 <MerlinTHP_> Is there a meetbot give-merlinthp-an-action command? ;)
+13:58:41 * MerlinTHP_ should read the manual
+13:59:20 <lalatenduM> does "#action" work
+13:59:21 <bstinson> #action MerlinTHP_ Research lookaside cache authentication and upload permissions
+13:59:35 <MerlinTHP_> Ah :)
+13:59:42 <bstinson> i think i said that right
+13:59:52 <MerlinTHP_> Works for me.
+13:59:54 <bstinson> anything else that needs to go in the minutes?
+14:00:07 <kbsingh> is someone going to look at storing user:groups in the koji auth layers
+14:00:18 <MerlinTHP_> I'll have a think about that too
+14:00:19 <kbsingh> there must be something like this already - since users are limited to some tag's and targets
+14:00:27 <kbsingh> cant those just be the groups and sig names as well
+14:01:32 <alphacc> kbsingh: user are limited to the tagging action not to some target. This policy stuff need investigation. I don't think there is a group directive.
+14:02:54 <MerlinTHP_> OK, so we done with the meeting? :)
+14:02:59 <bstinson> gwd: i think that was you who sent a message to -devel with other agenda items, sorry our discussion sort of trampled over yours
+14:03:00 <alphacc> #action alphacc investigate koji policy for cbs.
+14:03:08 <bstinson> hopefully there will be time for an open-flood next week
+14:03:53 <bstinson> #info send agenda items for next week to the centos-devel@centos.org
+14:04:01 <bstinson> 1 minute warning before I close the minutes
+14:04:16 <MerlinTHP_> I'm good.
+14:04:44 <kbsingh> same here
+14:05:02 <kbsingh> i think were going to need some of these sessions of just open chat before we start working on and only on agenda items.
+14:05:04 <alphacc> ok with me.
+14:05:28 <bstinson> sure thing
+14:05:31 <bstinson> #endmeeting
+ diff --git a/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.txt b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.txt new file mode 100644 index 0000000..c2bb82c --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.log.txt @@ -0,0 +1,253 @@ +13:01:06 #startmeeting +13:01:06 Meeting started Mon Sep 15 13:01:06 2014 UTC. The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot. +13:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic. +13:01:27 #meetingname CBS-Infra-2014-09-15 +13:01:27 The meeting name has been set to 'cbs-infra-2014-09-15' +13:01:52 #chair alphacc Arrfab kbsingh bstinson MerlinTHP_ +13:01:52 Current chairs: Arrfab MerlinTHP_ alphacc bstinson kbsingh +13:02:45 #topic Is this a good time to meet? +13:02:54 Well, it works for me :) +13:03:51 Me too if we keep it under 30 min +13:04:01 Good, I think we should make this a regular thing (weekly, or every-other-week) for a while until we run out of things to talk about +13:04:09 * MerlinTHP_ nods. +13:04:11 short meetings are good +13:04:17 I think weekly is good for now. +13:04:39 Agreed, i imagine we can find things to talk about +13:04:57 works for me too. although I am just a lurker +13:05:18 #agreed Weekly meetings on Monday at 13:00 UTC +13:06:36 * lalatenduM is here too +13:06:54 #topic SIG/Developer authentication +13:07:39 so far cbs has his own CA, I don't know the status of git.c.o auth +13:07:53 * MerlinTHP_ assumes it's ssh key auth +13:07:59 Can anyone confirm? +13:08:08 * kbsingh is here +13:08:14 * gwd is here +13:08:17 we also need to worry about the lookaside cache +13:08:42 I'd be tempted to start from a default position of "what does fedora infra do?" +13:09:01 If only that they've solved a lot of this stuff, and have existing tooling +13:09:10 I think FAS is on the radar +13:09:24 i am not sure if FAS is indeed on the store for CentOS though - is it ? +13:09:38 I've heard it mentioned, but nothing conclusive. +13:09:49 there certainly hasent been any movement on that front - FAS was brought up a few times, but only in line with other potential solutions as well +13:09:49 What's FAS? +13:09:57 alphacc: atm git.c.o uses his internal auth DB +13:09:58 gwd: the Fedora Accounting System +13:09:59 Fedora Account System +13:10:24 I'm not sure we really want to build something from scratch. +13:10:33 Arrfab: but gitblit does support ssl cert ? +13:10:45 git.centos.org can more or less do anything, includiung ldap, krb, shared certs, shared ca, pub certs, internal pipe backend for auth or even static files +13:10:51 alphacc: yes +13:10:57 What does g.c.o do now? +13:11:13 MerlinTHP_: flat file, internal auth +13:11:24 I suppose we're at the point of not having a huge userbase to reeducate +13:12:24 are we talking purely in the context of git.centos.org + cbs.centos.org ? I guess having FAS like system would help if were to come up system wide for all of .centos.org - and we can move wiki + bugs + forums + other things to it as well +13:12:41 I'd suggest that ideally the latter +13:13:15 In addition to FAS, I'd be tempted to throw IPA into the ring as an option too. +13:13:48 I spend a fair amount of time in $dayjob getting stuff to auth against our IPA instace. +13:14:04 MerlinTHP_: such discussion started too, but the scope is wider than just cbs+git which is supposed to be the "to be discussed points" today +13:14:06 kbsingh: yes. In term of interaction between cbs/git we just need people to be able to create branches at the git level +13:14:26 Arrfab: agreed. +13:14:38 Seems silly to build something just for cbs & git, though +13:15:34 how would branches in git.c.o work - at the moment, the distro brach is locked - noone can commit to those. and I've been working to have branch name be the sig name for someone +13:15:37 MerlinTHP_: I think it's better to test the workflow for building and defer auth for later. +13:15:54 eg. VirtSig people will need to work with their own branch - but wont be able to create and push to other ones, unless they had acl's for other sig's as well +13:16:21 alphacc: I'm just a bit worried about getting people too familiar with something that we might well change later +13:16:21 MerlinTHP_: agreed too, but it would be good to know what are the blockers now on the git/cbs status. and if common auth is the real issue, then another meeting around centralized auth can be foreseen :-) +13:17:19 MerlinTHP_: the koji part won't change, and educate user to access git with pass or ssh key doesn't seems an issue for our audience +13:17:27 alphacc: fair enough +13:17:40 kbsingh: So I think we need to be able to have dev branches from which we can issue a pull request. +13:17:50 MerlinTHP_: I would agree if it was for everybody. +13:18:29 alphacc: I'm a bit worried that you don't scale, though ;) +13:18:37 alphacc: you're doing all the account creation by hand atm? +13:19:04 MerlinTHP_: correct. this is part of this week documentation effort. +13:19:05 MerlinTHP_: yes, but afaik less than 10 people have access through approved SIGs +13:19:17 in terms of forward-looking-planning, my estimate on user accounts to end of the year 2014 is 50 +13:19:27 OK +13:19:27 and in the next 18 momths, is to grow that to 150 +13:19:44 which is not so bad +13:20:10 most SIG's are only going to have a few people commiting into git.centos.org right ? I'm counting on the biggest ones having 10 +13:20:18 I still think long-term it should be automated, rather than blocking on a specific person +13:20:27 or group of people. +13:20:31 Mm +13:20:48 This is one of those "FAS has already solved this issue" things, tbh +13:21:04 gwd: would'nt that be local though ? eg. if come of people want to do local branches ? or are you saying that people will need commit access to git.centos.org where from a 'privileged' account can merge into the production branch and issue a build req ? +13:21:06 yeah. fas or a bit of scripting around ipa. +13:21:11 Evolution: exactly +13:21:27 Evolution: yes agreed +13:21:36 TBH I personally like IPA a lot, but I'm trying not to be too biased ;) +13:22:01 gwd: if we want the push coming to git.centos.org - we might need to workout some sort of a convention for personal branches. +13:22:18 automate everything +13:22:49 kbsingh: Well it doesn't need to be on git.c.o, if that's what you mean; it could be on gitorious/github/some other public repo. But wherever it is, we want to be able to build from it. At least, I assume the burden of testing to make sure it builds properly should be on the person sending the pull request, not on the person potentially doing the pulling. :-) +13:23:04 specially, since automation is the only way to really make sure there is a 'user-exiting' cleanup process as well +13:23:15 Just bear in mind that koji needs config for each git server you want to pull from +13:23:26 MerlinTHP_: it will only pull from git.centos.org +13:23:27 I'd recommend only having koji pull from g.c.o +13:23:33 Right. +13:23:39 yes +13:24:02 So anything you want to build has to end up in g.c.o, even if people are pushing to github or whatever +13:24:34 MerlinTHP_: yes +13:24:43 yeah, its a good problem domain to fix, its the classic who CI's and how does the CI queue work +13:24:46 MerlinTHP_: There is SRPM use case, but I really didn't find any good reason. +13:24:47 MerlinTHP: Then that would imply either 1) sending pull requests from trees that haven't been tested on koji or 2) having development trees on git.c.o so that things could be tested on koji before sending a pull request +13:25:06 i wonder if we can have people do scratch builds, and the results be a consideation for people doing the pulls +13:25:16 gwd: koji should not become a CI. +13:25:28 Yeah, koji isn't great for CI +13:25:37 i dont think gwd is talking CI though +13:25:51 Right. +13:25:53 were not testing the code, per se - its just to make sure the branch is buildable +13:26:04 maybe --scratch builds might be a middle ground there ? +13:26:05 Yes just a warning, casue I have koji users :) +13:26:21 Just because it build via an SRPM doesn't mean it will build from a git tree. :-) +13:26:44 There's not that much difference between koji building a package and mock on a user box, as long as mock is using the koji repos. +13:26:54 gwd: right, but koji only ever builds from a srpm - the git is just where the srpm is stored, were never building from git +13:27:15 when koji gets a build-this, it git checksout, make it into an srpm - then does the mock run to build rpms out of it +13:27:17 Well, koji pulls the source from git and builds a srpm +13:27:24 kbsingh: yes +13:27:24 Yeah, tha +13:27:25 t +13:28:13 (bringing it back in a little bit) it sounds to me like we aren't quite ready to talk about long-term auth +13:28:21 nutshell: gwd's point is that people need to be able to propose changes, without running their own buildsystems. right ? +13:28:24 * MerlinTHP_ is getting that ;) +13:28:28 +feeling +13:29:30 what can we do in the short term to get people access to the lookaside caches? i know that's come up a couple of times +13:29:45 Auth with the same SSL cert they use for koji? +13:30:10 bstinson: I think we need at least docs on the process will be handled. +13:30:27 The upload script for fedora's lookaside is public, and can be easily adapted to our cache +13:31:07 I can hunt that out if there's interest +13:31:07 MerlinTHP_: can it be part of centpkg ? +13:31:11 are we talking about https://git.centos.org/sources/ ? +13:31:26 kbsingh: yes +13:31:27 Yeah +13:31:35 the privileged path to that store is via ssh or rsync over ssh at the moment +13:31:42 868963 +13:31:43 Hmm +13:31:58 but its a flat filesystem, so a cgi script ( like what fedora use ) might be easy to adapt, and we can protect branches at the unix level +13:32:09 195082 +13:32:16 ( ie. I can make sure the buildsystem and distro branches are owned by someone else ) +13:32:27 Evolution: move your yubi key to a different usb port +13:32:32 Heh +13:32:36 ah ah +13:32:39 bah, was dialing phone. +13:32:47 alternatively, folks - anyone needing to break into Evolution's 2FA accounts, you ahve about 180 seconds to use those two codes +13:32:48 * Evolution moves laptop +13:32:50 No, you weren't ;) +13:32:55 heh +13:33:18 i need a better keyboard, way too many typos +13:33:31 alphacc: to answer your question, it's already built into rpkg we just need to figure out how to say if a user has upload privs or not +13:33:32 so, what / how would centpkg integrate with the sources / lookaside push ? +13:33:47 centpkg has upload support +13:33:57 It needs tweaking for centos' cache layout +13:34:11 It does an HTTPS request with the client cert for auth +13:34:42 sorry, rpkg has that, centpkg can override that code +13:35:02 ok +13:35:14 what do we need on the server to support that push ? +13:35:31 A CGI script on an HTTPS server with some client auth config +13:35:41 So cgi + httpd config +13:35:47 what sort of auth backend can that support ? +13:36:05 also, upload via https.... is going to need some multipart fluffery +13:36:40 That bit is a solved problem, afaik. rpkg already does it +13:36:57 The server validates the client cert against our CA +13:37:14 Needs a CRL to be able to revoke certs. +13:38:14 right, so this would then share the ca with koji ? +13:38:19 Yeah +13:38:39 and we'd need to have git.centos.org also then use the same CA +13:38:47 Mm +13:38:55 IPA getting more attractive by the second... +13:38:56 ;) +13:39:31 if we keep the koji CA (and use it for soemthing else) we may want to move easy_rsa + git-crypt (for scaling issue) +13:39:37 or FreeIPA ;) +13:40:36 I'm more of a stout man myself... +13:40:40 gitblit can maknss calls as well if that makes life easier +13:40:53 can make nss +13:41:22 from the git.centos.org perspective, we can use pretty much anything and it will consume it . +13:41:27 * MerlinTHP_ nods. +13:41:49 there are 2 things that we need to protect though - (1) there is always going to be a privileged path for rhel sources and buildsystem feedback - both of those can never fail +13:42:09 and (2) we need a way to gurantee branch names and commit access to branch names is locked down +13:42:33 does gitblit currently give you that control? +13:42:34 so if the auth setup is going to happen at koji CA - that needs to provide a user:sig name mapping which can be used to map users:branch +13:42:34 Can gitblit do that per-branch stuff? +13:42:38 bstinson: yes. +13:42:52 Hrm +13:43:20 We need more than just a CA for this +13:43:30 CA + something with groups and things like that. +13:43:33 I worked with the author of gitblit ( james moger ) to work that in, and I've made some more tweaks at this end that make it work quite nicely +13:43:49 That's cool. +13:44:10 for the git code itself, and the lookaside cache - the privleged path is via ssh +13:44:28 and gitblit does not mind that, it will happy refresh local git content cache if it finds the underlaying storage changee +13:44:53 I'd have assumed that git+ssh was the default push method anyway +13:45:06 fwiw, gitolite can also consume and implement a user:branch mapping +13:45:37 push mode for git is over https +13:45:41 Oh, ok +13:45:54 thinking there is that if we need entity verification, an EV cert will give you that +13:46:31 Do we have a cert revocation system for the current koji CA? +13:46:48 If I lose my laptop with koji cert now, what happens? +13:47:09 MerlinTHP_: we can revoke access to koji +13:47:23 MerlinTHP_: no crl right now but agreed it's needed. +13:47:55 Is that turn off the user, or turn off the cert? +13:48:05 ( so to speak ) +13:48:16 MerlinTHP_: user +13:48:21 * MerlinTHP_ nods. +13:49:02 ok, let's start wrapping up +13:49:07 MerlinTHP_: user-rsa when Arrfab show me it existed. I don't want to reinvent the wheel. +13:49:16 alphacc: *nod* +13:49:23 MerlinTHP_: easy_rsa +13:49:26 Being a CA is a PITA. +13:49:45 OK, so, do we have any sort of consensus? :) +13:49:54 Or anything to have a consensus about +13:50:34 koji requires either SSL or KRB auth, and we're using SSL. Trying to use that for everything we can sounds appropriate? +13:50:44 Sounds like g.c.o can use it +13:51:07 so (if i'm understanding correctly), we want gitblit to talk to the koji CA but we need to work out some name:sig mappings, and we want to look at having the lookaside cache use the fedora-style cgi script +13:51:08 We need a way to store cert / user / group / sig info +13:52:00 yeah, if we can get some groups info in there that would rock +13:52:16 OK +13:52:16 if not, we can always store user:group mappings in gitblit itself, and just have it querry the CA for auth +13:52:31 I reckon we probably want that centrally too +13:52:41 and i presume the upload script can do something with the same CA as well ... if so - then we should trial it - or start trialing it at git.dev.centos.org +13:52:53 yeah, ideally all the info would be in one place +13:53:01 It's the httpd config rather than the script itself, but yeah +13:53:40 ah i see +13:53:50 but will that be able to map user's to dir names ? +13:53:59 once all that's in place we can sculpt centpkg around our setup +13:54:04 eg. if someone is locked to branch 'virtsig' they can only upload into /virtsig/ +13:54:17 kbsingh: ok, that bit would need script changes :) +13:54:40 the httpd-level stuff is authn, the authz would need to be in the script, I think +13:55:28 Is MerlinTHP_ volunteering to look at that for the next meeting? +13:55:36 Sure +13:56:30 ok, great! +13:56:35 :) +13:56:47 Running out of meeting +13:56:48 when are we meeting next ? +13:56:54 Same time next week? +13:57:09 ok, weekly works, but longer term we should think about making it bi-weekly +13:57:13 Sure +13:57:18 maybe do ~ 6 weekly ones ? +13:57:21 #info Next meeting: Monday 22-Sept 2014 13:00 UTC +13:57:36 kbsingh: that's reasonable +13:57:40 * MerlinTHP_ nods. +13:58:12 #info We will be doing 6 weekly meetings, then moving to a bi-weekly schedule +13:58:14 works for /Me +13:58:24 Is there a meetbot give-merlinthp-an-action command? ;) +13:58:41 * MerlinTHP_ should read the manual +13:59:20 does "#action" work +13:59:21 #action MerlinTHP_ Research lookaside cache authentication and upload permissions +13:59:35 Ah :) +13:59:42 i think i said that right +13:59:52 Works for me. +13:59:54 anything else that needs to go in the minutes? +14:00:07 is someone going to look at storing user:groups in the koji auth layers +14:00:18 I'll have a think about that too +14:00:19 there must be something like this already - since users are limited to some tag's and targets +14:00:27 cant those just be the groups and sig names as well +14:01:32 kbsingh: user are limited to the tagging action not to some target. This policy stuff need investigation. I don't think there is a group directive. +14:02:54 OK, so we done with the meeting? :) +14:02:59 gwd: i think that was you who sent a message to -devel with other agenda items, sorry our discussion sort of trampled over yours +14:03:00 #action alphacc investigate koji policy for cbs. +14:03:08 hopefully there will be time for an open-flood next week +14:03:53 #info send agenda items for next week to the centos-devel@centos.org +14:04:01 1 minute warning before I close the minutes +14:04:16 I'm good. +14:04:44 same here +14:05:02 i think were going to need some of these sessions of just open chat before we start working on and only on agenda items. +14:05:04 ok with me. +14:05:28 sure thing +14:05:31 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/september/centos-devel.2014-09-15-13.01.txt b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.txt new file mode 100644 index 0000000..e6f4882 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-15-13.01.txt @@ -0,0 +1,72 @@ +===================== +#centos-devel Meeting +===================== + + +Meeting started by bstinson at 13:01:06 UTC. The full logs are available +at centos-devel/2014/centos-devel.2014-09-15-13.01.log.html . + + + +Meeting summary +--------------- +* Is this a good time to meet? (bstinson, 13:02:45) + * AGREED: Weekly meetings on Monday at 13:00 UTC (bstinson, 13:05:18) + +* SIG/Developer authentication (bstinson, 13:06:54) + * Next meeting: Monday 22-Sept 2014 13:00 UTC (bstinson, 13:57:21) + * We will be doing 6 weekly meetings, then moving to a bi-weekly + schedule (bstinson, 13:58:12) + * ACTION: MerlinTHP_ Research lookaside cache authentication and + upload permissions (bstinson, 13:59:21) + * ACTION: alphacc investigate koji policy for cbs. (alphacc, + 14:03:00) + * send agenda items for next week to the centos-devel@centos.org + (bstinson, 14:03:53) + +Meeting ended at 14:05:31 UTC. + + + + +Action Items +------------ +* MerlinTHP_ Research lookaside cache authentication and upload + permissions +* alphacc investigate koji policy for cbs. + + + + +Action Items, by person +----------------------- +* alphacc + * alphacc investigate koji policy for cbs. +* MerlinTHP_ + * MerlinTHP_ Research lookaside cache authentication and upload + permissions +* **UNASSIGNED** + * (none) + + + + +People Present (lines said) +--------------------------- +* MerlinTHP_ (96) +* kbsingh (67) +* bstinson (34) +* alphacc (29) +* gwd (7) +* Evolution (7) +* Arrfab (5) +* centbot (4) +* lalatenduM (3) +* wolfy (1) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot diff --git a/static/minutes/2014/september/centos-devel.2014-09-22-13.02.html b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.html new file mode 100644 index 0000000..bd98d95 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.html @@ -0,0 +1,241 @@ + + + + +#centos-devel: cbs/infra + + + + +

#centos-devel: cbs/infra

+ +Meeting started by bstinson at 13:02:39 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. https://trello.com/b/CKGGvcKU/cbs-centos-org + is the url to the board (kbsingh, + 13:02:50)
      2. +
    +
    2. +
  2. Greetings / Who's Here? (bstinson, 13:03:03) +
    3. +
  3. Agenda (bstinson, 13:04:21) +
      +
    1. FAS/IPA Testing - Short Status Update + (bstinson, + 13:04:24)
      2. +
    2. Centpkg Progress - Short Status Update + (bstinson, + 13:04:28)
      3. +
    3. Blocker List (bstinson, + 13:04:32)
      4. +
    4. Brainstorming SIG Branch and Build Target + Names (bstinson, + 13:04:35)
      5. +
    5. Open Floor (bstinson, + 13:04:41)
      6. +
    +
    4. +
  4. FAS/IPA Testing (bstinson, 13:05:28) +
      +
    1. Infra team provisioned three VMs last week to + use for FAS & IPA testing (quaid, + 13:06:27)
      2. +
    2. can use the mailing list discussion to get + requirements (quaid, + 13:10:06)
      3. +
    3. ACTION: quaid can + write-up the requirements in to a wiki page to reference + (quaid, + 13:10:39)
      4. +
    4. IDEA: should we have a + second koji for ease of SSL testing, etc.? (quaid, + 13:13:31)
      5. +
    5. dev.git.centos.org can be used for testing git + connection (quaid, + 13:18:38)
      6. +
    +
    5. +
  5. Centpkg Progress (bstinson, 13:20:00) +
      +
    1. centpkg is reading in user certs and is able to + kick off koji builds (quaid, + 13:21:16)
      2. +
    2. IDEA: put git branch to + koji target in a config file instead of being hard-coded + (quaid, + 13:21:53)
      3. +
    3. ACTION: bstinson will + clean up his commits and send centpkg patches to the mailing + list (bstinson, + 13:25:15)
      4. +
    4. http://copr.fedoraproject.org/coprs/bstinson/Centpkg/ + (bstinson, + 13:27:13)
      5. +
    5. IDEA: have centpkg + eventually live in e.g. CentOS Extras (quaid, + 13:27:33)
      6. +
    6. not currently relying upon EPEL directly, + anything needed gets pulled in to local build, e.g. rpkg + (quaid, + 13:29:59)
      7. +
    +
    6. +
  6. Blocker List (bstinson, 13:31:44) +
      +
    1. integrate upstream patch in koji to support + git.c.o (alphacc, + 13:32:23)
      2. +
    2. ACTION: Build CentOS + koji rpms and install them (server-side). (alphacc, + 13:35:52)
      3. +
    3. AGREED: Project will + carry own koji RPMs to carry our own patches etc. (quaid, + 13:39:28)
      4. +
    4. can't use sshkeys for auth for git, needs to go + over https for code pathway (quaid, + 13:47:27)
      5. +
    5. https://git.centos.org/summary/centpkg.git + (kbsingh, + 13:54:07)
      6. +
    6. need to settle on temp auth method for + git.centos.org over https (quaid, + 14:03:27)
      7. +
    7. Next Meeting: Monday 29-Sept, 13:00 UTC + (bstinson, + 14:06:19)
      8. +
    +
    7. +
+

+ + + + +Meeting ended at 14:06:55 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. quaid can write-up the requirements in to a wiki page to reference
    2. +
  2. bstinson will clean up his commits and send centpkg patches to the mailing list
    3. +
  3. Build CentOS koji rpms and install them (server-side).
    4. +
+

+ + + +

Action items, by person

+
    +
  1. bstinson
      +
    1. bstinson will clean up his commits and send centpkg patches to the mailing list
      2. +
    2. +
  2. quaid
      +
    1. quaid can write-up the requirements in to a wiki page to reference
      2. +
    3. +
+

+ + + +

People present (lines said)

+
    +
  1. kbsingh (55)
    2. +
  2. MerlinTHP (48)
    3. +
  3. bstinson (46)
    4. +
  4. quaid (33)
    5. +
  5. alphacc (19)
    6. +
  6. Evolution (9)
    7. +
  7. centbot (5)
    8. +
  8. gwd (3)
    9. +
  9. mattymo (3)
    10. +
  10. Arrfab (3)
    11. +
  11. mikem (3)
    12. +
  12. wolfy (1)
    13. +
  13. jitseklomp (1)
    14. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.html b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.html new file mode 100644 index 0000000..1ce975f --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.html @@ -0,0 +1,256 @@ + + + + +#centos-devel log + + + + +
13:02:39 <bstinson> #startmeeting cbs/infra
+13:02:39 <centbot> Meeting started Mon Sep 22 13:02:39 2014 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
+13:02:39 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+13:02:42 <kbsingh> ok, check if you can get to the trello board - both you and alphacc are added there.
+13:02:50 <kbsingh> https://trello.com/b/CKGGvcKU/cbs-centos-org is the url to the board
+13:03:03 <bstinson> #topic Greetings / Who's Here?
+13:03:03 <alphacc> kbsingh: works for me
+13:03:07 <bstinson> looks like i'm in
+13:03:09 <MerlinTHP> Hello!
+13:03:09 * quaid is here
+13:03:14 <kbsingh> I'm here as well
+13:03:21 * Arrfab echoes "me too"
+13:03:44 <bstinson> #chair kbsingh quaid alphacc MerlinTHP Arrfab Evolution
+13:03:44 <centbot> Current chairs: Arrfab Evolution MerlinTHP alphacc bstinson kbsingh quaid
+13:03:54 * wolfy lurks
+13:04:21 <bstinson> #topic Agenda
+13:04:24 <bstinson> #info FAS/IPA Testing - Short Status Update
+13:04:28 <bstinson> #info Centpkg Progress - Short Status Update
+13:04:32 <bstinson> #info Blocker List
+13:04:35 <bstinson> #info Brainstorming SIG Branch and Build Target Names
+13:04:41 <bstinson> #info Open Floor
+13:05:00 <mikem> good morning
+13:05:09 <jitseklomp> Hi
+13:05:19 <bstinson> hi folks!
+13:05:28 <bstinson> #topic FAS/IPA Testing
+13:05:47 <MerlinTHP> FAS folks first ;)
+13:06:20 <bstinson> It sounds like Arrfab has started on some VMs for this project
+13:06:27 * MerlinTHP nods
+13:06:27 <quaid> #info Infra team provisioned three VMs last week to use for FAS & IPA testing
+13:06:39 <MerlinTHP> I've got access to the VM for IPA testing
+13:06:43 <Arrfab> bstinson: yes and quaid got account/sudo on those VMs
+13:07:02 <quaid> Arrfab: is one of them the one MerlinTHP has
+13:07:02 <quaid> ?
+13:07:18 <kbsingh> no, MerlinTHP's setup is in rackspace
+13:07:18 <Arrfab> quaid: no, a different one, running c7 for his IPA test
+13:07:35 <quaid> great
+13:08:08 <bstinson> great! is there anything the testing teams need going forward?
+13:08:17 <quaid> we need then a bit of requirements of what to test for
+13:09:04 <kbsingh> quaid: does the centos-devel thread give you all you need for scope ?
+13:09:10 <MerlinTHP> Evolution listed a few requirements on the mailing list for what we need the account system to do (self-service account creation, self-management for SIGs, etc).  IPA is missing a bunch of that stuff.
+13:09:21 <quaid> and just to interact with anyone who can help with tie-in to Koji
+13:09:34 <MerlinTHP> However, I've started writing a PoC web front end for IPA to do self-service.
+13:09:51 <quaid> kbsingh: I think so, can easily work up a wiki page on that
+13:09:58 <MerlinTHP> ( thus far users can sign up their own accounts )
+13:10:06 <quaid> #info can use the mailing list discussion to get requirements
+13:10:39 <quaid> #action quaid can write-up the requirements in to a wiki page to reference
+13:10:54 <alphacc> quaid: contact me if you need info on koji during your tests.
+13:11:35 <quaid> MerlinTHP: that's great! do you have the contacts you need with FreeIPA folks for that front end work?
+13:11:41 <Evolution> I'm assuming both ipa or fas would require a rekey of koji to test the ssl bits.
+13:11:53 <alphacc> Evolution: correct
+13:11:54 <quaid> alphacc: thanks
+13:11:55 <Evolution> would a second koji instance simply for ssl testing be in order?
+13:11:58 <MerlinTHP> Evolution: IPA would, certainly.
+13:12:13 <MerlinTHP> quaid: yeah, I already hang out in #freeipa ;)
+13:12:17 <Evolution> (once we get to that stage)
+13:12:42 <MerlinTHP> I'm planning to have the test IPA instance up with the front-end to poke at a bit later this week
+13:12:44 <quaid> Evolution: might be easier than messing with the running instance
+13:13:17 <quaid> similarly, I plan to have the basic FAS in place, and will rely upon smooge to help me get it further for actual testing
+13:13:31 <quaid> #idea should we have a second koji for ease of SSL testing, etc.?
+13:14:10 <kbsingh> there is a git.dev.centos.org that is already online - for testing scope on that side
+13:15:01 <bstinson> fantastic! it sounds like we're making progress
+13:15:10 <quaid> #ingo git.dev.centos.org can be used for testing git connection
+13:15:18 <quaid> #info git.dev.centos.org can be used for testing git connection
+13:15:21 <MerlinTHP> :)
+13:15:45 <quaid> that's all I've got right now, I think
+13:16:04 <kbsingh> dev.git.centos.org :)
+13:16:32 <MerlinTHP> In the course of doing research for the lookaside upload script, I've come to the conclusion that it'd help if the CA had an OCSP responder, and the host running the upload script was running apache 2.4 (so c7)
+13:17:06 <MerlinTHP> apache supports CRLs for certificate revocation, but you need to restart it every time you change the CRL file
+13:17:20 <kbsingh> we can run either c7 or c6 on the lookaside machine..
+13:17:53 <MerlinTHP> Whereas apache 2.4's OCSP support means it always goes ask the CA, so certificate revocations are instantly live.
+13:18:14 <MerlinTHP> Just a thought.
+13:18:18 <quaid> .undo
+13:18:27 <quaid> #info dev.git.centos.org can be used for testing git connection
+13:18:31 <quaid> #undo
+13:18:31 <centbot> Removing item from minutes: INFO by quaid at 13:18:27 : dev.git.centos.org can be used for testing git connection
+13:18:32 <quaid> #undo
+13:18:32 <centbot> Removing item from minutes: INFO by quaid at 13:15:18 : git.dev.centos.org can be used for testing git connection
+13:18:38 <quaid> #info dev.git.centos.org can be used for testing git connection
+13:19:11 <bstinson> ok, anything else before I move along?
+13:19:16 <MerlinTHP> Nothing from me
+13:19:29 <bstinson> thanks for researching the lookaside MerlinTHP
+13:19:39 <MerlinTHP> np
+13:19:50 <MerlinTHP> tbh, I spent more time on the IPA stuff...
+13:20:00 <bstinson> #topic Centpkg Progress
+13:20:38 <bstinson> ok this will be very short, I have Centpkg reading in user certs and i've been able to kick off koji builds
+13:20:45 <MerlinTHP> \o/
+13:20:52 <MerlinTHP> Oh, one thought
+13:21:06 <MerlinTHP> Currently, git branch to koji target is hard-coded
+13:21:16 <quaid> #info centpkg is reading in user certs and is able to kick off koji builds
+13:21:16 <MerlinTHP> I've thought for a while that it probably should be a config file
+13:21:17 <bstinson> i need to see if we can make it easer for centpkg to co-exist with fedpkg and its cousins
+13:21:38 <MerlinTHP> Does that sound like a sensible idea?
+13:21:40 <kbsingh> bstinson: can it pull from and do some level of mangling of git.centos.org hosted repos
+13:21:47 <MerlinTHP> I can work with you on it, bstinson
+13:21:53 <quaid> #idea put git branch to koji target in a config file instead of being hard-coded
+13:22:05 <kbsingh> MerlinTHP: we likely need a wider convo on git branch naming, i believe its in the schedule for later in the meeting
+13:22:25 <bstinson> kbsingh: yes it can pull (and push when we work out cert auth)
+13:22:33 <MerlinTHP> This is a bit orthagonal to that, imo
+13:22:40 <Evolution> so long as we can tie koji naming into that as well.. (bananas?)
+13:23:23 <bstinson> MerlinTHP: let's get together soon to talk about what you're thinking
+13:23:32 <MerlinTHP> Sure thing
+13:23:32 <kbsingh> what people can commit to - is tied into the targets they can consume in koji, but they should be able to ready from anywhere and build to the places they have acls to
+13:23:56 <kbsingh> tagging might have a role to play in here as well
+13:24:10 <alphacc> for semantic build=tag. policy work on tagging operation.
+13:25:08 <kbsingh> ok
+13:25:15 <bstinson> #action bstinson will clean up his commits and send centpkg patches to the mailing list
+13:25:31 <kbsingh> are we going to put this into a rpm ?
+13:25:37 <alphacc> I investigated the policy side and the easiest way now is to have a flat file and generate a policy. sig:user1,user2 and sig-admins:user1,user2
+13:25:58 <bstinson> kbsingh: i have a copr out there right now
+13:26:13 <kbsingh> we should have a more official process for this
+13:26:17 <kbsingh> maybe into centos-extras
+13:26:32 <kbsingh> but ok, lets do that as a second iteration
+13:26:54 <quaid> bstinson: what's the copr URL? (for the record)
+13:27:13 <bstinson> http://copr.fedoraproject.org/coprs/bstinson/Centpkg/
+13:27:33 <quaid> #idea have centpkg eventually live in e.g. CentOS Extras
+13:27:56 <MerlinTHP> That sounds sensible.
+13:28:11 <MerlinTHP> We'll have to decide where rpkg lives, though.
+13:28:17 <kbsingh> same place
+13:28:26 <MerlinTHP> rpkg is in EPEL, though
+13:28:32 <kbsingh> thats ok, were not relying on epel for now
+13:28:38 <MerlinTHP> ( that's just a note, not an objection )
+13:28:43 * MerlinTHP nods
+13:28:45 <MerlinTHP> Fair enough
+13:29:02 <kbsingh> anything in epel that we need - for now , we pull into local builds - longer term this is going to need a whole lot of conversation and attention :)
+13:29:09 <MerlinTHP> Mm
+13:29:54 <MerlinTHP> OK, centpkg looks to be cracking on
+13:29:59 <quaid> #info not currently relying upon EPEL directly, anything needed gets pulled in to local build, e.g. rpkg
+13:30:20 <Evolution> our interactions with epel will need to be a separate mailing list discussion or meeting here.
+13:30:31 <Evolution> that needs to happen semi-soon anyway to start getting expectations
+13:30:41 <Evolution> but I don't want to hijack this meeting for that
+13:31:00 <kbsingh> yeah
+13:31:14 * MerlinTHP pushes Evolution back down into his box
+13:31:42 <bstinson> ok, let's keep moving
+13:31:44 <bstinson> #topic Blocker List
+13:32:23 <alphacc> #info integrate upstream patch in koji to support git.c.o
+13:32:50 <kbsingh> ok, so what is the blocker list.. maybe we should first define what it is that is being blocked
+13:32:56 <alphacc> I have the RPMs ready.
+13:33:18 <alphacc> I will rebuild them in koji, and push it to infrastrcuture6 tag.
+13:33:32 <kbsingh> ok, so thats about 50% of the blocker problem fixed right ? if people can use centpkg to request builds from git.centos.org delivered into a target at cbs.centos.org
+13:33:53 <kbsingh> bstinson: once alphacc does his piece of work would that be possible ?
+13:35:36 <bstinson> should be
+13:35:52 <alphacc> #action Build CentOS koji rpms and install them (server-side).
+13:36:21 <bstinson> right now, i've just been kicking off builds using --srpm which creates an intermediate src rpm and uploads it for building
+13:37:08 <bstinson> alphacc: does the patch need any extra voices on the mailing lists?
+13:37:58 <alphacc> bstinson: I think we decided that we will have our own koji rpms, so no, just more testing.
+13:38:30 <bstinson> ok great
+13:39:10 <kbsingh> its been upstreamed as well right ? just not in a release
+13:39:21 <kbsingh> if they reject the patch upstream then we've got something to think about
+13:39:28 <quaid> #agreed Project will carry own koji RPMs to carry our own patches etc.
+13:39:51 <alphacc> mikem proposed the patch, but I don't think it is in master yet.
+13:40:39 <mikem> alphacc, which patch was that?
+13:41:32 <alphacc> mikem: koji-rpm-source-layout
+13:41:33 <mikem> "Support rpm source layout (SPECS and SOURCES dirs) when building srpms from source control."?  That's in upstream git
+13:42:07 <alphacc> ok great I missed it.
+13:42:56 <bstinson> ok, is anyone else have a component blocked on something?
+13:42:59 <kbsingh> so thats a good sign that were ok to carry it
+13:43:11 <bstinson> s/is/does/
+13:43:14 <kbsingh> the second half of the issue is auth into git.centos.org
+13:43:37 <kbsingh> i can import content in, and give people access based in login names, but its going to be https http_basic auth
+13:43:44 <kbsingh> works now, works for a few people, wont scale
+13:44:03 <kbsingh> and how much of a problem might we be creating for ipa folks to import this into their setup later ?
+13:44:55 <Evolution> kbsingh: bringing existing users over, or doing http auth?
+13:45:01 <alphacc> kbsingh: the forseen solution would be ssh-keys ?
+13:45:51 <MerlinTHP> If we go the IPA route, it'll just be a matter of converting ACLs into group memberships (or another LDAP attribute, if we go a more customised route for IPA)
+13:46:03 <kbsingh> Evolution: either/neither - i presume this will be just using CA keys, shared with koji longer term
+13:46:30 * quaid doesn't know yet of any hassles moving to FAS from http auth
+13:46:35 <kbsingh> alphacc: cant do sshkeys, the commits need to be over https to use the user<->branch mapping, since the commit needs to be 'intercepted' by code that can make that decision easily
+13:47:16 <bstinson> kbsingh: is that live on dev.git.c.o?
+13:47:27 <quaid> #info can't use sshkeys for auth for git, needs to go over https for code pathway
+13:47:44 <kbsingh> we could likely write something that does some sanity testing and checks keyname and works out group name and then looks at branch name etc, but the problem with that is still that folks can push at once - multiple branches
+13:48:06 <kbsingh> bstinson: it can be fairly easily.
+13:48:40 <kbsingh> bstinson: its live at git.centos.org
+13:48:45 <bstinson> i'd like to poke at it from the client side whenever it's ready
+13:48:59 <kbsingh> the user -> branch mapping ?
+13:49:28 <bstinson> the auth component
+13:50:20 <kbsingh> ok, i dont get what you want to poke at
+13:50:45 <kbsingh> the only way to commit to git.centos.org is over https, unless its the upstream buildservices, that can use a privileged path
+13:51:56 <bstinson> right, rpkg does all the committing over ssh so centpkg will need a few tweaks
+13:52:46 <kbsingh> ok
+13:53:01 <kbsingh> technically it should just be a case of using a different git remote url
+13:53:44 <kbsingh> iirc, there is a centpkg.git in git.centos.org's root git's
+13:53:47 <MerlinTHP> I suspect it'd work just by changing the git URL in the config file
+13:53:50 <kbsingh> isnt that how this works as well
+13:54:07 <kbsingh> https://git.centos.org/summary/centpkg.git
+13:54:56 <kbsingh> just going over this again to make sure i understand what piece of work you want me to deliver on
+13:56:10 <mattymo> hey Evolution
+13:56:37 <bstinson> when you say http_basic auth, are you meaning username/password?
+13:56:42 <kbsingh> yeah
+13:56:48 <Evolution> mattymo: meeting presently. wait one (or pm)
+13:56:54 <mattymo> oh ok
+13:57:32 <mattymo> I'll write here just b/c anyone can comment. I see this bug here: https://github.com/karelzak/util-linux/issues/121
+13:57:32 <bstinson> ah, we may need to hash out some details on that, I was hoping to hand you a client cert and get the user account info that way
+13:57:45 <kbsingh> bstinson: my understanding is that this will go away and fas or ipa will provide the certauthority to auth with
+13:58:13 <MerlinTHP> Mm
+13:58:57 <kbsingh> so the user will actually only have the one set of certs they use for koji and git
+13:59:10 <MerlinTHP> Yeah
+13:59:24 <MerlinTHP> ( + the lookaside, depending if you count that as part of git )
+13:59:37 <kbsingh> and somewhere in there will be a mechanism that says what branches ( or what groups ) this person belongs to
+13:59:50 <kbsingh> MerlinTHP: right, lookaside too
+14:00:12 <MerlinTHP> That mechanism could e.g. be an LDAP query against IPA
+14:00:55 <alphacc> MerlinTHP: I could query same ldap for the koji policy
+14:01:05 <MerlinTHP> That'd be neat
+14:01:16 <MerlinTHP> But you can probably s/IPA/FAS/ too
+14:01:51 * MerlinTHP wonders if we need to make this meeting slot longer
+14:02:03 <gwd> Sorry to interrupt -- could someone with koji admin privileges make a virt6-testing tag?  (I think that's what I want...)
+14:02:30 <bstinson> we are making good progress, at some point they'll get shorter :)
+14:02:34 <MerlinTHP> :)
+14:02:41 <alphacc> gwd: already there. pm.
+14:02:49 <MerlinTHP> I've got to go shortly
+14:02:55 <bstinson> since we're in the weeds, let's bring this back up offline and again next week
+14:03:08 <kbsingh> sounds good
+14:03:19 <kbsingh> i think the integration layers might be what needs the most effort
+14:03:26 <MerlinTHP> Agreed.
+14:03:27 <quaid> #info need to settle on temp auth method for git.centos.org over https
+14:03:40 <kbsingh> if we can offload auth for lookaside into httpd, we might do the same for git as well, but lets cross that bridge
+14:03:57 <alphacc> ok good for me too.
+14:04:19 <gwd> alphacc: Oops, sorry... missed the 2nd page on the web interface.
+14:05:01 <alphacc> gwd: it's a tag not a target, what are you yting to achieve ?
+14:05:16 <alphacc> s/yting/trying
+14:05:20 <bstinson> we can probably save SIG Branch and Build Target naming until next week also
+14:05:21 <kbsingh> cool, are we closing meeting ?
+14:05:41 <bstinson> closing in 1 minute
+14:05:44 <kbsingh> mattymo: still waiting for you guys to actually start doing some contributing and things into CentOS
+14:06:19 <bstinson> #info Next Meeting: Monday 29-Sept, 13:00 UTC
+14:06:35 <bstinson> thanks everyone!
+14:06:40 <MerlinTHP> Cheers!
+14:06:41 <gwd> alphacc: I'm trying to build ipxe into an actual repo, so that I can then try building xen (which depends on ipxe).
+14:06:50 <quaid> nice meeting, thx
+14:06:55 <bstinson> #endmeeting
+ diff --git a/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.txt b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.txt new file mode 100644 index 0000000..10dad11 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.log.txt @@ -0,0 +1,229 @@ +13:02:39 #startmeeting cbs/infra +13:02:39 Meeting started Mon Sep 22 13:02:39 2014 UTC. The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot. +13:02:39 Useful Commands: #action #agreed #help #info #idea #link #topic. +13:02:42 ok, check if you can get to the trello board - both you and alphacc are added there. +13:02:50 https://trello.com/b/CKGGvcKU/cbs-centos-org is the url to the board +13:03:03 #topic Greetings / Who's Here? +13:03:03 kbsingh: works for me +13:03:07 looks like i'm in +13:03:09 Hello! +13:03:09 * quaid is here +13:03:14 I'm here as well +13:03:21 * Arrfab echoes "me too" +13:03:44 #chair kbsingh quaid alphacc MerlinTHP Arrfab Evolution +13:03:44 Current chairs: Arrfab Evolution MerlinTHP alphacc bstinson kbsingh quaid +13:03:54 * wolfy lurks +13:04:21 #topic Agenda +13:04:24 #info FAS/IPA Testing - Short Status Update +13:04:28 #info Centpkg Progress - Short Status Update +13:04:32 #info Blocker List +13:04:35 #info Brainstorming SIG Branch and Build Target Names +13:04:41 #info Open Floor +13:05:00 good morning +13:05:09 Hi +13:05:19 hi folks! +13:05:28 #topic FAS/IPA Testing +13:05:47 FAS folks first ;) +13:06:20 It sounds like Arrfab has started on some VMs for this project +13:06:27 * MerlinTHP nods +13:06:27 #info Infra team provisioned three VMs last week to use for FAS & IPA testing +13:06:39 I've got access to the VM for IPA testing +13:06:43 bstinson: yes and quaid got account/sudo on those VMs +13:07:02 Arrfab: is one of them the one MerlinTHP has +13:07:02 ? +13:07:18 no, MerlinTHP's setup is in rackspace +13:07:18 quaid: no, a different one, running c7 for his IPA test +13:07:35 great +13:08:08 great! is there anything the testing teams need going forward? +13:08:17 we need then a bit of requirements of what to test for +13:09:04 quaid: does the centos-devel thread give you all you need for scope ? +13:09:10 Evolution listed a few requirements on the mailing list for what we need the account system to do (self-service account creation, self-management for SIGs, etc). IPA is missing a bunch of that stuff. +13:09:21 and just to interact with anyone who can help with tie-in to Koji +13:09:34 However, I've started writing a PoC web front end for IPA to do self-service. +13:09:51 kbsingh: I think so, can easily work up a wiki page on that +13:09:58 ( thus far users can sign up their own accounts ) +13:10:06 #info can use the mailing list discussion to get requirements +13:10:39 #action quaid can write-up the requirements in to a wiki page to reference +13:10:54 quaid: contact me if you need info on koji during your tests. +13:11:35 MerlinTHP: that's great! do you have the contacts you need with FreeIPA folks for that front end work? +13:11:41 I'm assuming both ipa or fas would require a rekey of koji to test the ssl bits. +13:11:53 Evolution: correct +13:11:54 alphacc: thanks +13:11:55 would a second koji instance simply for ssl testing be in order? +13:11:58 Evolution: IPA would, certainly. +13:12:13 quaid: yeah, I already hang out in #freeipa ;) +13:12:17 (once we get to that stage) +13:12:42 I'm planning to have the test IPA instance up with the front-end to poke at a bit later this week +13:12:44 Evolution: might be easier than messing with the running instance +13:13:17 similarly, I plan to have the basic FAS in place, and will rely upon smooge to help me get it further for actual testing +13:13:31 #idea should we have a second koji for ease of SSL testing, etc.? +13:14:10 there is a git.dev.centos.org that is already online - for testing scope on that side +13:15:01 fantastic! it sounds like we're making progress +13:15:10 #ingo git.dev.centos.org can be used for testing git connection +13:15:18 #info git.dev.centos.org can be used for testing git connection +13:15:21 :) +13:15:45 that's all I've got right now, I think +13:16:04 dev.git.centos.org :) +13:16:32 In the course of doing research for the lookaside upload script, I've come to the conclusion that it'd help if the CA had an OCSP responder, and the host running the upload script was running apache 2.4 (so c7) +13:17:06 apache supports CRLs for certificate revocation, but you need to restart it every time you change the CRL file +13:17:20 we can run either c7 or c6 on the lookaside machine.. +13:17:53 Whereas apache 2.4's OCSP support means it always goes ask the CA, so certificate revocations are instantly live. +13:18:14 Just a thought. +13:18:18 .undo +13:18:27 #info dev.git.centos.org can be used for testing git connection +13:18:31 #undo +13:18:31 Removing item from minutes: INFO by quaid at 13:18:27 : dev.git.centos.org can be used for testing git connection +13:18:32 #undo +13:18:32 Removing item from minutes: INFO by quaid at 13:15:18 : git.dev.centos.org can be used for testing git connection +13:18:38 #info dev.git.centos.org can be used for testing git connection +13:19:11 ok, anything else before I move along? +13:19:16 Nothing from me +13:19:29 thanks for researching the lookaside MerlinTHP +13:19:39 np +13:19:50 tbh, I spent more time on the IPA stuff... +13:20:00 #topic Centpkg Progress +13:20:38 ok this will be very short, I have Centpkg reading in user certs and i've been able to kick off koji builds +13:20:45 \o/ +13:20:52 Oh, one thought +13:21:06 Currently, git branch to koji target is hard-coded +13:21:16 #info centpkg is reading in user certs and is able to kick off koji builds +13:21:16 I've thought for a while that it probably should be a config file +13:21:17 i need to see if we can make it easer for centpkg to co-exist with fedpkg and its cousins +13:21:38 Does that sound like a sensible idea? +13:21:40 bstinson: can it pull from and do some level of mangling of git.centos.org hosted repos +13:21:47 I can work with you on it, bstinson +13:21:53 #idea put git branch to koji target in a config file instead of being hard-coded +13:22:05 MerlinTHP: we likely need a wider convo on git branch naming, i believe its in the schedule for later in the meeting +13:22:25 kbsingh: yes it can pull (and push when we work out cert auth) +13:22:33 This is a bit orthagonal to that, imo +13:22:40 so long as we can tie koji naming into that as well.. (bananas?) +13:23:23 MerlinTHP: let's get together soon to talk about what you're thinking +13:23:32 Sure thing +13:23:32 what people can commit to - is tied into the targets they can consume in koji, but they should be able to ready from anywhere and build to the places they have acls to +13:23:56 tagging might have a role to play in here as well +13:24:10 for semantic build=tag. policy work on tagging operation. +13:25:08 ok +13:25:15 #action bstinson will clean up his commits and send centpkg patches to the mailing list +13:25:31 are we going to put this into a rpm ? +13:25:37 I investigated the policy side and the easiest way now is to have a flat file and generate a policy. sig:user1,user2 and sig-admins:user1,user2 +13:25:58 kbsingh: i have a copr out there right now +13:26:13 we should have a more official process for this +13:26:17 maybe into centos-extras +13:26:32 but ok, lets do that as a second iteration +13:26:54 bstinson: what's the copr URL? (for the record) +13:27:13 http://copr.fedoraproject.org/coprs/bstinson/Centpkg/ +13:27:33 #idea have centpkg eventually live in e.g. CentOS Extras +13:27:56 That sounds sensible. +13:28:11 We'll have to decide where rpkg lives, though. +13:28:17 same place +13:28:26 rpkg is in EPEL, though +13:28:32 thats ok, were not relying on epel for now +13:28:38 ( that's just a note, not an objection ) +13:28:43 * MerlinTHP nods +13:28:45 Fair enough +13:29:02 anything in epel that we need - for now , we pull into local builds - longer term this is going to need a whole lot of conversation and attention :) +13:29:09 Mm +13:29:54 OK, centpkg looks to be cracking on +13:29:59 #info not currently relying upon EPEL directly, anything needed gets pulled in to local build, e.g. rpkg +13:30:20 our interactions with epel will need to be a separate mailing list discussion or meeting here. +13:30:31 that needs to happen semi-soon anyway to start getting expectations +13:30:41 but I don't want to hijack this meeting for that +13:31:00 yeah +13:31:14 * MerlinTHP pushes Evolution back down into his box +13:31:42 ok, let's keep moving +13:31:44 #topic Blocker List +13:32:23 #info integrate upstream patch in koji to support git.c.o +13:32:50 ok, so what is the blocker list.. maybe we should first define what it is that is being blocked +13:32:56 I have the RPMs ready. +13:33:18 I will rebuild them in koji, and push it to infrastrcuture6 tag. +13:33:32 ok, so thats about 50% of the blocker problem fixed right ? if people can use centpkg to request builds from git.centos.org delivered into a target at cbs.centos.org +13:33:53 bstinson: once alphacc does his piece of work would that be possible ? +13:35:36 should be +13:35:52 #action Build CentOS koji rpms and install them (server-side). +13:36:21 right now, i've just been kicking off builds using --srpm which creates an intermediate src rpm and uploads it for building +13:37:08 alphacc: does the patch need any extra voices on the mailing lists? +13:37:58 bstinson: I think we decided that we will have our own koji rpms, so no, just more testing. +13:38:30 ok great +13:39:10 its been upstreamed as well right ? just not in a release +13:39:21 if they reject the patch upstream then we've got something to think about +13:39:28 #agreed Project will carry own koji RPMs to carry our own patches etc. +13:39:51 mikem proposed the patch, but I don't think it is in master yet. +13:40:39 alphacc, which patch was that? +13:41:32 mikem: koji-rpm-source-layout +13:41:33 "Support rpm source layout (SPECS and SOURCES dirs) when building srpms from source control."? That's in upstream git +13:42:07 ok great I missed it. +13:42:56 ok, is anyone else have a component blocked on something? +13:42:59 so thats a good sign that were ok to carry it +13:43:11 s/is/does/ +13:43:14 the second half of the issue is auth into git.centos.org +13:43:37 i can import content in, and give people access based in login names, but its going to be https http_basic auth +13:43:44 works now, works for a few people, wont scale +13:44:03 and how much of a problem might we be creating for ipa folks to import this into their setup later ? +13:44:55 kbsingh: bringing existing users over, or doing http auth? +13:45:01 kbsingh: the forseen solution would be ssh-keys ? +13:45:51 If we go the IPA route, it'll just be a matter of converting ACLs into group memberships (or another LDAP attribute, if we go a more customised route for IPA) +13:46:03 Evolution: either/neither - i presume this will be just using CA keys, shared with koji longer term +13:46:30 * quaid doesn't know yet of any hassles moving to FAS from http auth +13:46:35 alphacc: cant do sshkeys, the commits need to be over https to use the user<->branch mapping, since the commit needs to be 'intercepted' by code that can make that decision easily +13:47:16 kbsingh: is that live on dev.git.c.o? +13:47:27 #info can't use sshkeys for auth for git, needs to go over https for code pathway +13:47:44 we could likely write something that does some sanity testing and checks keyname and works out group name and then looks at branch name etc, but the problem with that is still that folks can push at once - multiple branches +13:48:06 bstinson: it can be fairly easily. +13:48:40 bstinson: its live at git.centos.org +13:48:45 i'd like to poke at it from the client side whenever it's ready +13:48:59 the user -> branch mapping ? +13:49:28 the auth component +13:50:20 ok, i dont get what you want to poke at +13:50:45 the only way to commit to git.centos.org is over https, unless its the upstream buildservices, that can use a privileged path +13:51:56 right, rpkg does all the committing over ssh so centpkg will need a few tweaks +13:52:46 ok +13:53:01 technically it should just be a case of using a different git remote url +13:53:44 iirc, there is a centpkg.git in git.centos.org's root git's +13:53:47 I suspect it'd work just by changing the git URL in the config file +13:53:50 isnt that how this works as well +13:54:07 https://git.centos.org/summary/centpkg.git +13:54:56 just going over this again to make sure i understand what piece of work you want me to deliver on +13:56:10 hey Evolution +13:56:37 when you say http_basic auth, are you meaning username/password? +13:56:42 yeah +13:56:48 mattymo: meeting presently. wait one (or pm) +13:56:54 oh ok +13:57:32 I'll write here just b/c anyone can comment. I see this bug here: https://github.com/karelzak/util-linux/issues/121 +13:57:32 ah, we may need to hash out some details on that, I was hoping to hand you a client cert and get the user account info that way +13:57:45 bstinson: my understanding is that this will go away and fas or ipa will provide the certauthority to auth with +13:58:13 Mm +13:58:57 so the user will actually only have the one set of certs they use for koji and git +13:59:10 Yeah +13:59:24 ( + the lookaside, depending if you count that as part of git ) +13:59:37 and somewhere in there will be a mechanism that says what branches ( or what groups ) this person belongs to +13:59:50 MerlinTHP: right, lookaside too +14:00:12 That mechanism could e.g. be an LDAP query against IPA +14:00:55 MerlinTHP: I could query same ldap for the koji policy +14:01:05 That'd be neat +14:01:16 But you can probably s/IPA/FAS/ too +14:01:51 * MerlinTHP wonders if we need to make this meeting slot longer +14:02:03 Sorry to interrupt -- could someone with koji admin privileges make a virt6-testing tag? (I think that's what I want...) +14:02:30 we are making good progress, at some point they'll get shorter :) +14:02:34 :) +14:02:41 gwd: already there. pm. +14:02:49 I've got to go shortly +14:02:55 since we're in the weeds, let's bring this back up offline and again next week +14:03:08 sounds good +14:03:19 i think the integration layers might be what needs the most effort +14:03:26 Agreed. +14:03:27 #info need to settle on temp auth method for git.centos.org over https +14:03:40 if we can offload auth for lookaside into httpd, we might do the same for git as well, but lets cross that bridge +14:03:57 ok good for me too. +14:04:19 alphacc: Oops, sorry... missed the 2nd page on the web interface. +14:05:01 gwd: it's a tag not a target, what are you yting to achieve ? +14:05:16 s/yting/trying +14:05:20 we can probably save SIG Branch and Build Target naming until next week also +14:05:21 cool, are we closing meeting ? +14:05:41 closing in 1 minute +14:05:44 mattymo: still waiting for you guys to actually start doing some contributing and things into CentOS +14:06:19 #info Next Meeting: Monday 29-Sept, 13:00 UTC +14:06:35 thanks everyone! +14:06:40 Cheers! +14:06:41 alphacc: I'm trying to build ipxe into an actual repo, so that I can then try building xen (which depends on ipxe). +14:06:50 nice meeting, thx +14:06:55 #endmeeting \ No newline at end of file diff --git a/static/minutes/2014/september/centos-devel.2014-09-22-13.02.txt b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.txt new file mode 100644 index 0000000..233a540 --- /dev/null +++ b/static/minutes/2014/september/centos-devel.2014-09-22-13.02.txt @@ -0,0 +1,115 @@ +======================== +#centos-devel: cbs/infra +======================== + + +Meeting started by bstinson at 13:02:39 UTC. The full logs are available +at centos-devel/2014/centos-devel.2014-09-22-13.02.log.html . + + + +Meeting summary +--------------- +* LINK: https://trello.com/b/CKGGvcKU/cbs-centos-org is the url to the + board (kbsingh, 13:02:50) +* Greetings / Who's Here? (bstinson, 13:03:03) + +* Agenda (bstinson, 13:04:21) + * FAS/IPA Testing - Short Status Update (bstinson, 13:04:24) + * Centpkg Progress - Short Status Update (bstinson, 13:04:28) + * Blocker List (bstinson, 13:04:32) + * Brainstorming SIG Branch and Build Target Names (bstinson, + 13:04:35) + * Open Floor (bstinson, 13:04:41) + +* FAS/IPA Testing (bstinson, 13:05:28) + * Infra team provisioned three VMs last week to use for FAS & IPA + testing (quaid, 13:06:27) + * can use the mailing list discussion to get requirements (quaid, + 13:10:06) + * ACTION: quaid can write-up the requirements in to a wiki page to + reference (quaid, 13:10:39) + * IDEA: should we have a second koji for ease of SSL testing, etc.? + (quaid, 13:13:31) + * dev.git.centos.org can be used for testing git connection (quaid, + 13:18:38) + +* Centpkg Progress (bstinson, 13:20:00) + * centpkg is reading in user certs and is able to kick off koji builds + (quaid, 13:21:16) + * IDEA: put git branch to koji target in a config file instead of + being hard-coded (quaid, 13:21:53) + * ACTION: bstinson will clean up his commits and send centpkg patches + to the mailing list (bstinson, 13:25:15) + * LINK: http://copr.fedoraproject.org/coprs/bstinson/Centpkg/ + (bstinson, 13:27:13) + * IDEA: have centpkg eventually live in e.g. CentOS Extras (quaid, + 13:27:33) + * not currently relying upon EPEL directly, anything needed gets + pulled in to local build, e.g. rpkg (quaid, 13:29:59) + +* Blocker List (bstinson, 13:31:44) + * integrate upstream patch in koji to support git.c.o (alphacc, + 13:32:23) + * ACTION: Build CentOS koji rpms and install them (server-side). + (alphacc, 13:35:52) + * AGREED: Project will carry own koji RPMs to carry our own patches + etc. (quaid, 13:39:28) + * can't use sshkeys for auth for git, needs to go over https for code + pathway (quaid, 13:47:27) + * LINK: https://git.centos.org/summary/centpkg.git (kbsingh, + 13:54:07) + * need to settle on temp auth method for git.centos.org over https + (quaid, 14:03:27) + * Next Meeting: Monday 29-Sept, 13:00 UTC (bstinson, 14:06:19) + +Meeting ended at 14:06:55 UTC. + + + + +Action Items +------------ +* quaid can write-up the requirements in to a wiki page to reference +* bstinson will clean up his commits and send centpkg patches to the + mailing list +* Build CentOS koji rpms and install them (server-side). + + + + +Action Items, by person +----------------------- +* bstinson + * bstinson will clean up his commits and send centpkg patches to the + mailing list +* quaid + * quaid can write-up the requirements in to a wiki page to reference +* **UNASSIGNED** + * Build CentOS koji rpms and install them (server-side). + + + + +People Present (lines said) +--------------------------- +* kbsingh (55) +* MerlinTHP (48) +* bstinson (46) +* quaid (33) +* alphacc (19) +* Evolution (9) +* centbot (5) +* gwd (3) +* mattymo (3) +* Arrfab (3) +* mikem (3) +* wolfy (1) +* jitseklomp (1) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot