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