Summary/Minutes from today's FESCo meeting (2010-07-20)
Kevin Fenzi
kevin at scrye.com
Tue Jul 20 21:19:19 UTC 2010
===================================
#fedora-meeting: FESCO (2010-07-20)
===================================
Meeting started by nirik at 19:30:04 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-07-20/fesco.2010-07-20-19.30.log.html
Meeting summary
---------------
* init process (nirik, 19:30:04)
* kylem notting and mclasen indicated they would be unable to attend
today. (nirik, 19:30:50)
* ajax also unable to attend (nirik, 19:31:43)
* #351 Create a policy for updates - status report on implementation
(nirik, 19:34:51)
* #382 Implementing Stable Release Vision (nirik, 19:36:57)
* #409 Feature Request: GNUstep (nirik, 19:41:37)
* LINK: https://fedoraproject.org/wiki/Talk:Features/GNUstep has some
info (nirik, 19:42:38)
* Feature is approved. (nirik, 19:50:24)
* #423 F14Feature: GoldLinkerDefault -
http://fedoraproject.org/wiki/Features/GoldLinkerDefault (nirik,
19:50:33)
* will revisit later in the meeting hopefully with jlaw around.
(nirik, 19:52:35)
* #432 Add new FPL to fesco list (nirik, 19:52:46)
* AGREED: will re-add stickster for a bit. (nirik, 19:54:42)
* #439: dist-git rollout plan (nirik, 19:56:33)
* LINK: http://cvs.fedoraproject.org/webfiles/ (nirik, 20:13:26)
* AGREED: Go forth and GIT. Move forward at F14 branch time with a
migration. (nirik, 20:21:00)
* Till Maass unavailable (nirik, 20:21:39)
* #431 Exception for Recoll bundling other libraries modified (nirik,
20:26:21)
* AGREED: exception granted in this case. (nirik, 20:29:19)
* #433 F14Feature: CryptographyInKernel -
https://fedoraproject.org/wiki/Features/CryptographyInKernel (nirik,
20:29:26)
* AGREED: Feature is approved. (nirik, 20:37:51)
* #434 F14Feature - DNSSEC_on_workstations -
https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
(nirik, 20:38:32)
* will ask questions of feature owner and revisit next week. (nirik,
20:40:57)
* ACTION: mjg59 to ask for more input on this feature. (nirik,
20:43:08)
* #435 F14Feature: F14EclipseHelios -
https://fedoraproject.org/wiki/Features/F14EclipseHelios (nirik,
20:43:11)
* AGREED: Feature is approved. (nirik, 20:45:39)
* #436 F14Feature: KDE45 - https://fedoraproject.org/wiki/Features/KDE45
(nirik, 20:45:45)
* AGREED: Feature is approved. (nirik, 20:47:20)
* #437 F14Feature: MemoryDebuggingTools -
https://fedoraproject.org/wiki/Features/MemoryDebuggingTools (nirik,
20:47:27)
* AGREED: Feature is approved. (nirik, 20:49:22)
* #438 F14Feature: Ruby_1.87 -
https://fedoraproject.org/wiki/Features/Ruby_1.8.7 (nirik, 20:49:29)
* will gather more info and revisit next week. (nirik, 20:55:15)
* Open Floor (nirik, 20:56:03)
* LINK: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild
(dmalcolm, 20:57:15)
* Python 2.7 mass rebuild (nirik, 20:57:15)
* LINK: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild
(dmalcolm, 20:57:19)
* Open Floor (nirik, 21:14:49)
Meeting ended at 21:17:10 UTC.
--
19:30:04 <nirik> #startmeeting FESCO (2010-07-20)
19:30:04 <zodbot> Meeting started Tue Jul 20 19:30:04 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:04 <nirik> #meetingname fesco
19:30:04 <zodbot> The meeting name has been set to 'fesco'
19:30:04 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:04 <nirik> #topic init process
19:30:04 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:10 <mjg59> \o/
19:30:50 <nirik> #info kylem notting and mclasen indicated they would be unable to attend today.
19:31:02 <nirik> so, hopefully we still have quorum. ;)
19:31:14 <pjones> ajax is also out
19:31:27 <mjg59> Oops.
19:31:43 <SMParrish> I am here, but expecting a delivery soon so may have to jet for a few
19:31:43 <nirik> #info ajax also unable to attend
19:31:54 <nirik> so, we never everyone else...
19:32:14 * cwickert is sorry to be late
19:32:14 <pjones> we what?
19:32:22 <Oxf13> hrm. those are some of the key people I wanted around for the dist-git discussion.
19:33:10 <pjones> so right now it's nirik, smparrish, cwickert, mjg59, and pjones?
19:33:11 <nirik> pjones: in order for 5 of the 9 of us to be present.
19:33:39 <nirik> yep. Seems we do have 5 folks.
19:33:41 <cwickert> nirik: I can leave again if you want me to ;)
19:34:06 <pjones> smparrish only counts as half, right? since he's going to be gone soon anyway?
19:34:07 <Southern_Gentlem> yep you barely have a quorium (under roberts rules of order)
19:34:08 <nirik> cwickert: would make for a shorter meeting, but please do stay. ;)
19:34:11 <drago01> which means everyone has veto powers ;)
19:34:38 <pjones> Southern_Gentlem: we don't actually subscribe to robert's rules in any way...
19:34:42 <nirik> ok, lets go ahead and get started...
19:34:51 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:34:51 <nirik> .fesco 351
19:34:52 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:35:08 <nirik> so, we heard last week about a possible timeline for autoqa.
19:35:17 <nirik> Not sure how much more we can do on this until that lands...
19:35:34 <nirik> any general feedback on the critical path updates/proventesters?
19:35:39 <SMParrish> bah delivery is here brb
19:35:52 <nirik> I haven't heard too many complaints, but that could not mean much.
19:36:16 <pjones> yeah, it's been quiet.
19:36:54 <nirik> ok, will move on to next topic then...
19:36:57 <nirik> #topic #382 Implementing Stable Release Vision
19:36:57 <nirik> .fesco 382
19:37:01 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:37:15 <nirik> cwickert: if you don't have time, I could start that thread on the board list...
19:37:36 <nirik> notting is out this week.
19:37:53 <nirik> I sadly haven't added anything to https://fedoraproject.org/wiki/Updates_Lessons but plan on it still.
19:38:00 <cwickert> Kevin Fenzi: It's not the time but I haven't found the right words yet
19:38:36 <cwickert> and I think the board is busy with other important things like sustainable t-shirts and stuff..
19:38:44 <nirik> ha.
19:38:49 <pjones> ouch.
19:39:11 <nirik> well, I have some doubts about that clause too, so if you like I could start in on making a thread about it?
19:40:08 <cwickert> ok
19:40:45 <nirik> any more thoughts on this topic?
19:40:50 <cwickert> not atm
19:40:55 <nirik> I did see SMParrish added some data to the wiki on updates...
19:41:09 <pjones> oooh, oooh, let's move on to gnustep.
19:41:31 <nirik> ok. ;)
19:41:37 <nirik> #topic #409 Feature Request: GNUstep
19:41:38 <nirik> .fesco 409
19:41:39 <zodbot> nirik: #409 (Feature Request: GNUstep) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/409
19:42:27 <nirik> so, we wanted more info on this one.
19:42:38 <nirik> https://fedoraproject.org/wiki/Talk:Features/GNUstep has some info
19:43:02 <SMParrish> sorry bout that back now
19:43:24 <nirik> any further discussion on GNUStep? do we have the data we wanted.
19:43:42 <pjones> I'm trying to remember what the further info we asked for was.
19:43:57 <mjg59> Just what was actually being included
19:44:01 <nirik> well, basically I think we were wondering: if this has been in for ages, why is it a new feature?
19:44:11 <nirik> ie, whats new and exciting. ;)
19:44:11 <cwickert> pjones: look at the talk page
19:44:16 <pjones> cwickert: aha!
19:44:23 <mjg59> gnustep-back was missing. As far as I can tell, that means that it was impossible to produce a graphics gnustep app on Fedora.
19:44:31 <mjg59> graphical, rather
19:44:32 <cwickert> nirik: and this question still isn't answered I think
19:45:20 <cwickert> ok, graphical GNUstep, a single new package? the talk page just lists the packages we need, this info should be in the 'scope' section already
19:45:30 <pjones> so... man, I have trouble caring about this. sure, it's fine.
19:45:55 <mjg59> The description still needs fixing
19:46:09 <mjg59> Talking about Cocoa is just irrelevant
19:46:20 <pjones> that's really the big issue here, isn't it - it's hard to figure out what the feature is actually saying.
19:46:46 <cwickert> might be because Jochen is not necessarily the best English speaker I think
19:47:20 <cwickert> nevertheless he is a good packager
19:47:42 <pjones> yeah, I got that from the feature page as well.
19:47:46 <nirik> yeah, I guess I would say +1 on this, with the priviso that the page gets some revamp before release.
19:47:51 <mjg59> Significantly better than my German...
19:47:59 <nirik> ie, remove Cocoa, fill out what packages are in, etc.
19:48:03 <mjg59> Yeah, I'll try to remember to review it before final
19:48:20 <cwickert> and he should try to get more packages in, e.g. the gworkspace
19:49:16 <pjones> I'm +1 with similar caveats.
19:49:34 <mjg59> So, +1
19:49:45 <SMParrish> same here +1
19:49:50 <cwickert> +1
19:50:24 <nirik> #info Feature is approved.
19:50:33 <nirik> #topic #423 F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault
19:50:33 <nirik> .fesco 423
19:50:34 <zodbot> nirik: #423 (F14Feature: GoldLinkerDefault - http://fedoraproject.org/wiki/Features/GoldLinkerDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/423
19:50:42 <nirik> This is another one we wanted more info on.
19:51:25 <pjones> so, jlaw said he was going to try and be here for this, right?
19:51:41 <nirik> yeah.
19:51:45 <pjones> ... and yet he's not around :/
19:52:06 <nirik> we can revisit this again later in the meeting if he shows up?
19:52:23 <cwickert> AFAICS there were no changes on the wiki page
19:52:26 <pjones> yeah
19:52:35 <nirik> #info will revisit later in the meeting hopefully with jlaw around.
19:52:44 <nirik> ok, quick one:
19:52:46 <nirik> #topic #432 Add new FPL to fesco list
19:52:46 <nirik> .fesco 432
19:52:47 <zodbot> nirik: #432 (Add new FPL to fesco list) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/432
19:52:52 <nirik> I added the new FPL to our list.
19:53:09 <nirik> I removed stickster. :) However, he wants us to add him back for a bit.
19:53:17 <nirik> Is everyone ok with re-adding stickster for now?
19:53:22 <cwickert> 1st of august that was?
19:53:29 <pjones> sure
19:53:35 <SMParrish> I have no problems with it
19:53:36 <cwickert> +1 for adding him
19:53:42 <nirik> no problems from my side.
19:53:57 <stickster> nirik: Thanks folks, this will help me effectively help while Jared's out of pocket. I expect to be dropped >= August 1st. :-)
19:54:42 <nirik> #agreed will re-add stickster for a bit.
19:54:56 <nirik> Oxf13: you around to talk git? or want to defer to next week?
19:55:03 <Oxf13> I can talk now
19:55:27 <cwickert> go for git, go go go!
19:55:29 <Oxf13> do people want to listen?
19:55:38 <cwickert> sure
19:55:41 <SMParrish> All ears
19:55:56 * Oxf13 waits for topic change
19:56:33 <nirik> #topic #439: dist-git rollout plan
19:56:33 <nirik> .fesco 439
19:56:34 <zodbot> nirik: #439 (dist-git rollout plan) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/439
19:56:43 <Oxf13> alright
19:56:56 <Oxf13> so I'm putting the finishing touches and final details into our dist-git conversion
19:57:05 <pjones> yay.
19:57:28 <Oxf13> the last few things are minor (in relation to the tooling), such as how to name the branches
19:57:54 <Oxf13> we have the buildsystem able to build from git repos
19:58:16 <Oxf13> we have fedpkg able to cover what I would consider the minimum requirements (plus some) for initial roll out
19:58:31 <Oxf13> we have an ACL system that appears to work without falling over
19:58:51 <Oxf13> and we have conversion tools which appear to do the right thing with our existing CVS sources
19:59:07 <Oxf13> What I'd like to do is attempt converting over to dist-git during the F-14 branching point
19:59:30 <Oxf13> since that was already going to cause an outage. The outage would be longer, mayhap multiple days depending on repo conversion speed
19:59:48 <Oxf13> a brief outline follows:
19:59:54 <nirik> would it be possible/advisable to also do cvs branching in parallel in case we have to fail back to it?
20:00:00 <pjones> I think I'd support that - in that I think conversion should happen as early in the cycle as possible.
20:00:13 <Oxf13> nirik: cvs branching is actually pretty quick, so if we have to fall back it's not going to be a significant hurdle
20:00:26 <Oxf13> We're going to create a new host, pkgs.fedoraproject.org
20:00:41 <Oxf13> this new host will contain the git repos, as well as the lookaside cache and cgi
20:01:00 <Oxf13> We will make cvs.fedoraproject.org go read-only, then start the conversion script to get all the repos moved over
20:01:19 <Oxf13> Prior to this a fedpkg build will go out to the supported releases with a "production" configuration in it
20:01:45 <Oxf13> once the repos are converted, branched, and prepped for our use, we'll make the config change in koji to allow building from this new repo
20:01:46 <nirik> how's our documentation? ready to change for fedpkg?
20:01:49 <pjones> so the contingency plan is basically "nothing happened during the locked time"
20:02:12 <Oxf13> then we'll turn on pkgs.fedoraproject.org for commit access and allow building to resume.
20:02:12 <pjones> Oxf13: can koji not support both at once?
20:02:18 <mjg59> Oxf13: How long would you guess the conversion will take?
20:02:26 <SMParrish> is the cvs-admin team up to speed on what this will mean to them
20:02:37 <Oxf13> mjg59: on the test machine i have it took about a full day I think.
20:02:48 <Oxf13> pkgs.fp.o will ahve more resources
20:02:59 <Oxf13> and I can do some of the conversions in parallel
20:03:19 <Oxf13> SMParrish: I have been working with them and I have modified versions of their tools for dist-git
20:03:30 <nirik> SMParrish: happily the high level scripts won't change any, so the cvsadmin workflow should stay the same I think...
20:03:48 <Oxf13> their tasks will largely stay the same, although the path to the scripts they use will change, but that is insignificant.
20:04:00 <SMParrish> great just want ot make sure nothing is forgotten
20:04:07 <pjones> Oxf13: can koji not support both environments at once? if it can, it might be worth moving that to a much early timeframe, just to have fewer steps in the critical path
20:04:12 <Oxf13> pjones: It could, but I'm not sure I want to have the chance of builds coming from cvs and git at the same time
20:04:40 <Oxf13> the koji config change is just a config file entry, it takes seconds to make and push
20:05:11 <Oxf13> I'll be building up the config changes in a puppet branch so that when we're ready for the conversion we can merge the branch and push out the changes while the cvs2git conversions are happening
20:05:27 * stickster points at nirik's question about documentation... specifically packaging process stuff on wiki, nirik?
20:05:33 <Oxf13> ah right
20:05:39 <Oxf13> so the wiki stuff needs a lot of help
20:05:48 * stickster notes that stuff is ACL'd quite a bit
20:05:57 <Oxf13> I really need some volunteers to start working on dist-git style documentation for all the pages that talk about CVS
20:06:22 <Oxf13> some of that should wait until we finalize the branch naming convention though
20:06:24 <nirik> yeah, docs changes can be a pain, especially when the current stuff isn't organized all that well. ;(
20:06:29 <Oxf13> (and if we have time later in this meeting we can discuss that too)
20:07:44 <Oxf13> fedpkg has a pretty good help system to it, and can be made even better as people start using it and suggesting added help. Since it isn't make, it's a lot easier to hack on
20:08:02 <Oxf13> I suppose a man page couldn't hurt
20:08:08 <pjones> Oxf13: okay
20:09:07 <drago01> Oxf13: does fedpkg support "fancy" stuff like chain builds?
20:09:08 <dgilmore> pjones: making the change once makes it easier to know where the source for the srpm came from
20:09:11 <dgilmore> if we support both in parallel which we can
20:09:12 * nirik looks forward to watching CVS ride off into the sunset.
20:09:26 <Oxf13> drago01: there is code for chain builds, however I haven't tested it, thanks for reminding me.
20:09:26 <pjones> nirik: no kidding
20:09:37 <mjg59> nirik: Ride? I'm hoping it's shot and lying in a shallow grave.
20:09:55 <nirik> :)
20:09:55 <Oxf13> I do plan on keeping cvs.fedoraproject.org around in a read-only state for a while
20:10:10 <mjg59> Oxf13: Ok, good
20:10:12 <Oxf13> first on its existing hardware, until we're happy with dist-git and then it'll get shuffled onto less expensive hardware.
20:10:21 <mjg59> Does cvs support a banner?
20:10:33 <drago01> Oxf13: ok
20:10:48 <Oxf13> I don't have any real good numbers/idea about how well dist-git will scale when compared to dist-cvs, but many administrative tasks are /significantly/ faster with dist-git
20:11:05 <Oxf13> it is important to note that we are losing a couple features.
20:11:28 <Oxf13> 1) you won't be able to checkout an entire Fedora branch at once, eg you can't checkout rpms/F-13 and get the F-13 version of every package.
20:11:34 <Oxf13> (ditto for devel/)
20:11:49 <pjones> ... but you could write a very small shell script to do that
20:11:59 <Oxf13> 2) initially we won't be tagging the hashsums used to make builds with n-v-r.
20:12:15 <nirik> are we going to have anything like the daily cvs checkout seeds for git?
20:12:20 <Oxf13> This I plan to do later, based on if a build was successful or not, but that is not going to happen before F-14 branch.
20:12:34 <Oxf13> since hashes are immutable, I don't see this as a basic requirement.
20:12:54 <Oxf13> nirik: I don't know. I don't know what those are, but I imagine we can generate something though.
20:13:04 <SMParrish> Oxf13: what branches will the effect? F12+ and epel4+ ?
20:13:14 <drago01> all?
20:13:21 <drago01> otherwise it won't make much sense
20:13:26 <nirik> http://cvs.fedoraproject.org/webfiles/
20:13:28 <Oxf13> The conversion will attempt to convert any branch it finds in Fedora's public dist-cvs
20:13:37 <Oxf13> which means FC-6+
20:14:08 <gholms> How do you work around tags with names that aren't git-compatible?
20:14:12 <SMParrish> Oxf13: any reason why were including the EOL releases, wouldn't the conversion be faster if they were omitted
20:14:15 <Oxf13> oh another feature is that you won't be able to check out every single module / branch at once. You have to script and loop through each module.
20:14:41 <Oxf13> gholms: right now the only tags I've encountered that aren't git compatible are mistags that have untranslated macros in them such as {dist}
20:14:42 * nirik thinks it might be nice to have history...
20:15:27 <Oxf13> erm
20:15:31 <Oxf13> {?dist} that is
20:15:36 <Oxf13> the ? is the problematic character.
20:15:44 <Oxf13> and I've just translated it out to nothing.
20:15:59 <Oxf13> so you wind up with a tag that is like {dist} instead of {?dist} but the tag wasn't useful to begin with.
20:16:10 <nirik> ok, so any further questions on this? Did you want us to rubberstamp the migration ? or just FYI... ;)
20:16:14 <Oxf13> similarly [ is translated out
20:16:51 <Oxf13> SMParrish: the conversion would be marginally faster, but then we'd have to rely upon the old cvs server remaining up for history, I'd prefer to have it all in git
20:17:19 <dgilmore> nirik: i think we want the goahead from fesco. it will need to be widely announced
20:17:26 <SMParrish> Oxf13: thanks
20:17:35 <Oxf13> nirik: mostly I wanted to get all your thoughts on this, to make sure I'm not forgetting anything, and to make sure my plan seems sane.
20:17:44 <Oxf13> The roll back plan is as follows:
20:18:08 <Oxf13> if we haven't turned on building from dist-git, simply revert any config changes and turn committing back on on cvs.fedoraproject.org (after doing the F-14 branching)
20:18:40 <Oxf13> if we have turned on building, we'll turn back on CVS, import any built rpms into cvs, and continue
20:19:09 <Oxf13> the two systems are isolated enough that rolling back is fairly easy and fast which is why I'm willing to rush forward with an attempted roll out
20:19:15 * nirik is +1 on the plan. I'm happy to ditch cvs. I can't think of anything additional (which is not to say that something couldn't come up).
20:19:18 <pjones> yeah, I like this.
20:20:11 <mjg59> Yeah, I think so too
20:20:27 <cwickert> +1
20:20:29 <SMParrish> I'm +1 on this. Been looking forward to dumping cvs
20:20:35 <nirik> excellent.
20:20:40 <Oxf13> I apologize for not having this in a wiki page, I was unexpectedly busy with family matters last night.
20:21:00 <nirik> #agreed Go forth and GIT. Move forward at F14 branch time with a migration.
20:21:09 <Oxf13> woo woo!
20:21:11 <nirik> thanks for all the work on this Oxf13
20:21:28 <nirik> ok, moving along...
20:21:35 <nirik> another hopefully quick one:
20:21:39 <nirik> #topic Till Maass unavailable
20:21:52 <nirik> Till indicated on the devel list that he would be unavailable.
20:22:04 <pjones> uh, okay.
20:22:08 <nirik> Would it be ok if we generated a list of his packages and made sure everything had co-maintainers?
20:22:21 <nirik> and for those that do not, approve co-maintainers who wish to step up?
20:22:38 <nirik> or should we just leave things alone
20:22:58 <Oxf13> the list has been posted
20:23:02 <hicham> unavailable for good ?
20:23:07 <Oxf13> from an outsider, I'd say treat it as a vacation
20:23:23 <cwickert> hicham: due to an accident
20:23:28 <nirik> all we have is: "I cannot maintain my packages or handle anything else until further notice, because I had an accident."
20:23:43 <nirik> I read that as hopefully not being that long term, but "further notice" could be a while...
20:23:52 <SMParrish> nirik: I saw no ETA on his return in the message, but am willing to give him a few weeks before we take any action
20:23:54 <cwickert> I'm having an eye on them
20:23:58 <pjones> yeah
20:24:00 <hicham> provenpackagers can do the job
20:24:08 <pjones> I'm reading this as the "two broken hands" scenario
20:24:17 <cwickert> and I can also contact Till in private since I know him
20:24:23 * lmacken added himself to a bunch of his packages yesterday
20:24:39 <nirik> ok, just didn't want the packages to be ignored until someone tries to start the unresponsive maintainer process.
20:24:49 <nirik> sounds like folks are looking out, so great.
20:24:55 <nirik> lmacken: did he approve you?
20:25:28 <nirik> I guess only acls needs approval.
20:25:41 <nirik> ok, moving on then...
20:25:46 <skvidal> cwickert: tell till everyone hopes his injuries are not too bad and that he's able to heal up completely. Also tell him thanks for sending the notice
20:25:59 <cwickert> skvidal: will do
20:26:07 <nirik> totally agreed. :) Best wishes for a speedy recovery.
20:26:15 * skvidal apologizes for intruding
20:26:21 <nirik> #topic #431 Exception for Recoll bundling other libraries modified
20:26:21 <nirik> .fesco 431
20:26:21 <cwickert> skvidal: in fact I'm even thinking about going to Aachen to visit him
20:26:23 <zodbot> nirik: #431 (Exception for Recoll bundling other libraries modified) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/431
20:26:43 <nirik> skvidal: not an intrusion at all. ;)
20:27:31 <nirik> I'm +1 here given spot's input...
20:28:12 <pjones> yeah, I'm +1 on allowing it
20:28:18 <nirik> upstreams are dead and the code has been heavily modified.
20:28:23 <SMParrish> same +1
20:28:28 <nirik> so it's really more reuse than bundling.
20:28:35 <mjg59> +1
20:28:46 <cwickert> +1 then
20:28:49 <mjg59> If possibly worth long-term splitting out and independently forking
20:28:58 <mjg59> If anyone else might make use of it
20:29:19 <nirik> #agreed exception granted in this case.
20:29:26 <nirik> #topic #433 F14Feature: CryptographyInKernel - https://fedoraproject.org/wiki/Features/CryptographyInKernel
20:29:27 <nirik> .fesco 433
20:29:29 <zodbot> nirik: #433 (F14Feature: CryptographyInKernel - https://fedoraproject.org/wiki/Features/CryptographyInKernel) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/433
20:29:38 <nirik> on to features we didn't get to last week.
20:30:34 <nirik> I'm +1 for this, but I don't think it's upstream yet, so I fear it may not make F14.
20:31:18 <pjones> yeah, I like the idea, but if it's not upstream yet...
20:31:21 <mjg59> This came up on #fedora-kernel today
20:31:29 <mjg59> The kernel->userspace ABI isn't fixed yet
20:31:38 <pjones> I'm -1 until that happens
20:31:50 <mjg59> Userspace ABI is via a library so wouldn't vary, but given what we went through with DRM ABI breakage in-kernel...
20:32:08 <sgrubb> One thing I would like to point out is that all new security targets/standards a
20:32:08 <sgrubb> re calling for a separation in address space of cryptographic services and consumers. This will futureproof the crypto systems.
20:32:08 <mjg59> The problem is that we'd need to update the userspace library in lockstep with the kernel, and also deal with the case where the user has two different kernels installed
20:32:26 <sgrubb> actually, the plan is to make it configurable
20:32:39 <mjg59> So, on balance, I'm going to say that this is a valid feature and also one that we can't support in F14
20:32:57 <pjones> mjg59: yeah, that's what I'm thinking. It looks nice as an F15 feature probably
20:33:33 <sgrubb> we really need this tested and solid before F-15
20:33:51 <nirik> is this likely to get into .35?
20:34:08 <sgrubb> I don't know the merge window offhand
20:34:13 <mitr> Is there a chance for "approved feature, but kernel team must accept the code or it must arrive from upstream" instead? I realize the odds are slim
20:34:17 <mjg59> sgrubb: If you can't commit to a fixed kernel->userspace ABI before F14, then we can't sensibly support it in F14
20:34:37 <mitr> The kernel code is nearing functional completeness, and I've started sending it out for reviews today
20:34:45 <mjg59> But I'm happy to approve the feature with the proviso that that doesn't mean it should go into the Fedora kernel yet
20:34:47 <sgrubb> the ABI should be something we can set
20:34:56 <pjones> sgrubb: I understand that you've got a timeline, but if it's not ready it's not ready
20:35:08 <mjg59> All it means is that it doesn't get to 100% and we don't advertise it
20:35:20 <pjones> also what mjg59 said.
20:35:26 <SMParrish> if its not 100% by feature freeze then it gets cut
20:35:35 <sgrubb> that sounds fine to me
20:35:49 * nirik is fine with that plan...
20:35:54 <pjones> alright, +1 then
20:35:59 <mjg59> So +1, but you'll need to convince the kernel people that it's got a totally fixed ABI
20:36:19 <sgrubb> sure, we are starting that process as mitr said
20:36:19 <nirik> +1 here
20:36:25 <SMParrish> +1
20:36:59 <nirik> cwickert: ?
20:37:31 <cwickert> sorry
20:37:31 <cwickert> +1
20:37:51 <nirik> #agreed Feature is approved.
20:38:03 <nirik> good luck sgrubb / mitr. :)
20:38:11 <sgrubb> thanks
20:38:18 <mitr> thanks guys
20:38:28 <nirik> thanks for being here and providing info for us.
20:38:32 <nirik> #topic #434 F14Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations
20:38:32 <nirik> .fesco 434
20:38:33 <zodbot> nirik: #434 (F14Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/434
20:39:22 <nirik> In general I like this idea, but dnssec fills me with dread given it's history of update issues. ;(
20:39:29 <SMParrish> I looked this over and am concerned they haven't approached the NM folks yet. Think that needs to be addressed first
20:39:36 <pjones> I like this, but a) dnssec has had issues... and b) 15% completed.
20:39:57 <mjg59> Yeah, I'd like some input from the NM people
20:40:00 <pjones> SMParrish: yeah, I absolutely want to know what dan has to say
20:40:20 <nirik> should we ask questions and defer until next week?
20:40:23 <pjones> so I think we need more info here, based on that
20:40:25 <pjones> nirik: yeah
20:40:31 <SMParrish> yes defer
20:40:43 <nirik> ok.
20:40:57 <nirik> #info will ask questions of feature owner and revisit next week.
20:41:10 <pjones> probably best to ask atkac/pwouters _and_ dcbw about it
20:41:23 <cwickert> +1 for deferring
20:41:24 <nirik> can someone step up to do so?
20:41:56 * nirik listens to crickets.
20:42:04 <pjones> those are some loud crickets there.
20:42:18 <pjones> I'm not committing to more work between now and the 28th.
20:42:44 <mjg59> Ok, I'll do it
20:42:50 <nirik> mjg59: thanks.
20:43:08 <nirik> #action mjg59 to ask for more input on this feature.
20:43:11 <nirik> #topic #435 F14Feature: F14EclipseHelios - https://fedoraproject.org/wiki/Features/F14EclipseHelios
20:43:11 <nirik> .fesco 435
20:43:12 <zodbot> nirik: #435 (F14Feature: F14EclipseHelios - https://fedoraproject.org/wiki/Features/F14EclipseHelios) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/435
20:43:43 <nirik> 33 million lines of code. yikes
20:44:05 <SMParrish> nirik: and all java probably )
20:44:12 <cwickert> :)
20:44:28 <nirik> anyhow, +1, worth touting if nothing else.
20:44:31 <pjones> I'm pretty much okay with believing overholt knows what he's doing
20:44:39 <pjones> +1
20:44:40 <SMParrish> +1
20:44:42 <cwickert> sure he does, +1
20:45:12 <pjones> it's just the next upstream release anyway
20:45:31 <nirik> mjg59: thoughts/vote?
20:45:34 <mjg59> +1
20:45:39 <nirik> #agreed Feature is approved.
20:45:45 <nirik> #topic #436 F14Feature: KDE45 - https://fedoraproject.org/wiki/Features/KDE45
20:45:45 <nirik> .fesco 436
20:45:46 <zodbot> nirik: #436 (F14Feature: KDE45 - https://fedoraproject.org/wiki/Features/KDE45) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/436
20:46:02 <pjones> I'm +1 on this
20:46:09 <mjg59> The name of this project keeps getting longer
20:46:11 <mjg59> But +1
20:46:16 <SMParrish> +1
20:46:16 <nirik> +1... another fedora release, needs a new kde. ;)
20:46:49 <pjones> nirik: itym "another fedora *release*, another kde" ;)
20:47:10 <nirik> cwickert: ?
20:47:15 <nirik> pjones: ;)
20:47:18 <cwickert> +1
20:47:20 <nirik> #agreed Feature is approved.
20:47:27 <nirik> #topic #437 F14Feature: MemoryDebuggingTools - https://fedoraproject.org/wiki/Features/MemoryDebuggingTools
20:47:27 <nirik> .fesco 437
20:47:28 <zodbot> nirik: #437 (F14Feature: MemoryDebuggingTools - https://fedoraproject.org/wiki/Features/MemoryDebuggingTools) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/437
20:47:35 * dmalcolm is lurking
20:47:38 <pjones> +1 to this because it's awesome.
20:47:40 * cwickert hopes that kdepim 4.5 will make it
20:47:48 <cwickert> +1 for memory debugging
20:48:07 <nirik> nifty. +1.
20:48:15 <nirik> is this being upstreamed in gdb?
20:48:20 <SMParrish> +1
20:48:33 <nirik> oh, it's it's own thing. right.
20:48:35 <dmalcolm> nirik: it's separate code, written in python
20:48:35 <pjones> nirik: AIUI it doesn't need to be
20:48:45 <pjones> it's just a plugin
20:48:52 <nirik> makes sense. cool stuff.
20:48:57 <dmalcolm> nirik: it heavily uses the gdb python API; see: https://fedorahosted.org/gdb-heap/#Compatibilitywithgdbversions
20:49:14 <nirik> mjg59: votes?
20:49:17 <mjg59> +1
20:49:22 <nirik> #agreed Feature is approved.
20:49:29 <nirik> #topic #438 F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7
20:49:29 <nirik> .fesco 438
20:49:30 <zodbot> nirik: #438 (F14Feature: Ruby_1.87 - https://fedoraproject.org/wiki/Features/Ruby_1.8.7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/438
20:49:52 <mjg59> ...z releases are features?
20:50:08 <mjg59> On the other hand, it was released two years ago
20:50:17 <mjg59> So it seems fair
20:50:18 <mjg59> +1
20:50:30 <nirik> I guess this will need a mass rebuild of ruby packages?
20:50:33 <gholms> Not 1.9.x?
20:50:48 <SMParrish> +1
20:50:53 <cwickert> "Users will notice no difference other than the availability of the updated Ruby 1.8.7 rpm." - so is this really a feature then?
20:51:24 <mjg59> If it means that more software will work, sure
20:51:31 * nirik wonders how different ruby-1.8.6.399 and ruby-1.8.7 is.
20:51:44 <pjones> gholms: yeah, that seems really weird
20:52:11 <drago01> nirik: 0.0.0.601 ? ;)
20:52:15 <cwickert> so does it require a mass rebuild? then it's a feature
20:53:13 * nirik notes also that the feature owner isn't a owner of the ruby package unless I am missing something.
20:53:42 <nirik> I vote we gather more info and defer to next week...
20:53:45 <pjones> so, let's get the package owner's input, and also some clarification on why we're not talking about 1.9
20:53:57 <nirik> and if a mass rebuild is needed or not.
20:54:01 <pjones> right
20:54:14 <cwickert> 1.8.6 to 1.8.7 doesn't seem to be a big deal
20:54:20 <nirik> yeah.
20:54:22 <cwickert> but let's ask
20:54:30 <SMParrish> sounds good
20:54:36 <nirik> anyone want to commit to asking those questions/following up on this?
20:55:03 * nirik guesses he can do so if no one else can.
20:55:11 * cwickert is about to do that now
20:55:15 <nirik> #info will gather more info and revisit next week.
20:55:20 <nirik> cwickert: excellent. Thanks.
20:55:43 <pjones> still no jlaw
20:55:54 <nirik> nope. ;( Defer that till next week?
20:55:59 <pjones> I guess so :/
20:56:03 <nirik> #topic Open Floor
20:56:08 <nirik> ok, anything for open floor?
20:56:25 <Oxf13> I think dmalcolm has a topic
20:56:38 <nirik> ok, dmalcolm ?
20:57:06 <dmalcolm> python 2.7 mass rebuild
20:57:15 <dmalcolm> https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild
20:57:15 <nirik> #topic Python 2.7 mass rebuild
20:57:19 <dmalcolm> https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild
20:57:47 <dmalcolm> hope to kick this off tomorrow, though still some uncertainty (see the TODOs)
20:59:00 * nirik wonders if the gold linker thing or the gdb changes matter any here.
20:59:20 * dmalcolm sincerely hopes not
20:59:23 <pjones> probably gold
20:59:33 <dmalcolm> is gold in the buildroot?
20:59:33 <pjones> oh wait, misread your statement.
20:59:36 <pjones> neither /should/ matter.
20:59:48 <pjones> but it might be nice to have gold switched over before we do this
20:59:57 <nirik> right.
21:00:27 <pjones> current plan /isn't/ to do a rebuild for gold, right?
21:00:43 <Oxf13> I have not been approached to do one
21:00:59 * dmalcolm is worried that he will become the victim^Wvolunteer for fixing gold-related breakage
21:01:04 <pjones> hrm, the feature page mentions one
21:01:18 <pjones> but more of as a precautionary measure than "omg need to rebuild"
21:01:32 <nirik> "Third, rebuild everything. In theory, any compatibility issues between gold and gnu-ld were addressed during the Fedora 13 cycle. But a mass rebuild should be run as soon as possible to weed out any new problems"
21:02:22 <pjones> dmalcolm: but at the same time, if a python package has a gold-related problem, it was probably already broken
21:02:34 <pjones> (though it might not be your problem, depending on the package)
21:02:55 <nirik> right, so really we need to get this gold feature sorted as soon as we can.
21:03:04 <Oxf13> I think that "mass rebuild" coudl be done by mdomsch on the side
21:03:12 <Oxf13> as opposed to in our real scm and buildsystem
21:03:28 * mdomsch perks up
21:03:30 <dmalcolm> is this https://fedoraproject.org/wiki/Features/GoldLinkerDefault ?
21:03:34 <nirik> yea
21:03:46 <pjones> nirik: well, the danger there is probably shipping a distro that's got a lot of FTBFS in it
21:03:57 <pjones> (which technically is probably a license violation...)
21:05:34 <nirik> well, not sure we can solve this now... perhaps try and get answewrs out of band and vote in tickets/have a special session later this week?
21:05:55 <nirik> dmalcolm: I would say your plan looks fine to me, but we should figure out if we need gold to land before that.
21:05:58 <pjones> yeah, I think we're going to have to do that
21:06:03 <mdomsch> how can I help?
21:06:29 <nirik> mdomsch: a mass rebuild with gold enabled might be good... I'm not sure how to make it default tho off hand.
21:06:47 <pjones> nirik: move the symlink from ld -> ld.bfd to ld -> ld.gold ?
21:06:53 <gholms> The feature page suggests using alternatives.
21:07:13 <nirik> yep. it's an alternative. cool.
21:07:19 <pjones> er, yeah, it's indirect by one step.
21:07:32 <nirik> 'alternatives --set ld /usr/bin/ld.gold'
21:07:36 <mdomsch> inside the chroot of course
21:07:40 <pjones> right
21:07:57 <nirik> it's unclear to us if kernel/glibc need to build with the old linker.
21:08:15 <nirik> also, anything that still FTBFS from the dso changes last cycle will not work with gold either.
21:08:18 <mjg59> Does gcc have a command-line option to choose the linker?
21:08:50 <nirik> not that I know of off hand.
21:09:15 <pjones> mjg59: not according to info
21:09:21 <Oxf13> mdomsch: could probably build a version of gold that forces itself to be the default and use that in all your chroots
21:09:22 <pjones> which is unfortunate :/
21:09:24 <mjg59> So how would something that requires the binutils one work?
21:09:30 <mjg59> Build-conflict with gold?
21:09:34 <Oxf13> mdomsch: rather than manipulation of the chroot itself.
21:09:44 <nirik> mjg59: nope. gold is in binutils already.
21:09:47 <pjones> mjg59: manually call /usr/bin/ld.bfd? which suuucks.
21:09:55 <mjg59> nirik: Oh, of course
21:09:59 <pjones> so this is probably another thing we want to ask the tools team
21:10:02 <mjg59> Yeah
21:10:27 <nirik> can someone contact jlaw and ask our questions/get info?
21:10:43 <mdomsch> Oxf13: yes please
21:11:20 * nirik can do so if no one else can.
21:11:29 <Oxf13> mdomsch: I meant "someone" could, not me :)
21:12:21 <dmalcolm> I was hoping to start the python rebuild tomorrow; should I wait/postpone until this is resolved? I'd prefer not to be the guinea pig for gold by default though :)
21:12:52 <pjones> dmalcolm: I think so for now - we might decide you can go ahead, but I think more info is needed before we can make that decision
21:13:01 * nirik nods.
21:13:59 <dmalcolm> ok. please can you email me directly when the status is known? my email filters aren't working great right now :(
21:14:06 <nirik> sorry for any delays...
21:14:09 <pjones> okay
21:14:49 <nirik> #topic Open Floor
21:14:54 <nirik> anything more for open floor.
21:16:10 * nirik will close things out in a minute then if not.
21:16:10 <pjones> I propose that we're done.
21:16:43 <gholms> [You hear some noises in the distance.]
21:17:06 <nirik> thanks for coming everyone.
21:17:10 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100720/2e902fcf/attachment.bin
More information about the devel
mailing list