--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod
Hi everybody; who's around?
* nirik is here.
Kick__ is here
jds2001 here
jwb is here
notting is here
rwmjones here
bpeppleok, I see more than half of FESCo, so we can probably get started.
--- bpepple has changed the topic to: FESCo-Meeting -- MinGW - all
dgilmore    /me is here but has a $DAYJOB meeting also
rwmjonesbpepple, https://hosted.fedoraproject.org/fedora-infrastructure/ticket/807#comment:20 might be a good place for everyone to start?
rwmjonesor https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-oct-13
bpeppleAlright, rel-eng came back with an answer that they didn't feel the effort involved with setting up a seperate repo for MinGW was worth the benefit.
* nirik nods.
jds2001that's fine with me, for this instance.
rwmjonesalso, FPC approved the package guidelines with one alteration which I've made (mingw -> mingw32 renamed everywhere)
nirikdwmw2: you aren't around? you were the one pushing for the seperate repo, right?
jds2001however, it doesn't cover *other* cross-compile enivronments where the result might not be useful on the host.
* dwmw2 awakes
dgilmorejds2001: the level of work scales linerally
jds2001dgilmore: yeah, i know :(
* nirik never really saw the point of the seperate repo, unless just as a proof of concept for other things like this someday.
dwmw2why would the result not be useful on the host, for other cross-compile environments?
jds2001but since the result can be used in Fedora, I'm fine with it.
dgilmorejds2001: so each time a new repo would be requested it adds significantly to work loads
dwmw2one needs wine, the other needs qemu-arm. But I can run both just fine.
abadger1999dgilmore: We could make one separate repo for all cross compiled environments vs one per cross compiled env.
* jds2001 didn't know about qemu-arm. But would that not be more considered a secondary arch effort?
dwmw2If releng don't want the separate repo, then let's drop it for now. When we end up getting other cross-compilers working I'm fairly sure we'll realise we _do_ want separate repos, but if we don't want to look ahead right now, so be it.
abadger1999Then the scaling would be different.
dgilmoreabadger1999: we could
dwmw2jds2001: actually I don't use qemu-arm
I _do_ use qemu-i386 :)
dwmw2on my shinybook I can build and run i386 binaries.
I even just about got the flash player running in i386 nspluginwrapper once
rwmjonesso from mingw p.o.v we feel that we've now crossed all barriers to getting the packaging guidelines approved, so we can begin package reviews.  Is that right?
jwbok, so go forth and conquer then?
bpeppleok, so is everyone fine with dropping the seperate repo requirement for now, with the option to revisit down the road when we work with other cross-compilers?
nirik+1 here
jds2001+1 here
bpepplenotting, dgilmore: any options?
bpepplealright, I see 6 '+1', and one '0' to dropping the separate repo requirement.
so, it's been passed.
rwmjonesand http://fedoraproject.org/wiki/PackagingDrafts/MinGW can become a real packaging guideline?
jds2001I thought we approved that earlier.
rwmjonesjds2001, FPC approved it with that change of mingw -> mingw32
rwmjonesnot sure if FESCo actually said yay
jwbso if it's approved by FPC, you're done
jds2001right, and we approved the FPC report from that week.
rwmjonesok, fair nuff
bpepplerwmjones: I believe we had no objections to the FPC approval.
rwmjones: anything else regarding MinGW we need to discuss?
rwmjonesnot from our point of view ... does the wiki page need to be renamed under the official packaging space? (I can't do that)
danpb_ltopbpepple: don't think so - the separate  repo  & packaging standards were only thing we were waiting for
jds2001abadger1999: can you talk care of that?
danpb_ltopboth are addressed, so I think we're all set to proceed
bpepplerwmjones: Yeah, someone from FPC should be able to move it for you.
rwmjonesok, I'll mail someone from FPC
bpeppledanpb_ltop: great.  Thanks for all the work rwmjones and you have done on this.
rwmjonesit certainly has been a long journey
jds2001thanks for sticking with it through all this, too. It's really appreicated.
bpepplerwmjones: yeah, definitely.
abadger1999rwmjones, jds2001: Will do
bpepplealright, if there's nothing else we can move on.
--- bpepple has changed the topic to: FESCo-Meeting -- https://fedoraproject.org/wiki/User:Pertusus/Draft_keeping_infra_open_for_EOL - all
bpepplePatrice wanted us to consider his proposal.
dwmw2I think it's a bad idea to promote the _illusion_ of having updates, when critical flaws may go unpatched
nottingi think this is a profoundly bad idea
jds2001i think that notting summed it up the best.
nirikI'm worried that putting the Fedora name on something thats not maintained up to our standards.
bpeppledwmw2: yeah, that's my concern also.
dwmw2seriously, just use CentOS
dgilmoredwmw2: i agree
dwmw2by the time you've actually worked out what people want that's actually _achievable_, it's CentOS
jds2001I'm not surte what need this would meet that's not solved by CentOS/RHEL, personally.
dwmw2"Pick a Fedora release every 18 months or so, and keep doing updates for it"
it would be nicer if you could easily update from a given Fedora release to a given 'matching' CentOS release
dgilmorethere is no detail in that proposal on how to manage the transition to a EOL product.  no mention of how packages will be signed and pushed
dwmw2but that could be just a matter of documentation
nottingif there is a concrete desire to have a (somewhat, not 3-5 years) longer support term, that's probably an idea that needs to go by the board level
nirikalso, there is no mention of when it ends...
dgilmorethere is way to little detail for it to be seriously considered
dwmw2notting: true
nottingwhich would be a much better way to accomplish this
jwbignoring all that (which is a lot), there is the issue of just keeping the infrastructure active for this.  and that itself is not small
dwmw2I also think we should stop being so discouraging about FedoraN->FedoraN+1 upgrades
nottingbut if you want 3-5 years of support (which was mentioned in the mail thread)... use RHEL or CentOS. seriously.
jds2001dwmw2: how are we discouraging that?
bpeppleabadger1999: I noticed you were active on this thread.  anything you want to add?
dwmw2fsvo 'we'
nirikI propose we add our concerns to the discussion page and ask the Board to discuss this? since it's a high level long term goal, not a tech detail...
dwmw2talk about it on #fedora, you'll get a handful of muppets saying "upgrades don't work; just reinstall"
* jds2001 actually does do reinstalls, but nothing says I must
dgilmorenirik: +1
dwmw2I do upgrades. With yum. On remote, headless boxes.
nirikdwmw2: I try and correct them as I see them... I can also get the ops to do so
dwmw2at weekends
dgilmorei do remote yum upgrades
jds2001dwmw2: that works too :)
bpepple+1 to nirik's proposal.
wwoodspreupgrade is actually sensible now
abadger1999bpepple: Not really.  I like a Legacy idea but I think they're putting the cart before the horse.
dwmw2nirik: +1
nirikI tend to point people at http://fedoraproject.org/wiki/DistributionUpgrades , which perhaps could use some more work...
jds2001nirik: +1
jwbf13, you ran Fedora Legacy.  any comments?
bpeppleabadger1999: yeah, I don't see anything in the proposal that solves any of the problems that fedora-legacy had.
nottingnirik: +1. the proposal speaks to infrastructure, use (more or less) of Fedora trademarks/brand, and project goals. which are all above the FESCo level of 'just open CVS'
Kick__+1 to nirik's proposal
notting(if i inferred to patrice that he should bring it to fesco, i apologize)
jds2001I would also like to add a derivative distro is more than welcome to setup their own infrastructure and maintain whatever they like.
just not called Fedora.
f13There is truth to that a big part of LEgacy's failure was infrastructure
however, it was also a very convenient excuse to not participate
bpeppleok, could everyone add their comments to the discussion page, and I'll contact Patrice and the board.
f13I also think that we have this argument/discussion in very predictable cycles.
nirikdoing security backport updates is hard thankless work...
nottingf13: but it's not FESCo's domain to authorize the use of infrastructure in this manner
f13right about the time where the current RHEL release is getting a bit long in the tooth, and the next RHEL release is a little far off
jwbf13, yeah
j-rodI suck
jds2001j-rod: spare us the details :)
f13I expressed most hte concerns I have on the mailing list
bpeppleok, is there anything else anybody wants to add on this? Or should we move on?
* j-rod rethinking this "1pm is fine for me!" decision...
bpeppleok, moving on then......
--- bpepple has changed the topic to: FESCo-Meeting -- Do we really don't want Zope/Plone in Fedora? - https://fedorahosted.org/fesco/ticket/8
jwbhow many of us were on FESCo for this discussion when it came up the first time
* notting waves
jwbme, notting, bpepple ?
niriklast time we determined that the maintainer can decide he doesn't want a compat package.
* nirik was here.
bpeppleI personnally don't think anything has changed since we decided on this a year and a half ago.
f13I was
jwbthe only thing that has changed is that we have new FESCo members
jds2001jeremy has made it quite clear that he doesn't want a compat package.
f13the proposal has been tweaked slightly
jds2001and there are good reasons for that.
f13oh wait, that proposal.  Sorry
abadger1999I have a thought on this... but I don't know that it's appropriate for Fedora...
jwbthoughts are welcome
abadger1999Is RHEL 6 going to support zope/plone installs on top of it?
nottingthat is... a rhel 6 issue
jds2001unlikely if they get a new python.
abadger1999If so Fedora should be figuring out how to do this... maybe by looking at what Debian does.
jwbabadger1999, s/Fedora/Red Hat/
jeremyabadger1999: with my red hat hat on, I would even more vehemently oppose it there
nirikthey ship a compat python
abadger1999notting: Right... why I said it wasn't necessarily an appropriate thought for here :-/
nirik: and they have support infrastructure so they only have to ship one version of modules.
abadger1999That would be an interesting thing for us to look at *if* we allow a compat-python in the first plae.
nirikthey do? they have modules that work against any python version? how?
abadger1999The source code itself works with multiple versions.  Then they have a package that manages a symlink farm and compiled byte code somehow.
abadger1999I haven't looked too closely as we don't have compat-python to worry about yet.
jds2001abadger1999: how do you gurantee source compatibility?
jeremyabadger1999: I have plenty of source code that won't work with multiple versions of python
* Kick__ think allowing compat-python will open up a can of worms with lots of problems for our system-config-* tools if we aren't very, very careful
danpb_ltopthat's over-engineering a solution to a problem that should never be addressed - if zope community is unable to keep up2date with python it should be left to die a horrible death
* Kick__ agrees
abadger1999jds2001: How do we guarantee that upgrading python versions now is going to work?
jwbok, this is simple: is there anyone on FESCo that thinks this is a _good_ idea?
jds2001abadger1999: we don't.
jeremyabadger1999: that's why upgrading python versions is done very early in the cycle and takes a whole lot of work on the part of the python maintainer
bpepplejwb: I don't think it's a good idea.
nottingi don't. although i'm trying to think of if there's a similar analog that we *do* ship
wwoodsmultiple JREs.
abadger1999jds2001: we forward port.  debian is also sending patches upstream to keep backwards compat.
nottingthere's gtk1/gtk2 but there's no infrastructure around those
wwoods: we don't ship that
abadger1999But like I say, this might not be for us :-)
danpb_ltopnotting: that's different they're explicitly incompatible APIs
wwoodsnotting: I know. But the same brain-damaged worldview that thinks that's a good idea
and keeps demanding the ability to do so
nirikdid we formalize the 'maintainer is allowed to block compat packages' guideline?
wwoodsis at work here.
jwbnirik, i don't think so
* jeremy thought that bpepple finished it up and we voted on it
bpepplenirik: no.  I think it was more of a case that we agreed with the maintainer.
Kick__didn't the maintainer change in the meantime ?
* abadger1999 notes that upstream python-distutils is working to add that brain damage to python.
nottingright now, we ship a pile of compat-* stuff. some of it even for development
abadger1999But I'm hoping the other distro packagers and I are doing something to stop that.
nottingso we don't necessarily  forward-port things
abadger1999Kick_: Yes.  was jeremy, is now geppetto
nottingmmm, a python puppet master
Kick__did he voice his opinion ?
* pjones beats his head against FIPS140 hoping for a concussion.
jds2001pkgdb lists it as James Antill
* Kick__ suspects he won't support compat-python
wwoodsjds2001: /whois geppetto
abadger1999I pinged him on #fedora-devel just now.
bpepplenirik: yeah, I brought that to the lists, and was met with significant push-back on the proposal, so I dropped it.
nirikok, odd. It seems reasonable to me at a quick glance.
bpeppleThat's what I thought also, but some folks we pretty vocally opposed.
jwbthe same folks that were advocating for compat-python?
* nirik suspects so.
bpepplejwb: possibly.  I'd have to look at the mailing list archives to refresh my memory on who was opposed.
abadger1999geppetto: This was brought up by Oliver Falks wish to maintain compat-python packages to get zope/plone in.
pjonescompat-python sort of seems sensible, but actually isn't.
abadger1999geppetto: Log of this discussion so far: http://fpaste.org/paste/7611
geppettoabadger1999: Yeh, as I said on the mailing list ... if all we care about is Zope/Plone ... then I don't see a big problem in dumping a python24 into that package (in theory as a short term solution) ... as long as it isn't providing any of the python provides
jds2001geppetto: would that not violate packaging guidelines, though?
geppettoBut there is a significant worry that actually having a big pile of compat-python* packages could screw up the real python install
danpb_ltopgeppetto: it wouldn't stop there though
jds2001having a local copy of what should ostensibly be a system binary
jeremygeppetto: fundamentally, it's beyond a short-term solution at this point
bpepplegeppetto: I don't think it would be a short term solution, since it's already been over a year and a half, and the problem still exists.
danpb_ltopgeppetto: because you then have apps which build / extend zope/plone
abadger1999spot: Your cue :-)
geppettojeremy: True, that's why I said in theory
danpb_ltopgeppetto: wanting more python compat add on modules
pjonesjeremy: also, this happens to zope with *every* python release, for the entire history of zope.
geppettojds2001: Well you could argue that, at this point, the Zope people have forked python and are using their own language ;)
pjonesjeremy: it's an endemic problem
jeremywe moved to python 2.5 in december of _2006_
geppettodanpb_ltop: Tell them Zope is it's own broken thing, and they need to get it in Zope, get Zope ported to the system python
bpepplealright, so it looks like no one is in favor of this proposal.   Am I right in this assumption, if so we can probably move on.
jds2001+1 to moving on
bpeppleok, moving on then........
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
dwmw2weren't we having this discussion a year ago? Just fix it, ffs.
bpeppledwmw2: +1
geppettodwmw2: indeed we were, big thread/flamewar then too
bpeppleok, that's all I had for the today's agenda.  Anything else folks want to discuss?
what reviews have you done this week? :)
nottingnone. sorry.
* jds2001 has mentored ke4qqq :)
dgilmoredwmw2: none
dwmw2It _can_ be a rhetorical question
bpeppledwmw2: https://bugzilla.redhat.com/show_bug.cgi?id=456038 :)
buggbotBug 456038: medium, low, ---, bdpepple@gmail.com, ASSIGNED, Review Request: DarkIce - Live Audio Streamer
tibbsI haven't done nearly enough.
Kick__none, no time unfortunately
dwmw2seriously though, do we want to undertake "FESCo members will _try_ to work on at least one review a week" ?
tibbsBut there's still plenty of week left.
jds2001dwmw2: I think it's a worthwhile goal.
dwmw2I did one of the LXDE packages after last week's meeting; I should pick another one now
bpeppledwmw2: I'm fine with doing that.  I'm not 100% sold that we should check each week during meetings, though.
j-rodI'd rather not. I already have way too much going on to try to mix in a review a week.
* nirik has been working on doing a few, but didn't finish any this week.
dwmw2bpepple: yeah, the concerns about that were sane.
dwmw2j-rod: I did say _try_, and if you're busy, that's fair enough.
j-rodnow, if $dayjob were Fedora-centric instead of RHEL-centric, it'd be different, but my own time for Fedora stuff is currently being spent on lirc.
dwmw2if you ever find yourself at a loose end, though... :)
in your Copious Spare Time
bpeppleI think the suggestion to review the weekly stats on reviews was good, also.  I'm going to try to contact Christian to see if we can get those running again.
jwbdwmw2, i upgraded two packages and completed a u-boot-tools review
j-rodI have kids, there is no such thing
dwmw2I need to train myself so that when I'm bored and pissed off with real work, I look at reviews
Kick__I don't think we few people will help with the massive backlog, It'll be better to get more maintainers to do reviews
jwbdwmw2, ironically, the two packages were yours
dwmw2jwb: heh
tibbsI wouldn't suggest reviews as an antidote for being pissed off.
dwmw2Kick__: I agree. I'm hoping to set an example... set a trend.
bpeppletibbs: ;)
pjonesjwb: dwmw2: this would be the two reviews that I didn't finish last week, right?
dwmw2pjones: heh. That would be cool. Although I might need someone to take on maintenance of those too, since I have IT muppetry going on and they want me to stop publishing that.
pjonesok, so I still need to finish those then.
bpeppletibbs: you mind if I try to set-up a reviewers meeting to talk about ways to make it easier to do reviews?
dwmw2pjones: would be appreciated; when you do, please set the CVS request too? That way, I don't have to do it myself. And don't have to be shot for it.
pjonesdwmw2: yeah, uh, I'll review things for you, but you don't want me maintaining more stuff ;)
tibbsbpepple: Please.
dwmw2I know
tibbsMy life is still a bit chaotic.
dwmw2I'll cross that bridge when I come to it :)
bpeppletibbs: ok, I'll try to send an e-mail in the next day or so, to get the ball rolling on that.
tibbsI have a list of people who expressed interest in a package review sig.
bpeppletibbs: cool, could you forward that list to me, and I'll make sure to cc those folks.
dwmw2do we need to vote on the proposal I made?
jds2001i thought we already did?
last week
bpeppleDoes anyone object to dwmw2's proposal?
dwmw2did we?
jds2001+1 at any rate :)
nottingwhich one?
nirikI'm not sure what good the proposal does... but whatever.
jds2001try to do a review a week
dwmw2just that we'll _try_ to do at least one review a week.
in the hope that we set a trend :)
nottinghm, i suspect that it will just lead to channeling yoda
do or do not. there is no try
- yoda
We accept that some people _won't_ have time, and they have good reasons for that.
that's why I say 'try'
we could go for SHOULD, cf. RFC2119
bpeppledwmw2: +1 to having FESCo members try to do at least one review a week.
dwmw2but that's just nit-picking
nottingi am not against the concept of having FESCo members set good examples on this front. i just wonder how much codifying it matters
* nirik agrees with notting
dwmw2not at all, really.
dwmw2although if the idea is to set an example, part of that comes with _saying_ "FESCo has _agreed_ that we'll try to review at least one package weach, per week"
nirikHow about fesco members try to read all devel mailing list posts, try to spend 8 hours in #fedora helping people, try to help old ladies accross the road.
tibbsI will note that significant progress has been made on the review queue recently.
nottingnirik: sure, aaaugh, why not. in that order ;)
bpeppledwmw2: I'll add something to that affect in my meeting summary.
tibbsThe queue of non-merge reviews is about 15% shorter than it was a week or so ago.
nirikAdding a bunch of 'tries' doesn't sound productive. ;) I think we can agree to try and do reviews, but making it a formal proposal and such doesn't seem needed to me.
tibbs: it seems like influx has been down. I haven't seen that many new reviews coming in.
tibbsThere has been a reasonable number, I'd say.
tibbsWe didn't get bombed, no, but it's still several per day.
bpeppleok, it looks like we're winding down here.  Is there aything else we need to discuss? Or should we start to wrap-up for this week?
nottingtheoretically, there is a point at which new package requests *should* slow down
tibbsTrue, but I don't think we're there.
tibbsThat point is probably somewhere around "more packages than Debian" which I don't think we're at yet.
bpeppleok, going to start the countdown.....
* bpepple will end the meeting in 60
niriktibbs / bpepple: has the owner of https://fedorahosted.org/review-o-matic/ talked with you guys?
tibbsNever heard of it.
bpeppleme neither.
* nirik just noticed the request to create it today
* bpepple will end the meeting in 30
bpepple will give it a look over.
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!