FAmNA Meeting (20 June 2012)
by inode0
======================
#fedora-meeting: FAmNA
======================
Meeting started by inode0 at 01:00:06 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-20/famna.2012-06-...
.
Meeting summary
---------------
* Roll Call (inode0, 01:00:22)
* Announcements (inode0, 01:01:45)
* Tickets (inode0, 01:06:11)
* #37 (Proposal for distributing Fedora swag outside of
conferences/events) – FAmNA general trac -
https://fedorahosted.org/famna/ticket/37 (inode0, 01:07:16)
* Proposal for distributing Fedora swag outside of conferences/events
(inode0, 01:07:30)
* #22 (Red Hat Summit / JBossWorld 2012, Jun 26-29, Boston, MA) –
FAmNA general trac - https://fedorahosted.org/famna/ticket/22
(inode0, 01:26:58)
* Red Hat Summit / JBossWorld 2012 (inode0, 01:27:14)
* LINK: https://fedoraproject.org/wiki/Red_Hat_Summit_2012
(graphite6, 01:28:51)
* Open Floor (inode0, 01:41:30)
* LINK: http://www.amazon.com/Cow-Head-Party-Hat-Adult/dp/B002PBLL32
(suehle, 01:49:04)
Meeting ended at 02:05:30 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* rbergeron (83)
* inode0 (56)
* ianweller (41)
* nb (33)
* suehle (31)
* graphite6 (21)
* award3535 (21)
* MarkDude (20)
* chanchito (12)
* kk4ewt (11)
* dan408 (8)
* zodbot (7)
* inode1 (4)
John
11 years, 10 months
- 1
- 0
Summary/Minutes from today's FESCo Meeting (2012-06-18)
by Kevin Fenzi
===================================
#fedora-meeting: FESCO (2012-06-18)
===================================
Meeting started by nirik at 17:00:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fesco.2012-06-...
.
Meeting summary
---------------
* init process (nirik, 17:00:01)
* ticket 861 - Cleanup of maintainers with bugzilla account (nirik,
17:03:15)
* AGREED: nirik will mail a list of affected maintainers to the devel
list asking for anyone to contact them. nirik will mail them
directly to their fas account again today. Then we wait and process
any that didn't fix things by july 2nd on july 2nd. (nirik,
17:17:19)
* ticket 857 F18 Feature: Initial Experience -
https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857
(nirik, 17:17:38)
* AGREED: Feature is approved. (+8/0) (nirik, 17:31:30)
* ticket 863 F18 Feature: Clojure -
https://fedoraproject.org/wiki/Features/Clojure (nirik, 17:31:40)
* AGREED: Feature is approved (+9/0) (nirik, 17:43:35)
* ticket 864 F18 Feature: DNF -
https://fedoraproject.org/wiki/Features/DNF (nirik, 17:44:17)
* AGREED: Feature is approved (+8/0) (nirik, 17:56:59)
* ticket 867 F18 Feature: Hawkey -
https://fedoraproject.org/wiki/Features/Hawkey (nirik, 17:57:07)
* AGREED: Feature is approved, please merge it with the DNF feature.
(nirik, 18:00:38)
* ticket 865 F18 Feature: DragonEgg -
https://fedoraproject.org/wiki/Features/DragonEgg (nirik, 18:00:53)
* AGREED: Feature is approved (+7/0) (nirik, 18:13:03)
* ticket 866 F18 Feature: Dwarf Compressor -
https://fedoraproject.org/wiki/Features/DwarfCompressor (nirik,
18:13:20)
* AGREED: Feature is approved (+9/0) (nirik, 18:21:28)
* ticket 868 F18 Feature: MiniDebugInfo -
https://fedoraproject.org/wiki/Features/MiniDebugInfo (nirik,
18:23:37)
* AGREED: Feature is approved. (+7/-1/0) (nirik, 18:26:57)
* ticket 869 F18 Feature: Offline Updates using systemd and packagekit -
https://fedoraproject.org/wiki/Features/OfflineSystemUpdates (nirik,
18:27:56)
* AGREED: Feature is approved (+6/-1/0) (nirik, 18:41:44)
* ticket 870 F18 Feature: SELinux Booleans Rename -
https://fedoraproject.org/wiki/Features/SELinuxBooleansRename (nirik,
18:41:59)
* AGREED: Feature is approved (+7/0) (nirik, 18:45:18)
* ticket 871 F18 Feature: SysV to systemd -
https://fedoraproject.org/wiki/Features/SysVtoSystemd (nirik,
18:45:30)
* AGREED: Feature is approved (+6/-1/0) (nirik, 18:52:43)
* ticket 872 F18 Feature: systemd unit cleanup and enhancement -
https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup (nirik,
18:52:52)
* AGREED: Feature is not approved at this time. (-7/0) (nirik,
19:04:36)
* Next week Chair (nirik, 19:05:33)
* mitr to chair 2012-06-25 meeting. (nirik, 19:06:36)
* Open Floor (nirik, 19:06:53)
Meeting ended at 19:09:38 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (164)
* mitr (69)
* limburgher (57)
* jwb (51)
* hughsie (44)
* mjg59 (42)
* t8m (40)
* pjones (39)
* mezcalero (34)
* notting (31)
* _jakub_ (31)
* hircus (27)
* zodbot (16)
* brouhaha (15)
* Viking-Ice (12)
* tibbs|w (7)
* abadger1999 (5)
* kushal (4)
* alexlarsson (4)
* gholms (3)
* cwickert (2)
* Rombobeorn (2)
* JSchmitt (1)
* drago01 (1)
* mmaslano (0)
--
17:00:00 <nirik> #startmeeting FESCO (2012-06-18)
17:00:00 <zodbot> Meeting started Mon Jun 18 17:00:00 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:01 <nirik> #meetingname fesco
17:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones jwb mitr limburgher
17:00:01 <nirik> #topic init process
17:00:01 <zodbot> The meeting name has been set to 'fesco'
17:00:01 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:00:06 <mjg59> Hi
17:00:14 <jwb> hello. i am present.
17:00:26 <pjones> hi.
17:00:53 * limburgher present
17:01:16 <mitr> Hello
17:01:45 * hughsie present, but unsure of whether to just jump in on stuff, or just reply to questions...
17:02:27 <nirik> hughsie: feel free to jump in, but if it's about your feature, wait until we get to that topic?
17:02:32 * kushal is also here
17:02:34 <t8m> hello
17:02:37 <hughsie> nirik, understood, thanks.
17:03:00 <nirik> ok, lets go ahead and get started, we have a lot of features today. ;)
17:03:15 <nirik> #topic ticket 861 - Cleanup of maintainers with bugzilla account
17:03:15 <nirik> .fesco 861
17:03:15 * notting is here now. sorry about that
17:03:18 <zodbot> nirik: #861 (Cleanup of maintainers with bugzilla account issues) – FESCo - https://fedorahosted.org/fesco/ticket/861
17:03:29 <nirik> so, there was some back and forth in the ticket over the weekend on this.
17:03:37 * hircus present
17:03:42 <nirik> I'm happy to wait longer to take any action (although I don't think it will matter).
17:04:02 <limburgher> What's the current packager/package list at this time?
17:04:09 <jwb> i don't think it will either, but it can't really hurt to wait i guess
17:04:11 <notting> mmcgrath? someone should hit him with a fish or something.
17:04:41 * nirik notes he's going on vacation starting thursday, so I could happily wait until after I get back
17:05:06 <limburgher> nirik: Seems rational.
17:05:08 <t8m> I agree that it won't hurt if we wait for a few days more
17:05:27 <t8m> nirik, will you use the regular orphan process?
17:05:43 <nirik> in the last run, there were 97 issues. Down from about 197 a few weeks ago.
17:05:46 <t8m> I mean the non-responsive maintainer process
17:06:23 <nirik> t8m: well, I can, but thats a bunch of overhead for this number of packages...
17:07:00 <nirik> many of these issues could well have been happening for a long long time.
17:07:01 <t8m> nirik, ok can it be followed at least partially to avoid the overhead
17:07:49 <limburgher> And you're emailing both the FAS email and BZ email for each user, correct?
17:07:50 <nirik> t8m: well, what would you suggest?
17:08:10 <nirik> the policy asks that I file a bug against each package.
17:08:18 <nirik> I can do that, but it seems a massive waste of time and energy.
17:08:20 <mitr> nirik: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainer...
17:08:24 <abadger1999> limburgher: How would we know what hte bz email for a user is?
17:08:32 <nirik> limburgher: no, because we have no idea what their bz email is.
17:08:47 <mitr> nirik: If I understand correctly, it's down to 7 maintainers, isn't it?
17:08:51 <notting> you can look it up in bz if you have admin privs for that table. that i don't have.
17:09:07 <notting> we could pester the bz maintainer to find that, but don't know if that's a good scalable process
17:09:18 <nirik> mitr: sure, but because of this script failing, they would Never in fact see the bug.
17:09:20 <limburgher> abadger1999, nirik: If there are open bugs against packages they own and they are assigned to them, it'll be there.
17:09:54 <abadger1999> notting: ahhh... you mean, look up the component and check the email addresses there to see if there's an address that could be the person in quesetion?
17:09:56 <nirik> limburgher: it could be. Or it could be some older maintainer thats not them
17:09:58 <limburgher> And if that's the case, those users are a bigger problem than the ones for which there are no open bugs. :)
17:10:10 * abadger1999 could probably do that as a one-off.
17:10:15 <limburgher> nirik: True.
17:10:17 <notting> abadger1999: no, i mean do a bz search of the accounts table for a name
17:10:18 <nirik> the problem here is that bugzilla is out of sync, so using bugzilla to report it seems... not ideal
17:10:38 <t8m> nirik, so I'd at least announce it on fedora-devel and give them a few more days to respond
17:10:43 <abadger1999> notting: k. that would be trickier.
17:10:59 <limburgher> nirik: True, but two bad addresses has a better chance of finding the person than one bad address.
17:11:26 <Rombobeorn> I think sending email to the FAS address can count as equivalent to filing bugs in Bugzilla when there isn't a specific problem with a package. I'm more interested in seeing a mail on the devel list so that anyone who might know other ways of contacting these packagers will notice.
17:11:29 <t8m> actually filling a bug against component they own would reveal the current address
17:12:11 <nirik> ok, how about this: proposal: nirik will mail a list of affected maintainers to the devel list asking for anyone to contact them. nirik will mail them directly to their fas account again today. Then we wait and process any that didn't fix things by july 2nd on july 2nd.
17:12:20 <limburgher> t8m: True. because it uses the real BZ address, not foo-owner(a)fp.org.
17:12:31 <brouhaha> Sounds similar to the "Fast Track procedure" for unresponsive maintainers.
17:12:36 <jwb> nirik, sounds excellent
17:12:46 <nirik> t8m: unless it was owned before by someone else, or that address no longer exists, or... ;)
17:13:27 <t8m> nirik, even for bugs newly filled?
17:13:50 <nirik> t8m: this script is the thing that sets that in bugzilla. :)
17:14:07 <t8m> nirik, ah ok
17:14:12 <nirik> so, user foo has address foo(a)bar.com in fas, it tries to set that in bugzilla so bugs filed against packages they own go to foo(a)bar.com.
17:14:23 <nirik> it's not working because there is no foo(a)bar.com bugzilla account.
17:14:26 <notting> nirik: sounds good. then again, i suspect we could find mmcgrath if we wanted to
17:14:43 <nirik> so, whats on the component could be anything... we don't know. Old maintainer, old address they used to have, etc.
17:14:47 <t8m> nirik, never mind, so +1 to the proposal
17:15:02 <nirik> notting: yeah, I can ping him.
17:15:06 * abadger1999 thinks mmcgrath might not own any packages in Fedora anymore
17:15:13 <nirik> abadger1999: he does. ;)
17:15:36 <nirik> the mission critical ytalk. ;)
17:16:13 <nirik> anyhow, votes? counter proposals?
17:16:30 <limburgher> +1 to proposal.
17:16:39 <mjg59> +1
17:16:43 <pjones> sure, +1
17:16:43 <mitr> +1
17:17:15 <jwb> i think i already said it sounds good
17:17:19 <nirik> #agreed nirik will mail a list of affected maintainers to the devel list asking for anyone to contact them. nirik will mail them directly to their fas account again today. Then we wait and process any that didn't fix things by july 2nd on july 2nd.
17:17:27 <nirik> ok, moving on unless there's anything else on this.
17:17:38 <nirik> #topic ticket 857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857
17:17:48 <nirik> .fesco 857
17:17:49 <zodbot> nirik: #857 (F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience) – FESCo - https://fedorahosted.org/fesco/ticket/857
17:17:51 <Rombobeorn> It's good to see that due process works in Fedora. :-)
17:18:14 <nirik> Rombobeorn: hopefully folks filing bugs against those components are understanding as well. ;)
17:18:33 <mitr> #857 probably demonstrates most things that could go wrong in the feature process :(
17:18:52 <jwb> i'm not sure why you say that
17:19:19 <mitr> The ticket was deferred two times to gather more information, and we still managed to discover more interested parties
17:19:41 <mitr> I have sent an email on friday, but it's probably stuck in moderation queues
17:19:45 <jwb> is trac throwing 500 errors for anyone else?
17:19:50 <mjg59> jwb: Yes
17:19:52 <brouhaha> jwb: yes
17:19:55 <nirik> jwb: something odd going on, being looked at.
17:19:57 <jwb> ok :\
17:20:04 <pjones> yep
17:20:20 <jwb> mitr, sounds like the process is working fine then
17:20:41 <jwb> responsible parties are making sure it doesn't get a rubber stamp without proper discussion, etc
17:21:22 <limburgher> my understanding was that at the current moment, we'd determined that this would not impact spins not using it, correct?
17:21:35 <nirik> limburgher: yes, thats my understanding. just desktop spin.
17:21:36 <t8m> limburgher, that's not sure
17:21:36 <mitr> jwb: AFAICT the anaconda interaction was discoverred pretty much by a random act of luck
17:21:53 <jwb> mitr, pretty sure notting has repeatedly said that wasn't the case
17:21:56 <mitr> limburgher: It collides with anaconda's plans for sharing dialogs between anaconda and firstboot, so, not sure
17:21:58 <limburgher> t8m: What is your understanding of the current overlap?
17:22:07 <limburgher> mitr: Ah.
17:22:10 <mjg59> If only we had an Anaconda developer on fesco
17:22:18 <nirik> so, where do we go here? try and get interested parties all talking and revisit?
17:22:20 <t8m> limburgher, what mitr said
17:22:29 * nirik notes trac should be back
17:23:21 <pjones> mjg59: ppphbbbt.
17:24:22 <nirik> so, the question is: will anaconda+firstboot integration be messed up by this feature being in the desktop spin? or ?
17:25:09 <limburgher> My understanding was that this feature simply skipped firstboot, wouldn't that mean that anaconda would still use firstboot dialogs if need be?
17:25:14 <mitr> nirik: I think the worst case is asking the user for the same things twice
17:25:55 <limburgher> mitr: Which isn't great. I'd think the spin could feed anaconda options that it knows this feature would handle. Couldn' it?
17:25:56 <limburgher> t
17:26:11 <pjones> limburgher: yeah, that should be right
17:26:11 <jwb> the desktop spin isn't _using_ anaconda
17:26:25 <limburgher> <blink>
17:26:27 <mjg59> I think having a conversation about code that we haven't read while arguing positions for people who aren't here is unhelpful
17:26:36 <pjones> jwb: uh, liveinst is still anaconda I'm pretty sure.
17:26:39 <nirik> jwb: ? how does it install?
17:26:51 <limburgher> So if it's only using this, and not firstboot or anaconda, then there should be no issue.
17:26:53 <jwb> pjones, i thought it was still just basically a DD of the live image to a hard drive?
17:27:01 <t8m> serious hailstorm here just now
17:27:03 <mjg59> jwb: Yes, but it's Anaconda that does the setup
17:27:07 <mitr> limburgher: Yes, as long as the relevant parties agree on a mechanism.
17:27:09 <limburgher> mjg59: No, but it's fun.
17:27:26 <jwb> mjg59, but does it go through all the same setup stuff as a DVD install?
17:27:29 <jwb> i should just go try it
17:27:32 <nirik> t8m: stay safe. :)
17:27:32 <mjg59> jwb: Yes
17:27:38 <jwb> well i'm being dumb then
17:27:56 <t8m> nirik, not dangerous but cars parking outside might be damaged
17:28:13 <nirik> so, how about we delegate some of our number to go talk to anaconda and firstboot and initialexperence folks (possibly in the same place/time) and report back?
17:28:17 <limburgher> t8m: It'd still advice a helmet.
17:28:20 <pjones> Anyway at this point it really doesn't sound like the anaconda interaction is something fesco needs to be directly concerned with
17:28:30 <mjg59> So how about we just +1 it with the obvious assumption that if it's not well integrated it doesn't reach 100%?
17:28:45 <pjones> nirik: I don't know why we even need that, tbh.
17:28:46 <mjg59> We don't need to micromanage collaboration
17:29:00 <pjones> mjg59: I'm +1 to your proposal there.
17:29:10 <limburgher> mjg59, pjones: +1. If it's not, it will blow up, and we'll know.
17:29:20 <pjones> yeah
17:29:22 <nirik> sure, I'm ok with that too... I'd urge them to all communicate tho so we don't end up asking people things twice, or never.
17:29:42 <jwb> maybe even use the devel@ list as a place to discuss... development
17:29:50 <nirik> that would be novel
17:30:01 <pjones> Is that a thing we do now?
17:30:06 <limburgher> jump back.
17:30:09 <jwb> there's always a first time!
17:30:10 <t8m> well given the recent churn on devel it might not be too productive
17:30:33 <nirik> so, I see +3 ?
17:30:40 <mitr> +1 to proposal... my mail has reached the feature owners, at least, so people will hopefully handle this
17:30:42 <jwb> i am for pjones' proposal
17:30:45 <notting> i am +1 to this
17:30:45 <limburgher> t8m: +5 eyeroll :)
17:31:11 <t8m> ok +1 as well to the mjg59 proposal
17:31:15 <mjg59> I'm +1, obv
17:31:30 <nirik> #agreed Feature is approved. (+8/0)
17:31:40 <nirik> #topic ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure
17:31:40 <nirik> .fesco 863
17:31:41 <zodbot> nirik: #863 (F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure) – FESCo - https://fedorahosted.org/fesco/ticket/863
17:31:50 <nirik> +1, seems fine to me.
17:32:00 <limburgher> +1
17:32:05 <mitr> +1
17:32:12 <t8m> +1
17:32:34 * jwb gives in to the +1-isms
17:32:35 <jwb> +1
17:32:37 <mjg59> +1
17:32:42 <notting> how would the building & packaging with rpm-ified clojure packages work with people used to working with it beforehand?
17:33:24 <hircus> notting: eventually the goal is to use Leiningen the same way Maven work for Java packages
17:33:40 <hircus> i.e. provide an RPM offline mode that doesn't check versions, and the normal operational mode
17:34:06 <notting> so if you run it to grab your deps, it grabs some from packages, and some from <random upstream source>?
17:34:49 <hircus> well, with Maven, if you run it in online mode, it's more likely to pull most from the main Maven repos, given that pom files over-specify versions, normally
17:34:57 * pjones +1
17:36:20 <nirik> mmaslano was +1 in ticket.
17:36:35 <nirik> notting: more info, or vote?
17:36:55 <notting> hircus: so, to use the system deps packaged this way, you'd need to install them out-of-band (via su, authed package kit, whatever)?
17:37:37 <hircus> notting: two separate goals - one, to be able to have some Clojure apps (e.g. Pallet, a DevOps tool) available as RPMs
17:38:11 <hircus> the other one - to have the tools Clojure devs expect to have (e.g. Leiningen) available, but they'd use it just as they normally do (with standard repos).
17:38:39 <hircus> Debian's packaging is more #2 at the moment. we're hoping to package more eventually
17:38:56 <notting> essentially, i'm trying to compare&contrast with how rake/bundler/rubygems work
17:39:20 <hircus> ah, yes. not too familiar with how that works, is that mostly identical to Python eggs?
17:39:36 <limburgher> I think they're more like CPAN.
17:39:37 <notting> there there is no integration at the moment... it all goes to rubygems.org (AIUI)
17:40:05 <kushal> hircus, like pip and eggs
17:40:28 <hircus> at the moment, no, we've not had time to tweak Leiningen. once it goes in (dependent on deps being reviewed and some Maven bugfixes) then we'd make sure it picks up packages registered in /usr/share/maven-poms
17:40:53 <notting> but getting them registered there while you're developing as a user is outside the scope of this? ok.
17:40:55 <hircus> kushal: yes, Python eggs would be the ideal result
17:42:14 <hircus> right, as a user you won't be installing things into the system-wide repo
17:43:17 <notting> i mean, +1 in that it's not wrong to include it. i'm a bit concerned about the unclear usage case around an app developer trying to use leiningen with system-provided packages, but we have that problem with lots of languages
17:43:35 <nirik> #agreed Feature is approved (+9/0)
17:43:39 <nirik> yeah, we do. ;(
17:43:54 <limburgher> FutureFeature: Fix all languages.
17:44:13 <kushal> limburgher, :)
17:44:14 <hircus> yeah. I have that concern myself, though I think by F18 we can get Leiningen to at least source packages from the system repo properly
17:44:17 <nirik> #topic ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF
17:44:17 <nirik> .fesco 864
17:44:19 <zodbot> nirik: #864 (F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF) – FESCo - https://fedorahosted.org/fesco/ticket/864
17:44:34 <jwb> out of curiosity, what does DNF stand for?
17:44:36 <t8m> limburgher, some languages' feature is that they're not fixable
17:44:44 <notting> jwb: hey, at least it's not named DTF
17:44:49 <nirik> mmaslano is +1 in ticket.
17:44:52 <limburgher> t8m: Don't. Get. Me. Started. :)
17:44:53 <hircus> t8m: like luarocks :p
17:45:05 <nirik> Duke Nuken Forever! :)
17:45:09 <t8m> +1 to DNF
17:45:11 <jwb> notting, i dunno. DNF is commonly Did Not Finish. not a great expansion for a package manager
17:45:13 <hircus> upstream actively rejected python eggs-type integration
17:45:31 <mitr> +1 to DNF, as well
17:45:32 <limburgher> So, for DNF. . .this is just to get it in, not to replace yum?
17:45:34 <mjg59> jwb: Ticket says it's meaningless
17:45:41 <mjg59> Er, discussion page
17:45:50 <mjg59> I think it'd be nice to know what future plans are
17:45:51 <t8m> limburgher, sure
17:46:08 <mjg59> Is this intended to prototype functionality that'll head back to yum?
17:46:08 <jwb> mjg59, ah
17:46:23 <mjg59> Or is it going to sit there as an alternative and some time later we'll have a contentious argument about defaults?
17:46:24 <limburgher> I'm just curious what about yum in perceived as broken.
17:46:24 <jwb> mjg59, i think it is actually positioned as an eventual replacement for yum
17:46:25 <notting> i am curious "why fork", as well
17:46:32 * hughsie is wondering how the non-yum-compatible-depsolver issue is going to be worked out after the zif fiasco... :)
17:46:40 <mjg59> notting: I think this is probably one of the best answers to "why fork"
17:46:46 <limburgher> hughsie: Jinx.
17:47:05 <mjg59> hughsie: Presumably in an ideal world we all consolidate on libsolve
17:47:14 <mitr> notting: breaking plugin compatibility, I think
17:47:30 <hughsie> mjg59, fwiw, i'm planning to port Zif to the hawkey thing, which uses libsolv
17:47:48 <pjones> yeah, not inclined to vote for this thing until those questions are answered.
17:47:50 <mjg59> hughsie: Yeah. If DNF ends up being folded back into yum then I think everyone wins
17:48:00 <nirik> limburgher: yes, a preview/early picture, etc.
17:48:01 <nirik> +1 here provided this is being coordinated with yum maintainers, which I think it is.
17:48:04 <mjg59> Also, if we're advertising it as a feature, then I'd expect pk integration
17:48:05 <limburgher> mjg59: Agreed.
17:48:12 * nirik sees +4 so far
17:48:27 <mjg59> hughsie: Heard anything about that?
17:48:49 <hughsie> mjg59, well, from looking at hawkey and dnf, i don't see it yum compatible at all
17:48:53 <mitr> mjg59: I think this is "we added a package, please come and play with it" kind of feature, not "this is a change for everybody" kind of feature
17:49:16 <hughsie> mitr, i think that's the spirit, yes
17:49:44 <mjg59> mitr: I agree, but I think any package manager we advertise should integrate with the existing package management interface
17:49:53 <mitr> So, PK integration will eventually be required, but is not a prerequisite for adding that line to release notes
17:49:59 <t8m> mjg59, this is definitely not a replacement for anything (yet) so integration with pk is futurefeature
17:50:08 <hughsie> mjg59, dnf is missing a lot of features PK needs
17:50:15 <mjg59> I've no objection to it being in an archive, but I don't think it's a feature until it has at least rough functional equivalence
17:50:16 <jwb> then why would we bill this as a Feature?
17:50:21 <hughsie> by a lot, i mean, 80%
17:50:30 <hughsie> jwb, i agree
17:50:37 <jwb> this seems to be no more a feature than, say, adding apt
17:50:50 <nirik> I think they were seeing press in order to get people trying it out, reporting bugs, contibuting.
17:50:56 <nirik> seeking
17:51:29 <t8m> we are regularly +1 features that are nothing more than advertisements
17:51:50 <jwb> honestly, i think this is going to boil down to our very muddy definition of a feature and what everyone believes that to be
17:51:55 <t8m> it seems to me a double standard if we don't accept this one
17:52:03 <mitr> jwb: I think it falls under 3. and 5. in http://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a...
17:52:04 <limburgher> +1.
17:52:14 * nirik notes we also have the related Hawkey feature.
17:53:15 <notting> we do have alternative package managers, but some are barely supported at all in some regards. (smart, apt)
17:53:16 <jwb> mitr, yet in the checklist, it only matches 5
17:53:22 <notting> i assume this will be more so, even if it's a tech preview?
17:53:43 <nirik> I would hope the plan is to replace yum or merge changes back to it...
17:53:51 <nirik> we could defer and ask for that info?
17:53:53 <notting> in any case, it's reasonable by feature standards assuming the maintainers are willing to deal with the onslaught of people trying it and breaking it, so ... +1
17:53:57 <mitr> notting: IIUC at least one person is working on it full-time
17:54:00 <nirik> or just approve as it has +6 now.
17:54:33 <limburgher> I certainly need to see a list of "what's broken in yum and why it can't be fixed" before voting to replace it, but sure, put it in the distro.
17:54:34 <jwb> i guess i'm +1 if it's clearly labeled as a tech preview (or the fedora equivalent of such)
17:54:46 * hughsie assumed dnf was going to obsolete yum long term...
17:54:59 <hughsie> the emphasis on "long".
17:55:05 <t8m> I think so
17:55:53 <nirik> ok, so thats +7 ? /me recounts.
17:55:56 * hircus wondering if anyone knows what dnf is supposed to stand for
17:56:05 <hughsie> hircus, supposedly, nothing
17:56:07 <mjg59> Welcome to the start of this conversation
17:56:13 <gholms> It's too many syllables. :(
17:56:13 <mjg59> Well ok +1 then
17:56:18 <t8m> hircus, nothing - its on the talk page of the feature
17:56:22 <hircus> aha, ok
17:56:23 <limburgher> domain name fystem?
17:56:34 <nirik> pjones: vote?
17:56:35 <pjones> gholms: just pronounce it like it's an eastern european word and "n' is the vowel.
17:56:43 <pjones> nirik: vaguely +0.
17:56:44 <gholms> Heh
17:56:59 <nirik> #agreed Feature is approved (+8/0)
17:57:07 <nirik> #topic ticket 867 F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey
17:57:07 <nirik> .fesco 867
17:57:11 <zodbot> nirik: #867 (F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey) – FESCo - https://fedorahosted.org/fesco/ticket/867
17:57:16 <nirik> same thing here? I'm +1
17:57:30 <limburgher> Yeah. +1
17:57:33 * nirik wonders if both these couldn't be folded into one feature.
17:57:36 <pjones> I don't really see why this should be a separate feature
17:57:41 <mitr> I'm not sure why the two should be separate
17:57:49 <mitr> But it doesn't matter one bit, in the end.... so +1
17:57:49 <notting> yeah, i'd merge this into DNF
17:58:01 <jwb> i would agree with merging with DNF
17:58:06 <limburgher> I think the only make sense together, sort of pointless if one got in and not the other.
17:58:11 <nirik> +1 to merge into DNF.
17:58:14 <notting> proposal: merge into DNF
17:58:19 <mjg59> +1
17:58:19 * pjones +1 to notting's proposal
17:58:22 <limburgher> +1 to merge
17:58:27 <mitr> limburgher: Well, hawkey could end up testable and dnf broken
17:58:45 <limburgher> mitr: True.
17:59:03 <hughsie> mitr, zif kinda will depend on hawkey, not dnf, so i think it's seporate
17:59:31 <nirik> well, if thats the case just before feature freeze, scope could be adjusted to no longer include dnf?
17:59:49 <t8m> I'm fine either way - merging or separate feature
17:59:55 <mitr> but merging is fine with me as well, cuts down on the process.
18:00:05 * hughsie agrees
18:00:12 * mitr counts +5 to merge
18:00:38 <nirik> #agreed Feature is approved, please merge it with the DNF feature.
18:00:53 <nirik> #topic ticket 865 F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg
18:00:53 <nirik> .fesco 865
18:00:55 <zodbot> nirik: #865 (F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg) – FESCo - https://fedorahosted.org/fesco/ticket/865
18:01:09 <notting> hm a feature which our guidelines say you cannot use in packages
18:01:10 <nirik> +1, but I wonder if there's a llvm guideline, do you want one on this as well?
18:01:13 <brouhaha> This is another one for publicity (criteria 3 and 5)
18:01:18 <t8m> +1
18:01:25 <brouhaha> MinGW is also not usable to build Fedora packages
18:01:33 <drago01> it is
18:01:36 <jwb> notting, in fedora packages, yes. but you can use it for whatever you want to build
18:01:40 <brouhaha> This is a feature for developers, but not for development of Fedora.
18:01:42 <limburgher> +1
18:01:45 <mitr> nirik: There was a recent guideline against using LLVM where GCC is suported, it would probably apply here as well
18:01:48 <mitr> +1 to feature
18:01:54 <limburgher> mitr: Indeed it would.
18:02:21 <_jakub_> if it adds yet another hard gcc = %{version}-%{release} dependency, won't make me very happy on any gcc upgrades, especially if the maintainer won't be able to have quick turnaround
18:02:34 * nirik still doesn't think that's needed, but that ship has sailed. ;)
18:02:35 <brouhaha> I will try to do turnaround quickly.
18:02:51 <_jakub_> and I don't see much point for the distro about using LLVM optimizers with GCC FE, but can live with it
18:02:58 * hircus notes that the clang hard dependency is lifted in 3.0
18:03:03 <mitr> _jakub_: Has that historically caused problems?
18:03:04 <nirik> brouhaha: perhaps you could add _jakub_ as a co-maintainer?
18:03:15 <brouhaha> _jakub_, also useful for cross development, e.g., x86 to ARM
18:03:18 <limburgher> nirik: That sounds like an excellent idea.
18:03:22 <hircus> dragonegg might make LLVM more useful for C++ -- since clang++ lags behind in supporting the latest C++0x features
18:03:34 <brouhaha> nirik, I'd be happy to add _jakub_ as co-maintainer, if he's willing.
18:03:38 <pjones> I think maybe it's worth asking _jakub_ if he would want to be comaintainer or if that's just going to give him more work :)
18:03:52 <hircus> brouhaha: speaking of comaintenance -- want to comaintain LLVM :)
18:03:54 <_jakub_> mitr: yes, currently there is gcc-python-plugin which is constantly broken deps in rawhide and releases up until close to release
18:04:01 <nirik> pjones: sure, I didn't want to cause more work, just wanted to open the possiblity of fixing it if easy/desired.
18:04:37 <brouhaha> hircus: I'm open to the idea. I'm not at C++ expert level yet, but I'm getting better.
18:04:45 <_jakub_> and that one is actually useful
18:04:48 <mitr> _jakub_: does that affect only rawhide users that have gcc-python-plugin installed? Or is it making your work more dificult?
18:05:25 <_jakub_> mitr: it is mainly an issue when doing released distro updates, I then have to make sure all plugins (and libtool usually) are rebuilt as well
18:05:50 <brouhaha> Is there an easy way that I can get automatic notifications of new gcc builds in rawhide, to ensure that I know to update dragonegg quickly?
18:06:17 <brouhaha> (and in releases also!)
18:06:21 <notting> you can subscribe to koji notifications
18:06:26 <_jakub_> but I think clang is now requiring gcc version-release or at least version too, so that is already not fun
18:06:30 <brouhaha> notting: OK, I'll do that.
18:07:11 <nirik> if these things are just simple rebuilds, do consider adding more comaintainers that are around to do them more quickly.
18:07:20 <t8m> _jakub_, is the plugin ABI really broken by each rebuild?
18:07:23 <hircus> _jakub_: ah, my bad. yes, it still does, they just made it saner in the way it picks up the GCC version
18:07:45 <_jakub_> t8m: potentially broken, the ABI is simply not stable yet
18:07:46 <hircus> it depends on libstdc++, really, but that's in lockstep as GCC
18:07:59 <nirik> anyhow, back to the feature, I see +4.
18:08:14 <mjg59> +1
18:08:19 <_jakub_> t8m: I think dmalcolm is working on some stable ABI, but it is not there yet
18:08:22 <hircus> _jakub_: how hard would it be to maintain a separate, frozen version of libstdc++ ? that'd fix a lot of the clang-caused breakages
18:08:43 * t8m wonders if that version-release dependency should really be so exact
18:09:08 <hircus> version-only would suffice, actually. note to self: take a look tomorrow
18:09:39 <_jakub_> hircus: libstdc++ doesn't change that much after releases, but from time to time
18:10:08 <nirik> ok, thats +5... any other votes?
18:10:12 <hircus> _jakub_: right. but sometimes (as in F-16) GCC gets a major update, and that's what breaks clang
18:10:27 <hircus> anyway, back on topic
18:10:50 <jwb> nirik, +1
18:11:05 <_jakub_> hircus: I'm definitely not against a dependency on GCC major.minor, the problem is on major.minor.patchlevel or even release
18:11:32 <brouhaha> _jakub_, do you think plugin ABI typically changes on patchlevel?
18:11:51 <brouhaha> _jakub_: I can certainly relax the dependency to major.minor, if you think that's reasonable.
18:12:03 <hircus> _jakub_: the .patchlevel is an upstream problem, alas. the release is a packaging error on my part, I just blindly followed the guideline
18:12:26 <_jakub_> brouhaha: patchlevel is uninteresting, it is just a time when we package it up each few months
18:12:47 <pjones> nirik: yeah, +1
18:13:03 <nirik> #agreed Feature is approved (+7/0)
18:13:09 <_jakub_> brouhaha: but, some fixes might actually affect the plugin ABI at any time, though not very likely (but, we really don't know, because the plugin ABI is essentially all GCC headers)
18:13:20 <nirik> #topic ticket 866 F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor
18:13:20 <nirik> .fesco 866
18:13:22 <zodbot> nirik: #866 (F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor) – FESCo - https://fedorahosted.org/fesco/ticket/866
18:13:37 <brouhaha> _jakub_: I'll try to do my own retest with each new GCC build.
18:13:38 <nirik> mmaslano is +1 in ticket
18:14:04 <notting> how much will this add to build time, out of curiousity?
18:14:06 <jwb> i asked about how this interacted with the minidebuginfo proposal, if at all
18:14:13 <nirik> I'm +1, we will need to coordinate mass rebuilding.
18:14:22 <t8m> +1
18:14:43 <mjg59> +1
18:14:50 <_jakub_> notting: on a mid speed AMD box all of debuginfos took roughly 6 hours to compress or so
18:14:53 * pjones is +1 here
18:15:17 <limburgher> +1
18:15:29 <_jakub_> there are two parameters that will need to be carefully chosen on each arch depending on build box RAM amount/speed
18:15:33 <notting> _jakub_: split across all packages that's.... negligible? (if i didn't screw up the math)
18:15:57 <mitr> notting, _jakub_: are times for kernel (and libreoffice?) particularly high?
18:15:59 <_jakub_> notting: on libreoffice it can be like 5 minutes or so, but that is the slowest one
18:16:07 <nirik> _jakub_: are those hard coded? or dynamic according to the build machine?
18:16:12 <mitr> That's good :)
18:16:21 <mitr> +1
18:16:39 <notting> +1. although the linguistic implications of compressing dwarves is amusing
18:16:46 <pjones> indeed.
18:16:47 <hughsie> heh
18:16:52 <kushal> :)
18:17:01 <_jakub_> nirik: those should be hardcoded in redhat-rpm-config IMHO, it would be very weird if size of debuginfo differed depending on how much RAM the build box had at that day
18:17:04 <mitr> _jakub_: Hm, are there any packaging implications from the multifile copmression support?
18:17:26 <mitr> IOW, where is the shared file placed?
18:17:26 <nirik> _jakub_: not all our builders have the exact same memory...
18:17:30 <_jakub_> mitr: we should handle everything transparently from find-debuginfo.sh, which will need to be changed
18:17:36 * nirik wonders what the answer to jwb's question was.
18:17:43 <jwb> nirik, me too1
18:17:46 <mitr> _jakub_: great
18:17:58 <_jakub_> mitr: my proposal is to put the shared file as /usr/lib/debug/.dwz/%{name}-%{version}-%{release}.%{arch}.debug
18:18:18 <notting> minidebuginfo is, AIUI, a separate section. whether it's compressed or not is entirely up to minidebuginfo
18:18:43 <_jakub_> mitr: the *.debug files will contain relative path from those *.debug file directories to the picked up shared filename
18:18:46 <jwb> notting, but does compressed dwarf render minidebuginfo's benefits moot? does it make them better? etc
18:19:23 <_jakub_> minidebuginfo is about .symtab/.strtab, so has nothing to do with dwz
18:19:34 <pjones> yeah, they really aren't related
18:19:37 <_jakub_> dwz doesn't touch those sections at all
18:19:41 <notting> my understanding is that compressed dwarf is sitll Too Big to include by default
18:19:49 <_jakub_> yeah
18:20:10 <nirik> ok.
18:20:26 <_jakub_> I'd like to use -g3 by default though, to improve debugging and e.g. security checking (for -D_FORTIFY_SOURCE etc.)
18:20:44 <nirik> jwb: vote? or more info?
18:20:45 <_jakub_> with dwz -m the -g3 cost should be really very small
18:20:57 <notting> _jakub_: any reason -g can't be aliased to -g3?
18:20:57 <jwb> nirik, no, i'm fine. +1
18:21:27 <_jakub_> notting: 1) it would be confusing 2) would break gcc testsuite badly (all the assembly scanning etc.)
18:21:28 <nirik> #agreed Feature is approved (+9/0)
18:21:56 <mitr> _jakub_: How does -g3 affect _FORTIFY_SOURCE? That sounds kind of unexpected
18:22:20 <_jakub_> mitr: from .debug_macro you can verify if things have been built with that macro or not
18:22:47 <mitr> Ah, ok
18:22:51 <_jakub_> mitr: thus automation can be added to catch e.g. the recent libreoffice building with -O0 and thus without fortification
18:23:20 <pjones> One more thing I'll have to change in all my 'doesn't run in linux' packages.
18:23:37 <nirik> #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo
18:23:37 <nirik> .fesco 868
18:23:42 <zodbot> nirik: #868 (F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo - https://fedorahosted.org/fesco/ticket/868
18:24:03 <nirik> mmaslano was 0 in ticket.
18:24:24 <nirik> I'm -1.
18:24:28 <limburgher> Seemed. . .mildly contentious. . .
18:24:34 <mitr> I think the only technical objection was that spins won't fit on a CD, but when repeatedly asked nobody came up with an example user/ambassador saying that CDs are needed
18:24:54 <mezcalero> nirik: out of curiosity, why do you say -1?
18:25:17 <notting> i am +1. obviously would need to be coordinated with any dmz -related rebuilding
18:25:21 * pjones is also +1
18:25:33 <nirik> I don't think the extra size is worth the gain. I think we can/should work on making abrt better.
18:25:34 <hughsie> i don't know if i should comment, but from my role as an upstream maintainer, this would be *really* useful for real life debugging from end users...
18:25:44 <limburgher> mitr: Would dwarf compression help that?
18:25:48 <jwb> i'm marginally +1
18:25:55 <pjones> limburgher: no - different set of fields
18:25:56 <mitr> limburgher: _jakub_ said above that it is orthogonal
18:25:57 <t8m> as long as it does not replace full backtraces reported in ABRT I'm ok with it so marginally +1
18:26:11 <mitr> AFAICS this "only" benefits developers and reading crashes in unexpected components, but given Fedora's target arudence, +21
18:26:14 <mitr> +1 that is
18:26:16 <limburgher> mitr, pjones: Missed that, thanks.
18:26:22 <limburgher> Ok. +1
18:26:24 <mjg59> I lean +1
18:26:43 <mitr> nirik: My best guess is that abrt will just ignore this.
18:26:57 <nirik> #agreed Feature is approved. (+7/-1/0)
18:27:01 <_jakub_> I don't see what minidebuginfo gives us as advantage for bugreporting, in theory all you need is addresses (relative to start of DSOs) and their build-ids, everything can be recomputed from that
18:27:03 <limburgher> I wish spins could stay on CDs, but then I still want CD and floppy install media. <stares wistfully into the past>
18:27:13 <nirik> This also needs mass rebuild?
18:27:14 <jwb> i was hoping it would light a proverbial fire under abrt's arse
18:27:27 <gholms> Heh
18:27:31 <mitr> nirik: yes
18:27:37 <jwb> _jakub_, mostly it's that nobody has gotten around to doing that yet.
18:27:40 <notting> apologies, i have to go. (will leave window open for reading later)
18:27:43 <nirik> ok.
18:27:52 <nirik> have a good one notting...
18:27:56 <nirik> #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates
18:27:57 <nirik> .fesco 869
18:27:58 <zodbot> nirik: #869 (F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates) – FESCo - https://fedorahosted.org/fesco/ticket/869
18:28:12 <_jakub_> jwb: I thought the abrt server is capable of doing such textual replacement, just nothing generates such backtraces yet
18:28:18 * hughsie pings mezcalero
18:28:18 <mitr> _jakub_: I think it is primarily helpful when not reporting a bug, but wanting to diagnose a crash locally quickly (without waiting on a debuginfo download)
18:28:42 <_jakub_> anyway, when would be the mass rebuild planned for?
18:28:52 <nirik> sure, +1 here I guess, as long as it only affects desktop machines/etc... I don't think it's ideal, but I understand the reasoning.
18:29:06 <nirik> _jakub_: we need to coordinate with dgilmore on that.
18:29:10 <nirik> _jakub_: I'll file a rel-eng ticket to track it.
18:29:10 <mezcalero> hughsie: pong
18:29:24 <hughsie> mezcalero, see title. :)
18:29:24 <mitr> Hm. In general controlled updates are probably the right tradeoff, but yum/rpm maintainers wanted a discussion about doing this in a different layer
18:29:33 <_jakub_> if possible I'd like to see the dwz changes in rawhide for a fortnight or so before rebuilding everything
18:29:44 <mezcalero> hughsie: yupp, i am following ;-)
18:29:44 <limburgher> _jakub_: +1
18:29:51 <hughsie> mitr, i'm aiming this to be for all distros, not just Fedora
18:29:58 <hughsie> it's a GNOME3 feature, afterall
18:30:19 <mitr> hughsie: That's a concern for Fedora, but should not be the primary concern.
18:30:20 <nirik> _jakub_: when would that be ready to land?
18:30:35 <limburgher> hughsie: I'm a user, I understand the benefits, how do I turn it on and off?
18:30:43 <hughsie> limburgher, gpk-prefs
18:30:44 <mitr> hughsie: From what I've read so far, desktop-level sounds right, but I haven't seen any arguments for the lower levels so far
18:31:19 <hughsie> limburgher, the "automatically install" combo becomes "automatically download"
18:31:30 <limburgher> hughies: So if I don't have PK installed, it's a NOOP? What about upgrades? Will my f17 start doing this once I upgrade to f18?
18:31:32 <hughsie> if stuff is never autodownloaded, then there's never any new ui shown
18:31:43 <cwickert> hughsie: just to be clear about this: will I still be able to update "OS components" with gpk-update-viewer and without reboot?
18:31:58 <mjg59> hughsie: This doesn't seem entirely clear from the description - would all packages be updated in the offline mode, or only a subset?
18:31:59 <hughsie> limburgher, it's a noop for non-PK sure. Upgrades would have to be handled i guess.
18:32:08 <mjg59> hughsie: Ie, would some set of packages still be installed at runtime?
18:32:12 <hughsie> mjg59, just the ones that were idle-downloaded
18:32:18 <t8m> I partially agree with the argument that this encourages proliferation of applications that are broken if running during upgrades.
18:32:24 <hughsie> mjg59, only runtime would be applications that are not currently running
18:32:24 <limburgher> hughsie: Right. If I don't have PK, I don't want to upgrade and find that I now have it.
18:32:34 <hughsie> limburgher, sure, agree
18:32:51 <hircus> hughsie: it'd pull in packages that are dependent on specific versions of system packages that get updated, right?
18:32:52 <cwickert> mjg59: the definition of "application" is "whatever has a desktop file and shows up in the menu". these apps can still be updated
18:32:53 <mjg59> hughsie: If I'm running firefox and an update gets downloaded then it won't update, but if I'm not running firefox it will?
18:32:58 <hughsie> t8m, i think we're deluding ourselves if we think live-updating is working now...
18:33:03 <nirik> _jakub_: https://fedorahosted.org/rel-eng/ticket/5222 if you want to cc/add your scheduling.
18:33:17 <hughsie> mjg59, the live update stuff is only done by user action
18:33:26 <hughsie> i.e. in the updater GUI
18:33:27 <t8m> hughsie, sure it does not work perfectly but at least sometimes does
18:33:35 <mjg59> hughsie: Not following you now
18:33:46 <mjg59> hughsie: Ah, ok, I see
18:33:49 <hughsie> t8m, the time it breaks, i get to sort out the bugzilla
18:34:05 <mitr> t8m: I think if we want updates without reboots to work reliably, it would be necessary to start from the other end: figure out a heuristic for _reliably_ identifying things that can be updated without reboot - and then gradually expand that heuristic to handle larger and larger shares packages. _If_ someone is interested enough to do that.
18:34:15 <mjg59> hughsie: Is it possible for a package to indicate that it can support in-place updates?
18:34:44 <hughsie> mjg59, at the moment, no, but we're planning to add extra metadata to desktop files in the future for the Application installer, so it's easy to do that then
18:35:03 <hughsie> we just have to specify stuff like how to shut the app down saving state and how to bring it back up restoring state
18:35:18 <hughsie> assuming not everything uses GtkApplication
18:35:22 <mjg59> hughsie: Ok, so the assumption will be "Packages must opt-in to automatic runtime updates", and never "Packages must opt-out"?
18:35:22 <hughsie> that's F19+ tho
18:35:28 <hughsie> right
18:35:32 <mjg59> Ok
18:35:38 <mjg59> Well I look forward to that glorious future
18:35:47 <mjg59> It does sound more workable than what we have today
18:36:02 <hughsie> you and me both. For the GtkApplication stuff we can do a lot of stuff automatically -- i.e. send signals
18:36:17 <hughsie> for stuff like openoffice and firefox it'll be harder
18:36:26 <hughsie> so that's not part of this feature
18:36:39 <mjg59> Ok, so I'm +1
18:36:42 <mezcalero> tbh i doubt we could ever flag more than documentation packages as "don't need offline upgrade", simply because the many indirections of our stack
18:37:20 <hughsie> also, restarting firefox again is kinda hard when it's running for two different users on the same machine
18:37:20 * nirik checks for votes... I see +2?
18:38:05 * mitr isn't sure what to do about the yum/rpm developers concerns
18:38:22 <mitr> I'm leaning towards +1, given that there's little specific to go on...
18:38:37 <hughsie> panu was pretty clear he didn't want process parsing stuff in rpm, has that changed?
18:38:45 <nirik> mitr: well, I think the thought is that they could setup something like this is they wished?
18:39:04 <nirik> well, in yum... perhaps a plugin? yum-apply-updates-reboot ?
18:39:16 <hughsie> nirik, you need a session component too
18:39:29 <nirik> true...
18:39:34 <mitr> nirik: Having two different mechanisms queue the same set of updates sounds risky
18:39:37 <nirik> in any case thats beyond the scope of this feature?
18:39:41 <hughsie> right
18:40:15 <jwb> +1
18:40:16 * nirik is still +1
18:40:33 <nirik> so, thats +4? more votes?
18:40:35 <pjones> yeah, weak +1
18:40:49 <mitr> weak +1 as well, I suppose.
18:41:10 <mitr> (For the record, the snapshot/restore idea doesn't sound at all practical, but that's not a current concern.)
18:41:33 <t8m> +0 for historical and cultural reasons :)
18:41:44 <nirik> #agreed Feature is approved (+6/-1/0)
18:41:59 <nirik> #topic ticket 870 F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename
18:42:00 <nirik> .fesco 870
18:42:02 <zodbot> nirik: #870 (F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename) – FESCo - https://fedorahosted.org/fesco/ticket/870
18:42:07 <mezcalero> mitr: i'd probably make use of the snapshot stuff right from day 1 on actually. i.e. do a rwahide upgrade, see if it boots, if not, revert
18:42:28 <nirik> mmaslano is +1 in ticket on this one.
18:42:32 <jwb> so is this something that just needs to happen, or is there a PR component that would make it a feature?
18:42:33 <nirik> I'm +1 as well.
18:42:40 <t8m> +1
18:42:40 <mitr> mezcalero: losing log file contents, state (especially clustered/replicated databases would be fun), ...?
18:42:46 * pjones +1
18:42:52 <nirik> jwb: yeah, more noise to let users know that it's changed... etc.
18:43:03 <hughsie> mezcalero, surely that implies btrfs on / by default?
18:43:04 <mezcalero> mitr: sure, for my rawhide upgrades, i'd be totally happy!
18:43:04 <pjones> jwb: I think it's just a matter of keeping people using sebool informed
18:43:05 <mitr> +1
18:43:16 <jwb> i don't see why this can't just be a ticket with the docs people
18:43:20 <jwb> but whatever. +1
18:43:23 <mitr> mezcalero: right, it makes much more sense for rawhide
18:43:34 <mezcalero> mitr: in fact i currently do this with qemu -snapshot all the time
18:43:45 <mezcalero> mitr: i, test boot a qemu VM, and drop all changes
18:44:04 <mezcalero> mitr: with btrfs snapshots in the loop i could actually test boot the real hw the same way!
18:44:38 <mezcalero> hughsie: well, this was mostly referring to my own use, but yes, sooner or later i hop for btrfs on / for everybody by default...
18:45:06 <limburgher> +1
18:45:18 <nirik> #agreed Feature is approved (+7/0)
18:45:30 <nirik> #topic ticket 871 F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd
18:45:30 <nirik> .fesco 871
18:45:41 <zodbot> nirik: #871 (F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd) – FESCo - https://fedorahosted.org/fesco/ticket/871
18:45:58 <nirik> mmaslano is +1 in ticket
18:46:23 <nirik> This is a continuation of this feature since f15 I guess...
18:46:29 <limburgher> +1 publicity
18:46:36 * nirik is +1 here, hope we someday finish
18:46:39 <tibbs|w> Still says "Fedora 17" in one place.
18:46:41 <mitr> +1
18:46:45 <pjones> I'm sorry, I fell asleep.
18:46:47 <jwb> -1
18:47:14 <pjones> I really don't see any reason this needs to be a "Feature". Again.
18:47:18 <jwb> exactly
18:47:20 <nirik> jwb: for lack of featureyness?
18:47:32 <jwb> yes. also, for it being submitted since f15 and still not done
18:47:39 <t8m> +1
18:47:42 <tibbs|w> Note that packaging guidelines do not forbid the use of old-style initscripts.
18:47:43 <jwb> i mean, the work is great and needed but damn
18:47:50 * mezcalero is mildly surprised that his name is on the feature page, but is not opposed ;-)
18:48:04 <Viking-Ice> last relese cycle nirik requested this to be submitted again for the feature process hence I did it yet again
18:48:33 <nirik> Viking-Ice: do you think it's helped get people assisting to be a feature? or hasn't mattered?
18:49:14 <Viking-Ice> it helps having this as a feature but with regards to man power not so much
18:50:14 <nirik> how does having it a feature help? if it does I'm happy to approve it again... if it doesn't, perhaps we shouldn't bother?
18:50:42 <Viking-Ice> mezcalero, you agreed to be on that feature in f15 and this is the same page s/15/16 etc.. I can remove you from it if you so wish
18:51:03 <mezcalero> Viking-Ice: no, leave me on it!
18:51:11 <mezcalero> Viking-Ice: i am am a fan of this, totally
18:51:24 <mezcalero> Viking-Ice: in fact i wished i had more time (could fork() myself) to spend more time on this, too
18:51:30 <Viking-Ice> nirik, it helps being backed by fesco from maintainers perspective
18:51:48 <nirik> ok, I'm happy to still be +1 then.
18:52:01 <nirik> so, thats +5/-1 ?
18:52:04 <mjg59> +1
18:52:04 <nirik> any other votes?
18:52:08 <Viking-Ice> btw we are at "m" http://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17
18:52:26 <pjones> I'm still not really seeing the utility, so I'll stick with +0 since it's going to pass anyway.
18:52:43 <nirik> #agreed Feature is approved (+6/-1/0)
18:52:52 <nirik> #topic ticket 872 F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup
18:52:53 <nirik> .fesco 872
18:52:58 <zodbot> nirik: #872 (F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup) – FESCo - https://fedorahosted.org/fesco/ticket/872
18:53:17 <nirik> mmaslano was -1 in the ticket.
18:53:53 <t8m> I am also not convinced here -1
18:53:58 <mitr> -1 as well - removing /etc/sysconfig/* files is an anti-feature
18:54:22 <nirik> is there a replacement for the /etc/sysconfig files? just that the application/package needs to handle things better?
18:54:24 <mezcalero> removing /etc/sysconfig/ needs support from upstream i guess
18:54:27 <pjones> I don't see the featuryness here, and also those problems.
18:54:30 <limburgher> I'm -1. I see no point in breaking sysconfig. I'd like to see it gone, and don't want packages which don't use it to start, but removing it now is premature unless you're willing to patch the daemons involced.
18:54:46 <mezcalero> i.e. the individual packages need to support proper config files upstream, before we can drop support for the sysconfig hacks
18:55:01 <mezcalero> but otherwise i am all in favour of Viking-Ice's feature!
18:55:05 <tibbs|w> The replacement for sysconfig is editing a copy of the unit file copied to /etc.
18:55:30 <Viking-Ice> well arguably those files should be placed in their own directory under /etc
18:55:36 <nirik> tibbs|w: with specific env stuff added?
18:55:53 <tibbs|w> That's what I did for the packages of mine I converted to not have sysconfig files.
18:56:00 <Viking-Ice> relevant to their package and we point the environment file reference to that directory instead
18:56:10 * nirik is sort of 0 on this... it's stuff that would be great to do, but not sure it's really a feature.
18:56:10 <mitr> tibbs|w: Ironically, creating such a copy with /env has high risk of negating the other aspects of the feature (because whatever is changed in /lib will not be propagated into /etc)
18:56:25 <tibbs|w> Yep.
18:56:41 <alexlarsson> Sorry I got here a bit late, but since I'm the MiniDebugInfo guy, please direct any questions you have to me
18:56:52 <mezcalero> alexlarsson: your feature got accepted! yay!
18:56:58 <alexlarsson> yay!
18:57:20 <nirik> more votes, or comment on this feature? I see -4/0 so far.
18:57:22 <mezcalero> hmm, so the people who voted -1 on Systemd-unit-cleanup so far, is this only because of the sysconfig thing?
18:57:34 <alexlarsson> I guess i can continue taping plastic over my car window that got smashed :(
18:57:44 <mezcalero> i'd propose that the sysconfig bit is removed then, and would like to ask for another vote
18:58:00 <nirik> alexlarsson: also, see https://fedorahosted.org/rel-eng/ticket/5222 for scheduling on mass rebuilding.
18:58:12 <mezcalero> alexlarsson: btw, the feature was pretty nicely accepted +6, -1
18:58:43 <mezcalero> alexlarsson: i'd read that as clear support from fesco ;-)
18:58:43 <alexlarsson> Is the dwarf compressor also accepted?
18:58:48 <jwb> alexlarsson, yes
18:58:54 <mitr> mezcalero: Well, having a "cleanup systemd files" feature when "convert to systemd" has not even finished is kind of strange - I wouldn't want a "change all systemd unit files" to become a regular feature - but yes, removing the sysconfig bit would make it acceptable to me
18:58:55 <pjones> mezcalero: also because of lack of featuryness.
18:59:10 <limburgher> mitr: Me as well.
18:59:52 <mitr> mezcalero: At least with the understanding that the feature owner will find people interested enough to do the work. I don't think it's beneficial enough to require every developer to do this for their own packages.
18:59:56 <t8m> I think any changes of systemd units should be handled through package guidelines changes and not through feature process
18:59:57 <mezcalero> Viking-Ice: but, anyway, you are in charge, i'd remove the sysconfig bit for now though, this really needs more support from upstream in most cases i guess
18:59:59 <limburgher> pjones: Exactly. It's good work to do, great in fact, but it's more incremental than "Oooh, neat, look what f18 gives us that f17 didn't"
19:00:03 <mezcalero> Viking-Ice: and thanks for proposing this!
19:00:09 <mitr> t8m: That's a good point as well.
19:00:27 <nirik> so, -2, +2, 0 currently? any vote changes or more votes?
19:00:37 <jwb> i find the fact that this feature is getting -1 votes and the one before it didn't to be hilarious
19:00:42 * pjones is -1 , which he counts at -4 including himself
19:00:45 <mitr> The original systemd unit guidelines bypassed the FPC, let's not make a habit out of this
19:00:46 <jwb> -1
19:00:51 <nirik> jwb: yeah
19:00:53 <Viking-Ice> well we need to do this clean-up anyway to get units in sync with upstream systemd changes but arguably as mitr points out this should be done *after* we have migrated all units
19:00:59 <mjg59> I think -1
19:01:07 <pjones> so far I see t8m, mitr, limburgher, jwb, pjones, mjg59 as -1
19:01:21 <pjones> and mmaslano of course
19:01:40 <mitr> Viking-Ice: I am primarily pointing out that it should not be necessary to "get units in sync". There should be compatibility etc.
19:01:47 <nirik> pjones: mitr and limburgher were +1 after the dropping of /etc/sysconfig? or was that too stong a reading of vote change?
19:02:08 <Viking-Ice> mezcalero, but this is work ofcourse that could be combined with the preset feature should you decide to submit that for this release cycle
19:02:16 <mitr> pjones: I'd be +1 1) without /etc/sysconfig, and 2) after FPC accpets to change the guidelines
19:02:16 <pjones> nirik: I guess we'll have to ask them.
19:02:27 * nirik nods. waits.
19:02:27 <pjones> mitr: so that means you're -1 right now? :)
19:02:33 <mezcalero> Viking-Ice: preset was declined by fesco once, and i actually can understand why fesco did that
19:02:34 <limburgher> nirik: +1 to mitr's 1 and 2.
19:02:49 <mezcalero> Viking-Ice: and i need to do my homework on preset first, too, and get that through FPC
19:02:52 <mitr> pjones: well, 2) is a blocking condition, but not a prerequisite to me voting +1
19:02:56 <mezcalero> Viking-Ice: so my path for preset is FPC, not FESCO
19:03:14 <nirik> ok, so thats -8/0?
19:03:15 <Viking-Ice> mitr, it's better to clean unnecessary bits from the ( early ) submitted units
19:04:02 <mitr> mezcalero: Did you (or anyone else) follow up on the smarter RPM scriptlets (categories?collections) in connection to presets?
19:04:09 <t8m> Viking-Ice, but do you need a feature for that?
19:04:36 <nirik> #agreed Feature is not approved at this time. (-7/0)
19:04:51 <tibbs|w> FPC can fix up the guidelines quickly if someone gives us a draft.
19:05:00 <mezcalero> mitr: well, i haven't put together any new scriptlets yet, i need to do that
19:05:06 <Viking-Ice> t8m, for the /etc/sysconfig/foo files removal I believe so without it not so much
19:05:10 <mezcalero> mitr: which i will then submit to FPC
19:05:33 <nirik> #topic Next week Chair
19:05:39 <tibbs|w> Not sure how RPM collections gets wrapped up with that, though.
19:05:39 <mezcalero> Viking-Ice: btw, as I saw FPC now has adopted changes already to outlaw After=syslog and StandardOutput=error
19:05:49 <nirik> who wants to chair next week?
19:05:49 <Viking-Ice> we also need to fix file permissions on the submitted units ( some of them are wrong )
19:05:51 <mezcalero> Viking-Ice: so the FPC bits on that already got accepted
19:06:03 <mitr> I can chair next week
19:06:17 <nirik> note: I will be gone next meeting, and the meeting after. I might vote in tickets if I can get net, we will see. ;)
19:06:29 <t8m> Viking-Ice, also maybe you could merge cleanup of old and finishing up new units to one feature
19:06:31 <mezcalero> Viking-Ice: we should probably file a but to FPC to add the Documentation= suggestion to the packaging guidelines, but we should probably discuss that outside of this channel ;-)
19:06:36 <nirik> #info mitr to chair 2012-06-25 meeting.
19:06:37 <mezcalero> s/but/bug
19:06:39 <nirik> thanks mitr
19:06:53 <nirik> #topic Open Floor
19:07:09 <nirik> any business for open floor?
19:07:13 <mitr> mezcalero: _rpm_, not _FPC_. See the logs from the meating ~5 months ago that has rejected the presets feature
19:07:44 <mezcalero> mitr: hmm, what was that about?
19:08:52 <mitr> mezcalero: Not doing per-package scripts at all
19:09:00 <jwb> proposal: end the meeting
19:09:06 <nirik> :)
19:09:14 <nirik> if nothing else will close out in a minute.
19:09:25 <JSchmitt> poweroff
19:09:32 <pjones> that's the spirit.
19:09:38 <nirik> #endmeeting
11 years, 10 months
- 1
- 0
FAmSco meeting 2012-06-18 minutes
by Christoph Wickert
My fellow ambassadors,
the newly elected FAmSCo just held it's very first meeting. Sorry I did
not send out a reminder earlier, but I was a bit confused about the new
meeting time myself. We have now settled for
Monday at 17:00 UTC in #fedora-meeting-2.
And believe it or not, all 7 FAmSCo members were present and we had a
very productive meeting. I was re-elected as FAmSCo chair and appointed
Daniel Bruno as vice-chair.
I am looking forward to work with the new FAmSCo and I hope we can keep
up the pace and attendance.
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-...
Meet you again next week
Monday June 25th
at 17:00 UTC
in #fedora-meeting-2!
Regards,
Christoph
====================================
#fedora-meeting-2: FAmSCo 2012-06-18
====================================
Meeting started by cwickert at 17:01:26 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2012-06-18/famsco.2012-...
.
Meeting summary
---------------
* Roll Call (cwickert, 17:01:45)
* Announcements (cwickert, 17:08:13)
* We have a new FAmSCo: Christoph Wickert, Jiri Eischmann, Clint
Savage, Nick Bebout, Alejandro Perez, Daniel Bruno, Buddhika
Chandradeepa Kurera (cwickert, 17:09:06)
* Fedora Board Runoff Election is open till tomorrow, vote either nb
or evilbob at
https://admin.fedoraproject.org/voting/about/runoffboardf18
(cwickert, 17:10:06)
* AGREED: new FAMSCo meeting time is Monday at 17:00 UTC (cwickert,
17:14:49)
* new FAMSCo meeting time is Monday at 17:00 UTC (cwickert, 17:14:54)
* Election of the FAmSCo Chairs (cwickert, 17:19:44)
* LINK: https://fedoraproject.org/wiki/FAmSCo_election_rules
(cwickert, 17:19:50)
* AGREED: cwickert is the old and new FAmSCo chair (cwickert,
17:24:00)
* danielbruno is new FAmSCo vice-chair (cwickert, 17:31:25)
* Funding for fvollero for EuroPython (cwickert, 17:33:37)
* #297 can be closed, fvollero receives funding from his employer
(cwickert, 17:34:51)
* Funding for jreznik for LinuxTag 2012 (cwickert, 17:35:18)
* AGREED: #292 is approved (cwickert, 17:37:13)
* Budget review guidelines (cwickert, 17:37:33)
* ACTION: aeperezt to ask for feedback about #281 on the LATAM mailing
list (cwickert, 17:51:50)
* ACTION: all FAmSCo members to discuss #281 with their local
communities and provide feedback in the trac ticket (cwickert,
17:52:52)
* AGREED: : for now we go with 4 levels (0-499, 500-1999, 2000-5000,
5000+) and allow the regions to make their own rules. 5 ambassadors
should be rule of thumb for regional meetings, but exceptions may be
granted per region (cwickert, 17:54:20)
* Funding for fvollero for EuroPython (redux) (cwickert, 18:08:44)
* AGREED: #297 is approved, fvollero receives full funding for
accommodation at EuroPython, that is 425 EUR (cwickert, 18:15:38)
* Open Floor (cwickert, 18:15:52)
Meeting ended at 18:24:23 UTC.
Action Items
------------
* aeperezt to ask for feedback about #281 on the LATAM mailing list
* all FAmSCo members to discuss #281 with their local communities and
provide feedback in the trac ticket
Action Items, by person
-----------------------
* aeperezt
* aeperezt to ask for feedback about #281 on the LATAM mailing list
* **UNASSIGNED**
* all FAmSCo members to discuss #281 with their local communities and
provide feedback in the trac ticket
11 years, 10 months
- 1
- 0
Docs meeting summary -- 18 June 2012
by Ben Cotton
Meeting summary
---------------
* Roll Call (bcotton, 14:00:28)
* Follow up on last week's action items (bcotton, 14:04:04)
* ACTION: bcotton to draft QA Wrangler role description (bcotton,
14:04:21)
* ACTION: Sparks to follow up to mailing list about using koji to
publish docs.fp.o (bcotton, 14:06:04)
* ACTION: Sparks to file the ticket re: publishing with koji
(bcotton, 14:06:14)
* ACTION: Sparks to take man page website to mailing list (bcotton,
14:06:36)
* Sparks has completed to file the ticket re: publishing with koj
(bcotton, 14:07:21)
* Using koji to publish docs.fp.o (bcotton, 14:07:38)
* Publish man pages (bcotton, 14:25:32)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=828669 (bcotton,
14:28:02)
* QA recap (bcotton, 14:29:24)
* LINK: https://fedoraproject.org/wiki/Docs_QA_Procedure (bcotton,
14:29:44)
* Open floor discussion (bcotton, 14:52:01)
Meeting ended at 14:58:24 UTC.
Action Items
------------
* bcotton to draft QA Wrangler role description
* Sparks to follow up to mailing list about using koji to publish
docs.fp.o
* Sparks to take man page website to mailing list
Action Items, by person
-----------------------
* bcotton
* bcotton to draft QA Wrangler role description
* Sparks
* Sparks to follow up to mailing list about using koji to publish
docs.fp.o
* Sparks to take man page website to mailing list
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* bcotton (53)
* Sparks (24)
* lnovich1 (13)
* mprpic (10)
* lnovich (7)
* daydrim (5)
* pkovar (5)
* sgordon (3)
* zodbot (3)
* jhradilek (3)
* _logan (1)
* ianweller (1)
* jjmcd (1)
* jsmith (1)
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.20...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.20...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-18/fedora_docs.20...
--
Ben Cotton
Fedora Docs Leader
11 years, 10 months
- 1
- 0
Cloud SIG Meeting Minutes :: 2012-06-15
by Robyn Bergeron
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012...
Logs:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012...
==========================
#fedora-meeting: Cloud SIG
==========================
Meeting started by rbergeron at 19:00:13 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/cloud_sig.2012...
.
Meeting summary
---------------
* Roll Call, yo! (rbergeron, 19:00:28)
* gholms, tdawson, mdomsch, jzb, mrunge (if you're here for cloud, if
not, Hi!) present (rbergeron, 19:03:05)
* Features! Who's got em (rbergeron, 19:04:36)
* Feature submission deadline is 2012-07-24; Feature Freeze is
2012-08-07 (rbergeron, 19:05:31)
* Euca will be shooting for F18 (rbergeron, 19:05:58)
* hoping for CS as well. (rbergeron, 19:07:14)
* LINK: https://fedoraproject.org/wiki/Features/OpenShift_Origin
(rbergeron, 19:09:10)
* rubygem-passenger review stalled on licensing questions (gholms,
19:10:11)
* but OSO is still optimistic about F18 :) which is good! (rbergeron,
19:12:42)
* russellb mentions that pbrady has said that he was going to start
work on a folsom feature page for F18 (rbergeron, 19:14:57)
* Cloud SIG FAD (rbergeron, 19:16:19)
* Cloud Interop FAD is the idea - taking things like openstack,
eucalyptus, etc. that are in or going to be in fedora, and then also
things like plans to have openshift in fedora (rbergeron, 19:26:05)
* and then combining the two (rbergeron, 19:26:17)
* LINK:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/C...
(rbergeron, 19:49:10)
* Open Floor (rbergeron, 19:52:52)
Meeting ended at 19:57:55 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* rbergeron (157)
* gholms (61)
* tdawson (24)
* jzb (13)
* ke4qqq (7)
* agrimm (6)
* russellb (4)
* zodbot (4)
* jsmith (3)
* mrunge (2)
* mdomsch (1)
* apevec (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 10 months
- 1
- 0
Summary/Minutes from todays EPEL sig meeting (2012-06-15)
by Kevin Fenzi
==================================
#fedora-meeting: EPEL (2012-06-15)
==================================
Meeting started by nirik at 16:00:08 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-15/epel.2012-06-1...
.
Meeting summary
---------------
* init process/agenda (nirik, 16:00:08)
* broken deps script for epel6 that needs to be cleaned up:
http://fedorapeople.org/~kevin/epel-deps/spam-o-matic-el6 (nirik,
16:03:45)
* Overlapping with RHEL (part 10) (nirik, 16:04:34)
* LINK: http://vault.centos.org/6.2/os/Source/SPackages/ (Jeff_S,
16:25:09)
* LINK: http://www.redhat.com/products/enterprise-linux-add-ons/
(abadger1999, 16:32:22)
* LINK:
http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
). (nirik, 16:35:04)
* Open Floor (nirik, 16:42:14)
Meeting ended at 16:45:47 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (66)
* Jeff_S (24)
* abadger1999 (18)
* smooge (14)
* rbergeron (8)
* zodbot (4)
* dgilmore (2)
* jzb (1)
* tremble (0)
--
16:00:08 <nirik> #startmeeting EPEL (2012-06-15)
16:00:08 <zodbot> Meeting started Fri Jun 15 16:00:08 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:08 <nirik> #meetingname epel
16:00:08 <zodbot> The meeting name has been set to 'epel'
16:00:08 <nirik> #topic init process/agenda
16:00:08 <nirik> #chair smooge tremble dgilmore
16:00:08 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan
16:00:08 <zodbot> Current chairs: dgilmore nirik smooge tremble
16:00:12 <smooge> here
16:00:19 <nirik> who all is around for a epel meeting? :)
16:00:59 <Jeff_S> .
16:01:10 <Jeff_S> I'd like to be a table since we have four chairs already
16:02:08 <nirik> ha
16:02:19 * abadger1999 here
16:03:12 <nirik> who all has topics? I assume we will poke more at the overlap issue as we always do. ;)
16:03:31 <Jeff_S> nothing else here...
16:03:45 <nirik> #info broken deps script for epel6 that needs to be cleaned up: http://fedorapeople.org/~kevin/epel-deps/spam-o-matic-el6
16:04:34 <nirik> #topic Overlapping with RHEL (part 10)
16:04:51 <nirik> so, where were we on this? abadger1999 sent a proposal to the list...
16:05:21 <nirik> there was a bunch of discussion.
16:05:56 <nirik> much of it was from what is a 'basic subscription.
16:06:52 <abadger1999> I think people on list disputed what went into "Basic Subscription", whether there's additional cost involved with addons, and whether we could/should split on Addons vs channels instead of basic subscription.
16:06:59 <nirik> and some was things that seemed to go much more high level and just confused me. ;)
16:07:05 <nirik> yeah
16:07:57 <nirik> perhaps we could try and answer those questions via talking with Red Hat support folks.
16:08:17 <smooge> I think we keep it simple and say we have /en/os and we added two extra channels. If people have a problem iwth that then EPEL is not the project for them.
16:09:37 * nirik re-reads thread
16:11:12 <nirik> smooge: I agree that would be easiest.
16:12:29 <nirik> so, I think the 'base subscription' thing is just not going to help us any... perhaps we should drop trying to use that.
16:12:50 <smooge> yeah. It looks like it depends on when, who and what was bought.
16:13:28 <abadger1999> <nod>
16:14:15 <nirik> dgilmore: any more luck finding channel owners? or thats all unknown still?
16:14:18 <rbergeron> (is this still loosely about the puppet thing?)
16:14:25 <nirik> rbergeron: somewhat.
16:14:27 <Jeff_S> and centos includes more than "/en/os and we added two extra channels."?
16:14:30 <dgilmore> nirik: still unknown
16:14:36 * rbergeron is happy to help run people down
16:14:37 <rbergeron> or chase down
16:14:44 <rbergeron> i suppose running down sounds pretty bad :)
16:14:44 <nirik> rbergeron: it's about what epel will allow in it's repo.
16:14:51 <rbergeron> nirik: yeah, i got that part :)
16:14:52 * Jeff_S pictures rbergeron in her car running down channel owners
16:15:14 <nirik> the problem is we can't just say "nothing thats in RHEL'
16:15:24 <nirik> because there are eleventy gillion channels.
16:15:45 <smooge> Jeff_S, well what is in CentOS these days not counting Extras and such
16:16:25 <Jeff_S> smooge: not counting extras, correct. I think it's important to consider centos users as well. IMO more important than RHEL (yes, I said that!)
16:16:25 <rbergeron> is there a list of specific owners you're looking for or just "general list, whateve ryou can find"
16:17:40 <nirik> rbergeron: one of the thoughts was that we do 'nothing in base os/optional/lb/ha and if a channel owner of another channel requested it, we could add their channel packages to the list of 'don't ship these''
16:18:07 <nirik> but for that to work channel owners would need to communicate with us and say "please don't ship channel-foobar packages in epel'
16:18:36 <rbergeron> okay
16:18:51 <rbergeron> dgilmore: is your list at 0 or started?
16:19:49 <nirik> this would mean channel owners could be disruptive if they started shipping a bunch of stuff epel users use and then asked us to stop shipping them, but I would hope they would be reasonable.
16:20:33 <dgilmore> rbergeron: ive been talking to stickster_afk
16:20:46 <Jeff_S> nirik: I don't think we could have a policy that puts channel owners in charge of what we ship. But we surely should consider their requests when reasonable
16:21:12 <nirik> Jeff_S: sure. I guess I was thinking case by case...
16:21:18 <Jeff_S> +1
16:21:20 <nirik> I don't think anyone wants to cause problems for others...
16:21:26 <Jeff_S> nirik: maybe just some people ;)
16:21:41 <nirik> at least I hope we can minimize problems caused by epel for both rhel and other distros.
16:22:12 <smooge> Jeff_S, my question was what is in Centos Core for 6 and how does it overlap with RHEL .. eg is it built out of just /en/os or does it pull in other channels.
16:22:49 <nirik> so, how about this: we rephrase the proposed thing to drop mentions of 'base subscription' and ask on list if anyone has better proposals if they don't like that one.
16:22:59 <Jeff_S> smooge: it's built out of everything that's shared publicly on ftp.redhat AFAIK. let me see if I can get a better definition
16:23:14 <nirik> Jeff_S: that would include a number of channels then...
16:23:19 <Jeff_S> indeed
16:23:38 <nirik> and things like puppet, mongodb, etc that are shipped by epel too. ;)
16:23:46 <Jeff_S> do we have numbers on what part of our user and/or developer base are using centos vs. rhel?
16:23:47 <abadger1999> I'd be interested in knowing if there's any thought about Addons vs other channels inside of RH. Are addons more stable/won't conflict with each other/have other characteristics that other channels don't?
16:23:50 * Jeff_S thinks not
16:23:51 <smooge> and stuff that conflicts within those channels :)
16:23:55 * nirik again wonders why there's been no complaints over the last year if overlaps are so common.
16:24:22 <nirik> abadger1999: I know some of the add ons ship the same packages... so they do overlap
16:24:29 <smooge> Jeff_S, no we don't. Unless CentOS starts shipping smolt or something :)
16:24:41 <Jeff_S> smooge: god(s) help us
16:24:47 <abadger1999> <nod> -- did we figure out if those are presently all the same versions, though?
16:25:09 <Jeff_S> http://vault.centos.org/6.2/os/Source/SPackages/
16:25:11 <nirik> abadger1999: the one case I saw they were.
16:25:19 <Jeff_S> nirik: no mongo there for example
16:25:22 <nirik> but not sure if that was deliberate or not.
16:25:33 <abadger1999> <nod>
16:25:42 <nirik> Jeff_S: yeah, so I wonder if it's not just base + optional
16:25:52 <Jeff_S> nirik: I'll verify that and post to the list
16:25:59 <nirik> cool. that would be great
16:26:50 <nirik> abadger1999: would you be willing to try another proposal post? or would you like me to try?
16:26:59 <abadger1999> rpm --changelog might tell us.
16:27:16 <Jeff_S> abadger1999: hmm?
16:27:35 <abadger1999> (at leaset, if those packages in different addons had separate maintainers or not.)
16:28:30 <abadger1999> nirik: You can if you like.
16:28:38 <Jeff_S> :)
16:28:39 <nirik> sure, can try.
16:28:46 <abadger1999> I'd be okay with smooge's proposal.
16:29:10 <abadger1999> I'd be okay trying to s/Basic Subscription/Addons/
16:29:40 <abadger1999> and see if people point out that Addons won't work either :-)
16:30:46 <smooge> well there are too many addons now..
16:30:48 <nirik> yeah, it seemed it was unclear who got addons.
16:30:57 <nirik> and the addons confict with each other
16:31:15 <abadger1999> There's 6 addons listed on that page.
16:32:15 <Jeff_S> abadger1999: which page?
16:32:22 <abadger1999> http://www.redhat.com/products/enterprise-linux-add-ons/
16:32:32 <Jeff_S> thanks
16:32:42 * abadger1999 not counting the extended lifecycle ones
16:34:19 <Jeff_S> all the marketing hurts my eyes
16:34:56 <nirik> ok, hows this:
16:34:58 <jzb> Jeff_S: it's sort of like an eclipse, you're not supposed to look directly at it.
16:35:02 <Jeff_S> lol
16:35:02 <nirik> "EPEL6 will not normally ship packages that are shipped already in the
16:35:03 <nirik> following RHEL channels: os, optional, lb, and ha. Any overlapping
16:35:03 <nirik> packages must be to provide binary packages on arches not provided by
16:35:03 <nirik> RHEL ( following:
16:35:04 <nirik> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ).
16:35:06 <nirik> Additional channels may be added to the above list on a case by case
16:35:08 <nirik> basis. "
16:35:58 <Jeff_S> seems like a reasonable start to me
16:36:01 <abadger1999> I'm not in love with it because there's no expectation of what may or may not be added in that.
16:36:16 <nirik> yeah, thats true.
16:36:26 <abadger1999> But I'd be okay with it since it basically starts us with what we want to do now.
16:36:55 <nirik> we could drop the last sentence, and just continue to discuss adding critera.
16:38:11 <nirik> or change it to "additional channels could be added based on a critera we have yet to decide." :)
16:38:53 <abadger1999> +1 to the second wording.
16:39:16 <nirik> at least then people know it's still being discussed and they could provide input on the method. ;)
16:41:19 <nirik> ok, I can send that out for more comment.
16:41:25 <nirik> anything else on this?
16:42:00 <smooge> not from me.
16:42:14 <nirik> #topic Open Floor
16:42:20 <nirik> anything for open floor?
16:42:22 <smooge> I just want to get done with this and move back to making packages versus argueing over the color and floorsize of my bikeshed
16:42:33 <smooge> I will have mediawiki119 out this weekend I hope
16:42:45 <smooge> I will also be end of lifing all mediawiki's before then
16:43:02 <nirik> smooge: cool. ;)
16:43:33 <nirik> oh, another FYI, I will be not here for the next two meetings... someone else could run them, or we could just skip them. Either way is fine with me. ;)
16:44:19 <smooge> I can run them
16:44:43 <nirik> smooge: cool.
16:44:43 <smooge> if we miss one we may never start again :)
16:44:56 <nirik> yeah, we are bad about that. ;)
16:45:03 <nirik> ok, if nothing else will close out the meeting in a minute.
16:45:44 <nirik> thanks for coming everyone
16:45:47 <nirik> #endmeeting
11 years, 10 months
- 1
- 0
Summary/Minutes from today's Fedora infrastructure meeting (2012-06-14 at 18UTC)
by Kevin Fenzi
============================================
#fedora-meeting: Infrastructure (2012-06-14)
============================================
Meeting started by nirik at 18:00:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-14/infrastructure...
.
Meeting summary
---------------
* Good morning Fedora (nirik, 18:00:01)
* New folks introductions and Apprentice tasks. (nirik, 18:01:34)
* LINK: http://fedoraproject.org/easyfix/ (nirik, 18:03:58)
* Applications status / discussion (nirik, 18:07:20)
* Sysadmin status / discussion (nirik, 18:14:05)
* LINK: https:// doesnt work well on port 80 (dgilmore, 18:14:26)
* assistance with s3 mirroring welcome. (nirik, 18:25:26)
* help welcome to track down managed-keys dns warnings (nirik,
18:27:11)
* epylog named module welcome to parse named logs. (nirik, 18:29:22)
* FAD ? (nirik, 18:29:53)
* ACTION: nirik will make a web page to collect possible attendees,
flight costs and location / time prefs. (nirik, 18:37:54)
* Upcoming Tasks/Items (nirik, 18:38:14)
* Upcoming Tasks/Items (nirik, 18:38:23)
* 2012-06-18 remove people with pkgdb bugzilla issues. (nirik,
18:38:24)
* 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. (nirik,
18:38:24)
* 2012-06-26 Fedora 15 end of life. (nirik, 18:38:24)
* 2012-06-28 Seth at jury duty. (nirik, 18:38:24)
* 2012-07-05 nag fi-apprentices (nirik, 18:38:24)
* 2012-07-12 drop inactive apprentices. (nirik, 18:38:26)
* 2012-08-07 to 2012-08-21 F18 Alpha Freeze (nirik, 18:38:28)
* 2012-08-21 F18 Alpha release. (nirik, 18:38:30)
* Upcoming Tasks/Items (nirik, 18:39:30)
* 2012-06-18 remove people with pkgdb bugzilla issues. (nirik,
18:39:30)
* 2012-06-21 to 2012-07-04 Kevin is off on trains and boats. (nirik,
18:39:30)
* 2012-06-26 Fedora 15 end of life. (nirik, 18:39:30)
* 2012-06-28 Seth at jury duty. (nirik, 18:39:30)
* 2012-07-05 nag fi-apprentices (nirik, 18:39:30)
* 2012-07-12 drop inactive apprentices. (nirik, 18:39:32)
* 2012-08-07 to 2012-08-21 F18 Alpha Freeze (nirik, 18:39:34)
* 2012-08-21 F18 Alpha release. (nirik, 18:39:36)
* Open Floor (nirik, 18:45:16)
* cgit? (nirik, 18:50:42)
* http::websites (nirik, 18:57:51)
* iptables folks welcome to help with iptables revamp (nirik,
19:07:20)
* Open Floor (^2) (nirik, 19:07:37)
Meeting ended at 19:12:09 UTC.
Action Items
------------
* nirik will make a web page to collect possible attendees, flight costs
and location / time prefs.
Action Items, by person
-----------------------
* nirik
* nirik will make a web page to collect possible attendees, flight
costs and location / time prefs.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* nirik (154)
* skvidal (114)
* mdomsch (28)
* abadger1999 (13)
* pingou (13)
* ingm4r (12)
* sdrfed17 (9)
* relrod (5)
* zodbot (4)
* dgilmore (4)
* lmacken (3)
* sumitrai (2)
* misc (2)
* rossdylan (2)
* threebean (1)
* striker|rh (1)
* smooge (0)
* ricky (0)
* CodeBlock (0)
--
18:00:00 <nirik> #startmeeting Infrastructure (2012-06-14)
18:00:00 <zodbot> Meeting started Thu Jun 14 18:00:00 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <nirik> #meetingname infrastructure
18:00:01 <zodbot> The meeting name has been set to 'infrastructure'
18:00:01 <nirik> #topic Good morning Fedora
18:00:01 <nirik> #chair smooge skvidal CodeBlock ricky nirik abadger1999 lmacken dgilmore mdomsch threebean
18:00:01 <zodbot> Current chairs: CodeBlock abadger1999 dgilmore lmacken mdomsch nirik ricky skvidal smooge threebean
18:00:11 * mdomsch is here
18:00:20 <nirik> who all is around for a exciting, thrilling, wonderous, fedora infrastructure meeting?
18:00:21 * skvidal is
18:00:23 * lmacken
18:00:27 * rossdylan is here
18:00:28 * ingm4r is
18:00:31 * threebean is here
18:00:48 <sdrfed17> Hi Team. I am Sudhir Menon from India (irc:sdrfed17). with 3yrs of experience in Linux Sys Administration and QA. Would like to contribute to Infrastructure Group.
18:01:02 <nirik> welcome sdrfed17
18:01:28 * ingm4r would like to join the team, too
18:01:33 <sdrfed17> thankyou nirik
18:01:34 <nirik> #topic New folks introductions and Apprentice tasks.
18:01:35 <nirik> If any new folks want to give a quick one line bio or any apprentices
18:01:35 <nirik> would like to ask general questions, they can do so now. Anyone?
18:01:56 <sumitrai> Hi everone I am sumit rai from India, (irc: sumitrai), I have RHCSA, and I would love to be a part of fedora community
18:01:57 <nirik> sdrfed17 / ingm4r: were you more interested in sysadmin tasks? or application development?
18:02:16 <sdrfed17> sysadmin task niik
18:02:41 <ingm4r> Short Line from me: My name is Ingmar (I'm from Germany), I'm working as a Sysadmin since ~5 years
18:02:55 <nirik> excellent. Lots of new folks today. ;)
18:03:02 <ingm4r> so I\m interested in sysadmin tasks, too :)
18:03:02 <sdrfed17> sysadmin task is the thing that i am more interested in, would also like to have my hands on application development as well
18:03:23 <sumitrai> I am interested in sysadmin task too.
18:03:26 <nirik> For the sysadmin side of things, take a look at https://fedoraproject.org/wiki/Infrastructure_Apprentice and if that sounds of interest to you, I can set you up after the meeting (see me in #fedora-admin)
18:03:49 <nirik> for application development, we have a number of apps we work on, and there's a list of easyfix items to look at:
18:03:58 <nirik> http://fedoraproject.org/easyfix/
18:04:58 <nirik> so, we can get you all setup after the meeting. ;)
18:05:06 <nirik> any general questions right now?
18:05:15 <ingm4r> will do nirik
18:05:21 <ingm4r> not yet :)
18:05:40 <sdrfed17> looks good to me the apprentice part
18:05:42 <sdrfed17> nirik
18:06:27 <nirik> great. I can get you setup after the meeting. ;)
18:06:41 <ingm4r> that would be fine.
18:06:41 <nirik> do chime in with questions and comments as they come to you, and again welcome.
18:07:15 <sdrfed17> thank you we will be joining you @ fedora-admin after this meeting
18:07:20 <nirik> #topic Applications status / discussion
18:07:36 <nirik> abadger1999 / threebean / lmacken / pingou / relrod: any application news this week?
18:08:05 <abadger1999> nirik: Sorta sysadminy -- we're about to retire app01.dev :-)
18:08:06 <lmacken> nothing exciting
18:08:17 <nirik> abadger1999: hurray.
18:08:19 <abadger1999> the apps that were being tested on it have moved to pkgdb01.dev and fas01.dev
18:08:46 <nirik> is everyone happy with how staging works these days? is it better than when we had a staging branch?
18:08:46 <abadger1999> in the process, I updated them to use passwordless sudo and made the login/sudo group the commit group for the applications
18:09:05 <abadger1999> which were things we'd talked about migrating our dev boxes to do.
18:09:09 <abadger1999> Seems to be working out fine.
18:09:28 <pingou> worked a bit on HK and our student seems to make some progress as well
18:09:34 <nirik> we did have a upgrade to koji this week. ;)
18:09:46 <pingou> nirik: btw, what about python-bz ? any news ?
18:09:48 <nirik> pingou: cool.
18:09:57 <abadger1999> I think lmacken hit his first stg-was-nonintuitive issue this week (or last week)
18:10:17 <dgilmore> nirik: i have found one bug in koji i need to get fixed
18:10:31 <abadger1999> someone else had added an explicit stg module for something and then we couldn't figure out why committing to master wasn't showing up on stg.
18:10:40 <abadger1999> (in the modules/ directory)
18:10:47 <lmacken> abadger1999: yup, that was confusing at first.
18:10:59 <nirik> pingou: there is a 0.7.0 version. We should retest our stuff with it.
18:11:01 <abadger1999> Not sure if we can do anything about that except remember to check for that.
18:11:09 <nirik> abadger1999: ah yeah. I wonder if there's anything we can do about that... .
18:11:39 <pingou> nirik: release?
18:11:41 <pingou> in testing ?
18:12:06 <nirik> pingou: packages in fedora updates-testing. Looks like it's not been built for epel yet.
18:12:14 <pingou> ok
18:12:21 * pingou notes this on his todo
18:12:22 <nirik> I can do a scratch build if anyone wants
18:13:00 <nirik> ok, cool.
18:13:10 <nirik> dgilmore: what was the bug? in login?
18:14:05 <nirik> #topic Sysadmin status / discussion
18:14:06 <dgilmore> nirik: yeah the web login issue
18:14:15 <dgilmore> its adding a :80 to the url
18:14:24 <nirik> I thought I'd add a section about what sysadminy things we have done over the last week too.
18:14:26 <dgilmore> https:// doesnt work well on port 80
18:14:29 <nirik> dgilmore: ah, bummer. ;(
18:14:43 <nirik> we just finished last night a mass reboot... so everything should be up to date.
18:15:05 <nirik> skvidal revamped out dns this week. :) Please read the readme in the dns repo
18:15:26 <skvidal> if anyone wants to updats our dns SOP
18:15:28 <mdomsch> skvidal: that's huge
18:15:37 <skvidal> to point to the readme in the dns git repo
18:15:38 <mdomsch> thanks for your effort there
18:15:40 <skvidal> please feel free
18:15:52 <skvidal> mdomsch: thanks for that - I hope it will make us all less pained when it comes to proxy time
18:15:54 * nirik can do that.
18:15:59 <skvidal> s/proxy/proxy rotation/
18:16:04 <nirik> yeah, I think it's less error prone for proxys.
18:16:10 <nirik> thanks for working on it skvidal
18:16:13 <skvidal> and it should be less error prone in general
18:16:21 <skvidal> it is VERY hard to get an invalid zone file past it
18:16:36 <skvidal> I hope
18:16:37 <skvidal> :)
18:16:41 <nirik> we also wiped out community01.dev and made a packages01.stg, which I think is mostly working now.
18:16:52 <mdomsch> I've got the S3 mirrors functional in 3 zones now (us-east-1, us-west-1, and us-west-2)
18:16:55 <nirik> yeah, which is something that had happened to us in the past. ;(
18:17:11 <mdomsch> and spent another few nights trying to beat hardlink handling into s3cmd sync
18:17:38 <nirik> mdomsch: any luck with that?
18:17:41 <mdomsch> once that's working, need to parallelize it on 2 dimensions: 1) multiple uploads per upload target
18:17:56 <mdomsch> 2) scan the local file system once, then multiple upload targets in parallel
18:18:06 <mdomsch> as it stands, we're beating the crap out of the netapps on every sync
18:18:18 <mdomsch> as it calculates md5sums on each file before checking in with S3 to see if it has it
18:18:46 <mdomsch> which is the last thing it needs right now - local tree md5sum caching
18:18:53 <nirik> perhaps we could pregenerate that? or get it from the repodata?
18:19:02 <nirik> does it have to be md5?
18:19:20 <mdomsch> unfortunately, yes, md5 only. S3 returns that as the ETAG
18:19:35 <skvidal> mdomsch: can you generate an md5sum file and go off of datestamp?
18:19:49 <skvidal> mdomsch: b/c datestamp should be a simple stat() hit and not a full file read like md5sum
18:19:54 <mdomsch> though I did just add stashing the md5 in the S3 per-file metadata, so could conceivably add another hash type
18:20:18 <skvidal> mdomsch: then you can assume the md5sum is the same, if the datestamp on the file is older than the last time you ran
18:20:33 <skvidal> (unless someone intentionally set the file mtime/ctime back)
18:21:01 <mdomsch> maybe....
18:21:11 <mdomsch> definitely open to ideas to speed things up
18:21:39 <mdomsch> problem is, mtime/ctime is an easy stat() call locally, but it requires a full HTTP HEAD call for each target remote
18:21:48 <skvidal> mdomsch: you don't need to compare it to remote
18:21:48 <mdomsch> to get it out of the metadata
18:21:54 <skvidal> mdomsch: you just compare it to the last time you ran
18:21:57 <mdomsch> MD5 we get "for free" from the bucket list command
18:22:12 <skvidal> any file with a timestamp > than the last time you ran
18:22:15 <skvidal> you take an md5 of
18:22:25 <skvidal> s/file/local file/
18:22:31 <skvidal> that way you're not hitting EVERY file on the netapp
18:22:38 <skvidal> only those newer than the last execution of your script
18:22:40 <mdomsch> skvidal: ah, yes
18:22:45 <skvidal> and when you're done
18:22:50 <skvidal> you store the md5sum of that file
18:22:56 <skvidal> so - if you need it for any reason
18:22:58 <skvidal> you have it
18:23:05 <mdomsch> yes, that's completely feasible
18:23:05 <skvidal> w/o rereading it from the file itself
18:23:47 <nirik> yeah
18:23:52 <mdomsch> that's exactly in line with what I was thinking
18:24:30 <skvidal> cool
18:24:31 <nirik> cool. Sounds like a number of optimizations possible...
18:24:40 <nirik> ok, moving on?
18:24:46 <mdomsch> so, if there are any new folks
18:24:49 <mdomsch> apprentices etc
18:24:59 <mdomsch> who know python and have time to monkey with it
18:25:06 <mdomsch> I'm very open to the help...
18:25:13 <nirik> excellent.
18:25:26 <nirik> #info assistance with s3 mirroring welcome.
18:25:39 <nirik> any other sysadmin stuff to note from this last week?
18:26:18 <skvidal> the bind managed-keys crap?
18:26:27 <skvidal> if anyone is familiar with named and dnssec
18:26:47 <skvidal> and can figure out why on every startup named belches out that it cannot find some managed-keys in dynamic/<long string>
18:26:55 <skvidal> i would be OVERJOYED to see a solution
18:27:11 <nirik> #info help welcome to track down managed-keys dns warnings
18:27:11 <skvidal> grep for managed-keys in the messages log of any of the nameservers
18:27:13 <skvidal> and you can see
18:27:49 <nirik> yeah, it's an odd one. ;(
18:28:34 <skvidal> an named epylog module
18:28:37 <skvidal> if anyone wants to write one
18:28:47 <skvidal> I'm sure we'd be happy to be a tester of it
18:29:22 <nirik> #info epylog named module welcome to parse named logs.
18:29:33 * nirik should file some of these for apprentice folks. ;)
18:29:53 <nirik> #topic FAD ?
18:30:18 <nirik> So, I sent out an email the other day to judge interest in holding a FAD (Fedora Activity Day).
18:30:27 <nirik> sounds like there is some interest.
18:30:38 <nirik> we need to try and isolate place and time and see who all can make it.
18:30:40 <pingou> I bet there is :)
18:31:08 <nirik> so, what I might do is make a wiki page, and ask people to sign up there and note their place/time prefs.
18:31:24 <nirik> and possibly ballpark costs of flying them to place X or something.
18:31:46 <skvidal> nirik: you know - fudcon in paris - we could colocate a fad w/that
18:31:51 <nirik> anyone have any further thoughts/ideas on this? is security a good topic?
18:31:56 <pingou> skvidal: +1
18:31:56 <skvidal> nirik: I'm sure I could convince eunice that we need to go to paris in the fall.
18:32:07 <nirik> skvidal: ha. yeah!
18:32:16 <pingou> but we should still be able to do one before if we like
18:33:06 <pingou> we should be able to get a room there
18:33:10 <nirik> If folks know of spaces that would be very low cost/free for us to gather at, we could consider them too.
18:33:13 <mdomsch> doubtful I could attend or be of much value for a security-focused FAD
18:33:23 <skvidal> mdomsch: you're always useful
18:33:53 <mdomsch> I think security is too broad though. I'd like to see a "we will accomplish 1, 2, and with a lot of luck, 3, in 2 days"
18:34:05 <nirik> mdomsch: you're always welcome. ;)
18:34:06 <nirik> yeah...
18:34:10 <mdomsch> I love the ideas on the list so far
18:34:31 <mdomsch> just trim it down to something achievable with a few people who can Get It Done
18:34:53 * pingou wonders about a webapp component
18:34:53 <nirik> yeah, I listed a bunch of possible things...
18:34:58 <pingou> but then it would be 2 groups
18:35:07 <nirik> I think the list is too long to get done all at once there.
18:35:16 <abadger1999> nirik: Smooge had the idea of just getting two-factor auth done.
18:35:30 <abadger1999> That seemed like it was a good focus for a FAD.
18:35:34 <pingou> imho 2 factor should have the priority
18:35:43 <nirik> we might want to focus on things that we could either a) be confident of getting done, b) need to discuss in person more to come up with a plan.
18:35:47 <nirik> abadger1999: yeah.
18:37:06 <nirik> well, I will see about whipping up a web page where we can collect costs and time/place prefs.
18:37:16 <nirik> and we can narrow scope down
18:37:54 <nirik> #action nirik will make a web page to collect possible attendees, flight costs and location / time prefs.
18:38:14 <nirik> #topic Upcoming Tasks/Items
18:38:23 <nirik> #topic Upcoming Tasks/Items
18:38:24 <nirik> #topic 2012-06-18 remove people with pkgdb bugzilla issues.
18:38:24 <nirik> #topic 2012-06-21 to 2012-07-04 Kevin is off on trains and boats.
18:38:24 <nirik> #topic 2012-06-26 Fedora 15 end of life.
18:38:24 <nirik> #topic 2012-06-28 Seth at jury duty.
18:38:24 <nirik> #topic 2012-07-05 nag fi-apprentices
18:38:26 <nirik> #topic 2012-07-12 drop inactive apprentices.
18:38:28 <nirik> #topic 2012-08-07 to 2012-08-21 F18 Alpha Freeze
18:38:30 <nirik> #topic 2012-08-21 F18 Alpha release.
18:38:32 <nirik> ugh.
18:38:34 <nirik> misskey
18:38:36 <nirik> oh well.
18:38:38 <nirik> lots of topics. ;)
18:38:43 <nirik> (those were supposed to be infos)
18:38:49 <striker|rh> holy cow
18:39:01 <ingm4r> DOS...to get back into security :)
18:39:30 <nirik> #topic Upcoming Tasks/Items
18:39:30 <nirik> #info 2012-06-18 remove people with pkgdb bugzilla issues.
18:39:30 <nirik> #info 2012-06-21 to 2012-07-04 Kevin is off on trains and boats.
18:39:30 <nirik> #info 2012-06-26 Fedora 15 end of life.
18:39:30 <nirik> #info 2012-06-28 Seth at jury duty.
18:39:30 <nirik> #info 2012-07-05 nag fi-apprentices
18:39:32 <nirik> #info 2012-07-12 drop inactive apprentices.
18:39:34 <nirik> #info 2012-08-07 to 2012-08-21 F18 Alpha Freeze
18:39:36 <nirik> #info 2012-08-21 F18 Alpha release.
18:39:46 <nirik> anyhow, as noted there, I will be gone the next two meetings. ;)
18:40:06 <nirik> if anyone needs anything from me, please ask me to do it before next thursday.
18:40:18 <skvidal> nirik: I need you to not be gone, kthx
18:40:23 <skvidal> nirik: :)
18:40:30 <nirik> does anyone have any other upcoming tasks or things they would like to note on the schedule?
18:40:49 <nirik> skvidal: working on it. ;) Looking forward to be sitting on the train reading a book looking out the window. ;)
18:41:32 <skvidal> hrmph
18:41:36 <nirik> Oh, our private cloud hardware is supposedly in the datacenter somewhere. We just need it to be located and racked and wired and we can start setting it up.
18:41:44 <skvidal> nirik: and the networking setup
18:42:08 <nirik> yeah.
18:42:21 <nirik> I'm not sure if thats just one switch or two.
18:42:44 <skvidal> and of course whatever it means for ips
18:42:56 <nirik> yeah. we do have an external class C ready for this. ;)
18:43:22 <relrod> sorry, wayyyyy late, but I'm here.
18:43:31 <nirik> oh, also, we are hopefully getting a osuosl02 box... will be good to have 2 machines there so we can HA them or whatever we need.
18:45:16 <nirik> #topic Open Floor
18:45:26 <nirik> any questions, comments, ideas for open floor/
18:46:10 <relrod> well since I missed the app discussion, quick update on fedorahosted automation app stuff
18:46:18 <rossdylan> Fedora badges is coming along pretty well, working on building the nessicary rpm's of the python modules i have been working on
18:46:31 <nirik> relrod: sure...
18:46:35 <nirik> rossdylan: cool.
18:47:20 * nirik noted the ubuntu badges thing thats incompatible with open badges had a 0.2 release the other day.
18:47:46 <relrod> The web side of the fedorahosted automation app is pretty much done, and the CLI I'd say is 75% done. The CLI (at least to the point where I can test it locally) can fully process git requests and Hg requests. I need to get it processing bzr and svn.
18:48:33 <nirik> relrod: how much pain would it be if we had a hosted-agilo01 instance that was just for projects that needed agilo trac plugin/
18:48:33 <relrod> Flask still isn't packaged for el6 yet though. The maintainer is having some issues with the Flask tests not passing on el6
18:49:23 <nirik> ah
18:49:38 <relrod> nirik: Probably not too much pain, you'd just run the CLI on -agilo01 instead of hostedXX
18:49:46 <nirik> ok
18:50:22 <skvidal> item: cgit vs gitweb-caching?
18:50:40 <skvidal> did we come to a conclusion there?
18:50:42 <nirik> #topic cgit?
18:51:05 <nirik> not that I know of. I was going to ask gnome.org folks what they thought of cgit (since they use it there)
18:51:13 <nirik> but I didn't get around to it.
18:51:22 <skvidal> I got an internal email
18:51:25 <skvidal> on the subject
18:51:27 <skvidal> which said
18:51:39 <skvidal> 'cgit is much better'
18:51:42 <skvidal> (more or less)
18:51:51 <nirik> yeah... from looking it seems that way to me.
18:52:04 <nirik> so, I'm fine moving to it.
18:52:17 <nirik> the main downside is broken links.
18:52:20 <abadger1999> +1 for cgit from me.
18:52:24 <nirik> but there's some redirect rules that could help.
18:52:41 <abadger1999> But I've never been as concerned about the broken links as other people.
18:53:06 <nirik> yeah, it doesn't worry me overly. I don't think those links are used much...
18:53:14 <skvidal> abadger1999: I think I am inline with that now
18:53:17 <nirik> if someone hits an old bug with a gitweb link, too bad.
18:53:18 <skvidal> I used to worry about the links
18:53:20 <skvidal> but screw it
18:53:25 <skvidal> it's just how things fall down sometimes
18:54:10 <nirik> I'd be ok adding the redirects to try and make it somewhat nicer, or if we want just try and redirect all those gitweb things to a page that explains we are using cgit and how to search for what they were looking for.
18:54:56 <skvidal> worksforme
18:55:03 <skvidal> oh - I have another sysadmin-y task
18:55:04 <nirik> so, does someone want to lead this? if not, I can add it to my list. ;)
18:55:06 <skvidal> that is a touch herculean
18:55:17 * nirik notes we could test cgit on hosted01/02
18:55:32 <skvidal> nirik: might be easier to test cgit on fedorapeople
18:55:43 <skvidal> nirik: then again maybe those ~ repos will be tricky on fedorapeople
18:56:04 <nirik> there's also pkgs01.stg
18:56:11 <skvidal> nod
18:56:14 <nirik> anyhow, you had another topic?
18:56:30 <skvidal> yah
18:56:32 <skvidal> so
18:56:41 <skvidal> our httpd::websites, etc module in puppet
18:56:42 <skvidal> is
18:56:44 <skvidal> to say the least
18:56:45 <skvidal> complicated
18:56:57 <skvidal> a while back when we moved infra.fp.o to be standalone
18:57:04 <skvidal> I wrote a new httpd::site class
18:57:16 <skvidal> which simplifies how websites can be setup in puppet
18:57:20 <skvidal> it doesn't involve any templates
18:57:28 <skvidal> and makes me less likely to scream
18:57:43 <nirik> yeah, +1 on that
18:57:45 <skvidal> so
18:57:49 <skvidal> we need to move to that more
18:57:51 <nirik> #topic http::websites
18:58:01 <nirik> yeah, fine with me.
18:58:03 <skvidal> we need to convert sites over and whittle our way off of the other one
18:58:08 <skvidal> just takes people
18:58:17 <nirik> yeah.
18:58:26 <skvidal> another item that is on my todolist but...
18:58:28 <nirik> and getting puppet to do the right thing.
18:58:29 <skvidal> well it's a todolist from hell
18:58:38 <skvidal> iptables templates
18:59:08 <skvidal> my plan is to break iptables templates up into stg/prod templates
18:59:19 <skvidal> this separation is mainly to make sure we keep stg from talking to prod
18:59:40 <nirik> sure... and possibly "untrusted vpn" ?
18:59:41 <skvidal> the idea is for the template to use the heredoc trick
19:00:00 <skvidal> so we have a standard preamble
19:00:14 <skvidal> then if iptables.$iptables_group for that node exists - it gets include
19:00:23 <skvidal> and if iptables.$iptables_datacenter exists - that gets included
19:00:37 <skvidal> and if iptables.$fqdn exits - that gets included
19:00:45 <skvidal> (actually reverse the first two
19:00:49 <skvidal> datacenter, group, fqdn
19:01:01 <nirik> yep. just like the other sane places you already converted to that. ;)
19:01:13 <skvidal> so that we end up being able to add arbitrary rules, per host or per group of hosts (or per datacenter)
19:01:25 <skvidal> w/o having to deal with the defintion problem for iptables
19:01:30 <skvidal> that we deal with in puppet all the time
19:01:41 <skvidal> the other alternative, which I am not advocating but I am throwing out there
19:01:44 <nirik> right. so would we remove the custom rules from nodes then?
19:01:50 <skvidal> yes
19:01:58 <skvidal> we would remove custom rules from node files
19:02:01 <nirik> sounds good to me.
19:02:04 <skvidal> and put them in simple iptables <heredocs>
19:02:07 <skvidal> so the other alternative
19:02:10 <skvidal> that I want to mention
19:02:15 <skvidal> that the dns thing this week made me think about
19:02:35 <skvidal> we could setup iptables in templates - just the dns zone template
19:03:01 <skvidal> in a separate git repo, etc
19:03:11 <skvidal> construct per host and have puppet just run the update-iptables
19:03:15 <skvidal> which sucks down via git, etc
19:03:19 <skvidal> like I said
19:03:22 <skvidal> not advocating
19:03:24 <skvidal> just thinking about it
19:03:30 <nirik> we could, but we don't often change iptables and it doesn't have serial numbers and such... not sure it's worth it.
19:03:51 <skvidal> nod - thr advantage I was thinking of was being able to validate iptables
19:04:19 <skvidal> which is... difficult with the pieces of iptables we'd have to work with in puppet
19:04:33 <nirik> validating iptables in general is difficult. ;(
19:04:44 <skvidal> nirik: true
19:05:00 <misc> especially if you can have a valid iptables config that just block yourself :)
19:05:18 <nirik> I'm happy to simplify and split out what we have now tho for sure...
19:05:27 <nirik> since if you make a mistake now, it affects ALL machines.
19:05:30 <skvidal> the second advantage would be the speed at which we could deploy an iptable
19:05:34 <skvidal> change
19:06:20 <nirik> yeah, currently we don't update often... but there are use cases I suppose.
19:06:27 <skvidal> right
19:06:50 <skvidal> anyway it's something I'm going to be working on so I figured it would be worth mentioning it
19:06:58 <nirik> yeah, sounds good.
19:06:59 <skvidal> if anyone wants to work on it and is familiar with iptables - enjoy
19:07:20 <nirik> #info iptables folks welcome to help with iptables revamp
19:07:37 <nirik> #topic Open Floor (^2)
19:07:44 <skvidal> hah
19:07:48 <nirik> any other items for open floor or other questions, comments? ;)
19:08:19 <ingm4r> just a basic question, if thats ok
19:08:27 <nirik> ingm4r: sure, fire away
19:08:35 <ingm4r> stg ist staging and prd is productive?
19:08:44 <misc> production
19:08:53 <ingm4r> ok
19:09:27 <nirik> ingm4r: yeah...
19:09:42 <nirik> so we try and test things like new package versions and changes in our staging setup...
19:09:53 <nirik> then when they appear fine there, they go to production machines.
19:10:05 <ingm4r> jup, thought so. Just wanted to be sure about the naming.
19:10:16 <nirik> our staging setup is not a complete 1 to 1 mapping, but it has many copies of productions stuff.
19:10:26 <sdrfed17> nirik: so are apprentice guys allowed to work on both staging and production?
19:11:13 <nirik> sdrfed17: sure, the way it works is that apprentices can login to machines and check out a read only copy of our puppet repo... so any changes you make need to be sent throug someone that has commit access.
19:11:25 <nirik> so that way you can see how things are setup and propose patches for review.
19:11:55 <sdrfed17> nirik: ok
19:11:55 <nirik> anyhow, happy to discuss more over in #fedora-admin...
19:12:04 <nirik> we are over time, so lets go ahead and close out...
19:12:09 <nirik> #endmeeting
11 years, 10 months
- 1
- 0
Fedora Board Meeting Minutes 2012-06-13
by Christoph Wickert
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.2...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.2...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.2...
=====================================
#fedora-meeting: Fedora Board Meeting
=====================================
Meeting started by rbergeron at 18:30:31 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-13/fedora_board.2...
.
Meeting summary
---------------
* Who's around (rbergeron, 18:32:42)
* jreznik, ke4qqq, gholms, rbergeron, cwickert, abadger1999 present
(rbergeron, 18:33:13)
* LINK: http://fedoraproject.org/wiki/Board/History (rbergeron,
18:34:45)
* ACTION: rbergeron to leave pbrobinson in e5, move sparks into
rdieter's e3 spot (THANKS REX!), and jds2001 gets a hot dog in the
future for an extra week of hanging out ;) (rbergeron, 18:37:46)
* ACTION: and rbergeron to update wiki history of board seats
accordingly, and move folks into emeritus territory as necessary
(rbergeron, 18:38:08)
* Announcements (rbergeron, 18:38:14)
* There is currently a runoff election for the remaining board seat in
progress (rbergeron, 18:38:45)
* LINK:
http://lists.fedoraproject.org/pipermail/announce/2012-June/003085.html
(rbergeron, 18:38:50)
* see link for information on voting; election ends Wednesday, june 20
at 00:00:00 (which may be tuesday in your time zone, plz pay
attention) (rbergeron, 18:39:20)
* Open Q&A (rbergeron, 18:41:28)
* This is an open board meeting! We dedicate the first portion of this
meeting to answering your burning questions. If you have any, speak
up, and try to vaguely follow the protocol listed here:
http://fedoraproject.org/wiki/Board_public_IRC_meetings (rbergeron,
18:43:22)
* LINK: https://fedoraproject.org/wiki/Secureboot (nirik, 18:50:29)
* Discussion / questions on UEFI -
https://fedoraproject.org/wiki/Secureboot is a page nirik has set up
with some basic info, more info welcome (rbergeron, 18:51:08)
* (work in progress) SecureBoot feature page at
https://fedoraproject.org/wiki/User:Pjones/Features/SecureBoot
(pjones, 18:51:48)
* IDEA: have an IRC town hall for covering questions on
secureboot/uefi? (rbergeron, 18:52:04)
* Lots of discussion in logs, probably best that you, minutes-reader,
read the full log ;) (rbergeron, 18:53:48)
* Questions on election process (rbergeron, 19:06:01)
* ACTION: cwickert to draft a common nominations/elections wiki page
till next week (cwickert, 19:19:27)
* Update on Naming Stuff (rbergeron, 19:28:36)
* Naming meeting is Friday 2012-06-15 (this friday) at 17:00 UTC (1pm
EDT, 7pm CEST) in #fedora-meeting-1 (rbergeron, 19:33:51)
* results of doodle poll are at http://www.doodle.com/2y43y5vxxizsqyef
(rbergeron, 19:35:54)
* Meeting is open (rbergeron, 19:36:05)
* Open Floor (rbergeron, 19:48:38)
Meeting ended at 20:11:12 UTC.
Action Items
------------
* rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3
spot (THANKS REX!), and jds2001 gets a hot dog in the future for an
extra week of hanging out ;)
* and rbergeron to update wiki history of board seats accordingly, and
move folks into emeritus territory as necessary
* cwickert to draft a common nominations/elections wiki page till next
week
Action Items, by person
-----------------------
* cwickert
* cwickert to draft a common nominations/elections wiki page till next
week
* jds2001
* rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3
spot (THANKS REX!), and jds2001 gets a hot dog in the future for an
extra week of hanging out ;)
* rbergeron
* rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3
spot (THANKS REX!), and jds2001 gets a hot dog in the future for an
extra week of hanging out ;)
* and rbergeron to update wiki history of board seats accordingly, and
move folks into emeritus territory as necessary
* rdieter
* rbergeron to leave pbrobinson in e5, move sparks into rdieter's e3
spot (THANKS REX!), and jds2001 gets a hot dog in the future for an
extra week of hanging out ;)
* **UNASSIGNED**
* (none)
11 years, 10 months
- 1
- 0
Fwd: [KFI] Rangkuman Meeting 7 Juni 2012
by Prima Yogi Loviniltra
---------- Forwarded message ----------
From: Yonisman Blankxys <blank.xys(a)gmail.com>
Date: Fri, Jun 8, 2012 at 1:04 AM
Subject: [KFI] Rangkuman Meeting 7 Juni 2012
To: id-community(a)lists.fedoraproject.org
Assalamualaikum wr wb,
Berikut rangkuman meeting masih membahas FAD Padang,
Minutes :
http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-0...
Minutes (Text) :
http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-0...
Log :
http://meetbot.fedoraproject.org/fedora-id/2012-06-07/fedora-id.2012-06-0...
Wassalam,
_______________________________________________
Milis Komunitas Fedora Indonesia
id-community(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/id-community
--
*Best Regards,*
*PRIMA YOGI LOVINILTRA*
Fedora Contributor & Ambassadors
*Indonesian guy who live in and love Malaysia*
*M: (6)016 640 0385*
*W: *http://fedoraproject.org/wiki/User:Jurankdankkal
*B: **http://loviniltra.com/ <http://numoss.org/>**
*
11 years, 10 months
- 1
- 0
Fwd: Rangkuman Meeting 14 Juni 2012
by Prima Yogi Loviniltra
---------- Forwarded message ----------
From: Prima Yogi Loviniltra <prima.yogi(a)loviniltra.com>
Date: Fri, Jun 15, 2012 at 12:41 AM
Subject: Rangkuman Meeting 14 Juni 2012
To: Komunitas Fedora Indonesia <id-community(a)lists.fedoraproject.org>
Rangkuman Meeting 14 Juni 2012.
Masih persiapan FAD Padang yang bisa di bilang 60% kali yah,hehe.
Sayang bgt arifiauo DC tadi, saya mau menanyakan tentang kedatangan ke FAD
Padang ini.
Berikut rangkumannya :
Minutes:
http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-1...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-1...
Log:
http://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06-1...
==================
#fedora-id Meeting
==================
Meeting started by jurank_dankkal at 14:11:50 UTC. The full logs are
available athttp://meetbot.fedoraproject.org/fedora-id/2012-06-14/fedora-id.2012-06...
.
Meeting summary
---------------
* menentukan Physical Meeting FAD Padang (jurank_dankkal, 14:13:26)
* LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Meeting_Minutes
(jurank_dankkal, 14:17:50)
* IDEA: FAD Physical Meeting akan di adakan di gubuk inibudi dan di
gabung dgn gath IBT-S (jurank_dankkal, 14:33:51)
* ACTION: FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah
inibudi (jurank_dankkal, 14:44:22)
* Venue Confirmation (jurank_dankkal, 14:44:48)
* ACTION: jurank_dankkal akan mengirim proposal yang udah fix ke
blankxys dan inibudi (jurank_dankkal, 14:56:28)
* ACTION: FAD Padang akan di adakan di Gedung Graha Telkom Padang
(jurank_dankkal, 15:04:44)
* Speaker untuk FAD Padang (jurank_dankkal, 15:06:37)
* LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Schedule
(jurank_dankkal, 15:08:26)
* ACTION: hircus akan membuat ticket funding travel sebelum senin
(jurank_dankkal, 15:25:15)
* LINK: https://fedoraproject.org/wiki/FAD_Padang_2012#Schedule
(jurank_dankkal, 16:04:02)
* Tugas Promo Team (jurank_dankkal, 16:06:59)
* LINK: http://bit.ly/FADPadang2012 (jurank_dankkal, 16:11:46)
* ACTION: erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni
2012 (jurank_dankkal, 16:15:15)
* open floor (jurank_dankkal, 16:17:35)
Meeting ended at 16:25:08 UTC.
Action Items
------------
* FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah inibudi
* jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan
inibudi
* FAD Padang akan di adakan di Gedung Graha Telkom Padang
* hircus akan membuat ticket funding travel sebelum senin
* erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni 2012
Action Items, by person
-----------------------
* blankxys
* jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan
inibudi
* erdie1one
* erdie1one akan menyelesaikan banner sebelum Jumat, 15 Juni 2012
* hircus
* hircus akan membuat ticket funding travel sebelum senin
* inibudi
* FAD Physical Meeting, Jam 14.00, 17 Juni 2012 di rumah inibudi
* jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan
inibudi
* jurank_dankkal
* jurank_dankkal akan mengirim proposal yang udah fix ke blankxys dan
inibudi
* **UNASSIGNED**
* FAD Padang akan di adakan di Gedung Graha Telkom Padang
People Present (lines said)
---------------------------
* jurank_dankkal (217)
* hircus (64)
* blankxys (57)
* inibudi (48)
* betefive (44)
* zodbot (31)
* erdie1one (28)
* Qrinz (25)
* smart4rd1_ (18)
* H4nk (7)
* smart4rd1 (6)
* acenk90 (6)
* street (4)
* arifiauo (1)
--
*Best Regards,*
*PRIMA YOGI LOVINILTRA*
Fedora Contributor & Ambassadors
*Indonesian guy who live in and love Malaysia*
*M: (6)016 640 0385*
*W: *http://fedoraproject.org/wiki/User:Jurankdankkal
*B: **http://loviniltra.com/ <http://numoss.org/>**
*
--
*Best Regards,*
*PRIMA YOGI LOVINILTRA*
Fedora Contributor & Ambassadors
*Indonesian guy who live in and love Malaysia*
*M: (6)016 640 0385*
*W: *http://fedoraproject.org/wiki/User:Jurankdankkal
*B: **http://loviniltra.com/ <http://numoss.org/>**
*
11 years, 10 months
- 1
- 0