=================================== #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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
