--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
* j-rod here
jwb is here
jds2001 here
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
Hi everybody; who's around?
* jwb is here
Kick__ is here
nirik is here.
j-rod is still here
bpeppleok, I see six of us here, so we can probably get started.
--- bpepple has changed the topic to: FESCo-Meeting - Final F11 Schedule - https://fedoraproject.org/wiki/Releases/11/Schedule - all
* notting is here
bpepplerel-eng finalized their schedule proposal.
everyone get a chance to look it over? and if so, are there any objections to it?
* jds2001 hopes that feature freeze != beta freeze will help, we'll see.
nirik is fine with that, +1
bpeppleok, I see seven '+1', and no objections, so we've approved the schedule.
wwoodsPlease note that we (rel-eng, QA) are expecting FESCo to make final decisions on whether to keep or defer features at the meeting *before* the freeze
nirikwwoods: yeah, thats a good plan.
bpepplewwoods: the final freeze on 4/14, correct?
wwoodsto give rel-eng/QA a week to enact contingency plans (i.e. rearrange comps etc.) before the freeze happens
well, each of the freezes, really
but yes
that's the critical one
bpeppleso, we should make any final decisions by 4/8 at the latest.
wwoodsFeature Freeze (Mar 3) is also important - anything not testable by that date shoudl be deferred
Which means any feature that's not testable and nearly complete by Feb. 25
may be pushed to F12
yes. that soon.
bpepplewwoods: sounds good.
I'll put those dates in my meeting summary.
* nirik needs to get going on his feature page... :)
nirikwe may want to highlight that with a post to fedora-devel-announce as well?
bpepplenirik: yeah, not a bad idea.
wwoodsyes, final release is all the way in the summer but new features must be specced out and testable (i.e. nearly complete) in *12 weeks*
bpeppleI think poelcat usually sends out an e-mail reminding about the feature process, maybe we can have him add those dates to the message.
* jds2001 has been the bad guy on the announce list lately.
jds2001so I guess I can continue :)
bpepplejds2001: works for me.  thanks!
jds2001(i.e. I'll draft and send the mail - hopefully today)
wwoodsobviously it's up to FESCo's judgement - if something's not testable on Feb. 25 but the packages will be in the Feb. 26 rawhide spin, that's probably fine
jds2001it'll include the scope/test plan stuff from last week too.
wwoodsso: a week before alpha freeze (Jan. 14) every feature needs a spec
Feb. 25, features need to be pretty dang close to meeting that spec, and have a test plan that I can follow to confirm that fact
Apr. 8, features need to be 100% complete and all final packages should be built
it sounds like a long time to freeze but it's the same schedule we've had for a couple years. we're just actually trying to *enforce* it this time.
bpepplewwoods: yeah, that's something I would like us (FESCo) to do a better job this release.
ok, anything else in regard to the schedule anyone want to bring up?
alright, if there is nothing else we can move on.
--- bpepple has changed the topic to: FESCo-Meeting - Merge dist-f11-python with Rawhide on Thursday - https://fedorahosted.org/rel-eng/ticket/1114 - all
bpeppleivazquez: ping.
bpepplealright, ivazquez is looking to merge python-2.6 with Rawhide on thursday.
nirikso how much is left that will break?
ivazquezI don't rightly know.
There have been... issues.
* jds2001 notes pretty much all of system-config-* is there, lots of python modules
ivazquezlibtool, build wars, and so on.
But I did get yum and pygtk2 working.
And a fair number of s-c-* packages.
jwbok, let me ask a slightly different question
is there really a better time or better plan for getting this in, other than slamming it in and seeing what happens?
* nirik notes yum is important, to allow people to update to fixed packages. ;)
XulChrisyou dont need yum to update
jds2001I see 706 pakcages in dist-f11-python
ivazquezDifferent, yes. Better, no.
There will be issues regardless of when it happens.
jds2001who knows how many of them actually work?
nirikXulChris: sure, but makes it easier.
jds2001wll 704 counting the two header lines :)
ivazquezThe only thing that needs to happen for yum to work on Thursday is that rpm needs to be rebuilt.
Kick__ivazquez:  do you have a wiki page which lists some common issues that packagers should look out for ?
nottingivazquez: that's sort of a biggie
jeremyfwiw, I'm updating my laptop now so that anything to try to help make sure anything super-obviously-broken gets fixed up
ivazqueznotting: I know. It got caught in a build war.
bpeppleivazquez: that was pkconfig issue, right?
ivazquezIt was caused by the pkgconfig issue.
I don't see it as a big deal though.
A bump and a build, and we're in business.
jeremyivazquez: I think that we have to have working yum to switchover.  but bump and build of rpm I can do this afternoon
ivazquezWell, I see little point in doing it until the tags are merged.
ivazquezThe other big package issues are libtool and xulrunner.
I'm working on fixing libtool, which will fix avahi, which will unblock a pile of packages.
ivazquezcaillon said he would do something about xulrunner.
jds2001ivazquez: no, build a new rpm in dist-f11-python so that it Just Works(TM) when merged
ivazquezjds2001: I'm not interested in another build war over rpm. Every time I see it go back to dist-f11... it takes a bit out of me.
* Kick__ unfortunately wasn't aware of any libtool issues until ivazquez filed a bug today
ivazquezI should've filed it earlier, and I'll take the heat for that one.
I have a feature page up, but it hasn't been wrangled yet. https://fedoraproject.org/wiki/Features/Python_2.6
So, which questions did I miss...
Oh yes, package issues.
There really aren't any. It's just a matter of stomping on depsolve failures.
ivazquezThere are a few code issues, but I and others have been stomping on them as they show up.
nottingassuming yum & rpm are ready, +1 from me
ivazquezNonetheless, avahi and xulrunner are probably shadowing a few more.
Kick__what's the state of anaconda ?
nirik+1 (with nottings proviso)
ivazquezIt built. I don't know that it works.
jds2001ivazquez: your page was in the wrong category, I fixed it for ya :)
Kick__not a problem for me if rawhide isn't installable for a few days
ivazquezjds2001: Oh. I just followed the rules in the template.
jds2001again, +1 if yum and rpm are OK
nirikivazquez: additionally, would you be willing to write up a wiki page/SOP/howto on how to use a seperate tag to merge something like this? It would be great to reuse what you have learned for other people doing this down the road... if you have time to write it up.
Kick__+1 with yum and rpm
j-rodyeah, its early enough, breakage is almost mandatory right now. :)
ivazqueznirik: Sure, I can do that.
jds2001ivazquez: you used FeaturePageReady.... instead of FeatureReady.... :)
ivazquezAh, okay.
bpepple+1 here also, assuming yum & rpm are ok.
ivazquezAny further questions?
jds2001ivazquez: you're the first one to incur my wrath here, but scope and test plan are weofully inadequate :P
but those dont have to be in place til later
alpha freeze for scope, beta freeze for test plan
ivazquezThe problem with Scope is that Python is so pervasive in Fedora that it almost ends up being "everything".
bpeppleivazquez: ok, I see six '+1' (providing rpm & yum are ok), and no objections, so your proposal has been approved.
jds2001yeah :P
ivazquezIf rpm gets a rebuild then yum will be fine. I have it running in a VM here.
f13ivazquez: surely though you could come up with some measure of "success"
ivazquezIt does emit 3 DeprecationWarnings which I've passed to James.
f13ivazquez: a turning point between "fix remaining bugs" and "throw it all out and scratch the feature"
jwb"it pisses enough users off that we have a mass exodus to ubuntu"
XulChrisit wont be that bad ;-)
ivazquezMy definition of success would be that we can install a system usable by a Fedora packager to get their tasks done.
jwbivazquez, i think that's fair
ivazquezSo anaconda, koji, bodhi, mash, pungi.
XulChrismigrating to python3 might be though ;-)
jwbivazquez, and yum and rpm
ivazquezrpm and yum are way, way below those.
If we can get those five then we're golden.
jwbso, how far off are those 5?
ivazquezOne moment...
ivazquezAll but bodhi have been built.
bodhi was blocked by python-cherrypy2, which only got built very recently thanks to abadger1999's efforts.
But none have been tested.
jwbcan you have them tested before tomorrow?
notting.... why do we care whether bodhi works with the new python yet? we're not running the server on rawhide.
wwoodsso the scope of the problem is: rebuild every python package in the distro?
ivazquezI can test pungi, and possibly mash. koji and anaconda are out.
j-rodivazquez: doesn't testing pungi require testing anaconda?
er, include
ivazquezPart of it, certainly.
pjonesI wouldn't think it includes all of it.
XulChrisarent we sophisticated enough yet to make test scripts for these apps which can be run in %test?
pjonesXulChris: test scripts along those lines for the installer are... difficult.
j-rodnot all, no, but certainly "it doesn't blow up" sanity-testing
abadger1999notting: the bodhi package also has a client subpackage used in "make update"
j-rodand pungi should spit out an iso that could be booted in a guest...
nottingabadger1999: which is not a required feature... i mean, yeah, it should work by f11
but i really don't care whether or not it works for moving the python stuff over
abadger1999If we can build the bodhi package, though, the client code is independent of the server code (which is where our rebuild troubles have been);.
there's the web interface so it's not critical.
ivazquezwwoods: Every package that builds against the .so and every package that has compiled scripts.
jwbexcept no
because xulrunner is required for the web interface
(for packagers using rawhide as their development platform)
nottingjwb: it doesn't break kvm :P
jwbnot everyone is rich
jeremyjwb: xulrunner's python bits are just python binding to use xulrunner in things like sugar's web browser
the package didn't exist at all in Fedora until about 2 months ago
jwbjeremy, either way, if it doesn't build...
ivazquezIt builds.
I just am unable to do a formal build since I'm not in the ACL.
nottingwhich doesn't sound like a move blocker
ivazquezBut a scratch build succeeds.
nottingsorry, back in a minute or two
jeremythere are certainly things that will still need work -- but as long as people can continue to 'yum update', then we should be in good enough shape
ivazquezYes, yum works.
bpeppleok, so has anyone reversed the earlier vote?  Otherwise, ivazquez's proposal was approved.
jwbi'll add a +1
any other questions for ivazquez? otherwise we can probably move on.
XulChriswill bugs be filed for the remaining packages that dont build?
bpeppleivazquez: thanks for all your work on this, it's really appreciated!
ivazquezGlad to help.
XulChrisi guess that falls under that FTBFS bug
jeremyespecially by me!  as I didn't have to do it this time :-)
bpeppleok, moving on......
--- bpepple has changed the topic to: FESCo-Meeting - Secondary Arches: will they ever fly? (aka, wtf happened to Fedora ia64, and what can/should we do to resuscitate it)- j-rod
XulChrisi thought this was going to be discussed on the mailing list first or something?
f13probably better mailing list topic
jwbit was
bpeppleXulChris: was it?  I haven't read my e-mail since earlier this morning.
jwbi discussed it
bpeppleah, ok.
moving on then...
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
jwbnot sure if there was more discuss that people wanted
* XulChris has a topic
bpeppleok, that was everything I had on the schedule, is there anything else folks want to discuss?
jwbwhat is going on with ocmal?
j-rodhold on, back to secondary arches for a sec, por favor
bpepplej-rod: shoot.
j-rodis this something FESCo even cares/should have anything to do with?
f13all in favor of nominating j-rod as master of s390?
j-rodf13: I hate you.
* j-rod glances at the ia64 box sitting behind him...
f13I think it's fair for FESCo to have some oversite on where secondarcy arches intersect with primary arches
chepersonally id have most use cases in the arm sector ;)
jwbj-rod, i think we care in the sense that we want to make sure there are no hurdles to getting it done
f13the whole way this is setup was ran through FESCo via spot way back when.
nirikI think the big thing is that we would like to see more communication from them. ;)
jwbnirik, that too
nirikche: I would love to see arm up to date... would stick it on my phone. ;)
chenirik, ;)
j-rodone big thing is that ia64 basically went completely dark a few weeks ago, and I don't know if anyone cares
or if its publicly known why
spotthe ia64 secondary arch people know why.
f13any place that secondary arch work would have impact upon primary arch maintainers, that should be overseen by FESCo to make sure that interaction is done in a way that is favorable to the greater maintainer base.
nirikso, until we know more, I don't think this is really something we can do anything about... I would love to see regular status reports and/or at least a frontperson contact email... but I have no idea how to even request that
j-roddgilmore: I think you know more about this than I, but I suspect you're out of the office for a bit... :)
jds2001j-rod: i dont personally care, since I don't have any ia64 hardware.
f13I care, only from a Red Hat RHEL point of view
jds2001but I think we should be encouraging it.
since RHEL does support ia64 obviously
jwbwhy does that matter
jds2001(as well as s390, so i nominate j-rod for that post :) ).
jwbor, more specifically, why does that matter for FESCo?
f13jwb: it matters to those of us who live in both camps.
f13not necessarily to fesco, I'm talking individuals
j-rodfolks inside RH *should* care about at least the secondary arches that RHEL supports
jwbyeah, sure.  but FESCo?
nottingi think we should clarify the policy to encourage/force regular reports
spotdgilmore is actually working on the kojisad code now (well, when he's back on the clock)
we should have more to talk about wrt secondaries at FUDCon
nottingbecause i believe we (as FESCo) want to know a) if there are particular hurdles that are troubling them b) if the team for a particular arch has gone AWOL
f13koji sad?
bpepplenotting: agreed.  I think the big issue is that most folks aren't aware of the status of the various arches.
f13secondary arches make the baby koji cry?
j-rodsomething along the lines of at least monthly status reports from the secondary arch groups would be nice
bpepplej-rod: yeah, that sounds good.
jds2001that would be great.
nottingj-rod: +1 to that
jwb+1 to j-rod's suggestion
bpeppledoes someone have a list of the secondary arches leads, so that we can contact them, and ask for monthly reports?
they should all have lists at least
notting(and if the people on that list aren't the right people, that's also something we'd want to know)
bpeppledoes anyone want to contact them (otherwise I can)?
jds2001there's a FAS group for each arch
jwbbpepple, i can do it
bpepplejwb: great, thanks!
jds2001that should contain the leads, since that's similar to cvsadmin
bpepplej-rod: anything else in regards to secondary arches?
j-rodnah, nothing for now. Request regular status reports so we know what's going on, and the rest, we can take to the lists
bpepplej-rod: cool.
XulChris: you had something you wanted to bring up?
bpepplefloors yours.
XulChrisi have a package which is changing its license to affero gpl
and it is a compiled binary, so I need to include the source code with the rpm
and there are no other examples of packages with these circumstances
i was wondering if i can just Requires: %{name}-source
AINAL but i think the reason why i cant just include SOURCE0 is because the license requires that i include all the spec files etc to build the rpm
nirikXulChris: I think this might be better discussed at the packageing comittee meeting?
XulChrisbut the other two packages which have this license dont do that
f13I'm confused.
how is this aspect of the license any different from the GPL itself?
nirikXulChris: they don't have binaries tho?
f13why isn't the srpm suitable?
XulChrisnirik: no they are both all source code packages
f13: i think the issue is, that the installed rpm must include the source code
f13where is that listed in teh license?
jwbXulChris, i think this is probably a better question for fedora-legal
jwbspot and company can probably help you more than FESCo
nottingXulChris: 6d) would seem to apply, which would imply no need for a separate package
XulChrisok im not very familiar with the license
upstream is just telling me that i will need to add the source code
f13yeah, I think 6d covers Fedora pretty ell.
nottingbut yeah, check with fedora-legal
jwbXulChris, by all means CC upstream too
bpeppleXulChris: any other questions?
XulChrisi guess ill ask the packaging comittee
and get more clarification from upstream
about the legal issues
and cc that to fedora-legal
there is nothing wrong with Requires: %{name}-source is there?
other than that repo is typically not enabled?
nottingyou can't require outside of your own repo
at least, that *should* be policy
XulChrisim not aware of any policy like that
f13XulChris: that wouldn't be allowed
f13it would break every single person trying to install that package
and require modification of default repo files
and the license clearely states that you don't have to require people get the source
f13"You need not require recipients to copy the Corresponding Source along with the object code."
XulChrisok ill pass that along to upstream and see what they say
tibbs|hBTW, I asked a similar question regarding javascript and was told that we only need to worry about our own source distribution requirements, not those of people who might install webapps and such.
bpeppleok, any other questions, or should we wrap up today's meeting?
(or however you spell it)
bpeppleah, forgot.
bpepplejwb: floors yours.
f13apparently it's being "worked on"
jwbseems to be a massive sea of broken deps.
is there anything that needs more attention?
(because we have so many ocaml hackers...)
f13Richard Jones said it was all in his court
tibbs|hAll ocaml deps will break any time pretty much any piece of the ocaml environment changes.
bpepplejwb: yeah, the rawhide report is giant these days due to all those broken deps.
f13Just to keep people updated, upstream OCaml made some small but
significant change to a library which turns out to break lots of
packages. So this is going to take some time to get fixed.
Details here and in the follow-up messages.
nirikI thought it was upstream changing something that they thought wouldn't do much, and it broke the world.
nirikyeah, that
tibbs|hFolks need to get used to seeing lots of ocaml broken dependencies; it is the nature of the beast.
jwbf13, is there any possible way to filter those to the end of the report?
jwb: meh... maybe? But is that really what we want?
bpeppleprobably not.
tibbs|hIf the ocaml broken deps swamp other useful information, then perhaps.
f13maybe instead we could corner richard and get him to show us the simple fix, and send a few minions out to all the packages to fix with patches for now.
jwbwell, in the long run no.  but i'm wondering if people are simply missing broken deps that could be fixed because of the flood
right, what tibbs|h said
f13jwb: people still get individual mails for the broken deps they own
tibbs|hBut I wouldn't expect them to persist for all that long.  The fix is known; it just needs to be implemented.
jwbf13, we have this thing called 'provenpackagers'
tibbs|h(Note that I know only a little about ocaml.)
jwbthey don't get emails other than the rawhide report
f13jwb: a proven packager should be able to ... read.
bpepplef13: Is that working? I have a broken dep, but haven't gotten a reminder.
f13bpepple: are you the recipient of <package>-owner@fedoraproject.org ?
bpepplef13: yeah. swfdec-gnome.
Maybe my spam filter is being to aggressive, tho. I'll have to give a look.
f13bpepple: it's possible mail is falling over somewhere.
* nirik would also think this would be a good time for a Ocaml SIG to help out... if there is anyone besides Richard.
bpeppleso, going back ocaml, does anyone want to contact richard and see if we can give him some help.
* nirik can mail him if no one else will.
bpepplenirik: thanks! I was hoping not to have to do it. ;)
jwb: anything else in regard to ocaml you want to discuss? otherwise we can probably wrap up the meeting.
jwbnope, that was it
bpeppleok, if there is nothing else let's call it quits.
nirikbpepple: you do too much already. ;)
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!