--- jds2001 has changed the topic to: FESCo meeting -- init
jds2001FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* nirik is here.
jwb is here
j-rod is back in the saddle
sharkcz is here
jds2001sorry for the time confusion
* dgilmore is here
jds2001DST should be abolished.
--- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
dwmw2we should build a big dome over 95.8% of the world and abolish timezones completely.
jds2001let's get started....
dwmw2: :)
why 95.8%?
jds2001oh, im a little slow :)
jds2001.fesco 57
zodbotjds2001: #57 (Make stronger policy/guideline that ABI/API/soname breakage should always be announced fedora-devel-announce (not f-d-l)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/57
dwmw2how much does this actually help, in practice?
jds2001likely none.
dwmw2don't we already get automated warnings when deps break anyway?
jds2001and im not sure that it's in the charter of f-d-a to mention day-to-day stuff
dwmw2I don't see the point in this, then
jwbdwmw2, perhaps preventing the breaks is what it's targeting
dwmw2if it was mailing the maintainers of the affected packages, maybe
j-rodyeah, I'm kind of of the mind that shouting louder doesn't really help anything
dwmw2but they'll get mailed anyway once you break it :)
j-rodhaving a heads up that something is going to break is nice tho
i.e., advance notice instead of ex post facto
dwmw2in the good old days, the person breaking it would just rebuild the affected packages...
jds2001yeah, that already happens on f-devel.
* notting is here for the moment, but may need to drop out
dwmw2advance notice is nice; I'm not sure we (FESCo) need to get bureaucratic about it
jds2001dwmw2: they still can, if they're in provenpackager
dgilmorei suggest we come up with a easy way to detect things that will break so they can be fixed by the person breaking them
j-rodmy f-d and f-d-a mail all goes to the same folder anyway, so I care not
nottingdgilmore: repoquery -q --whatrequires <yourpackage> --alldeps
dwmw2dgilmore: don't we already have that?
jwb'make what-will-break'
dwmw2maybe there could be an immediate mail to the affected package owners, as soon as the 'breakage' hits rawhide/
dgilmorenotting: sure.  i guess ill add a im-gonna-break-shit wrapper to fedora-packager
jds2001that would be cool.
nottingdgilmore: you could fancy it up by iterating over the library provides of the package, so it doesn't catch things that require /bin/<whatever> from the package
j-rodooh, could it be a cvs pre-commit hook so we can slow down cvs even further? :)
j-rod(usage of cvs, that is)
jds2001so as for this proposal, I'm -1.
dgilmorenotting: yeah
dwmw2there are better ways to deal with this
dgilmore-1 for the proposal
notting-1. f-d-l (or mailing those affected directly) is fine with me
sharkczI agree, -1
jwb0.  there's obviously a problem with how it is today, but i'm not sure this is the solution
* nirik is also 0. I think this could add noise to the announce list.
jds2001i see five -1's, two 0's, and one -0.5 :)
so we've declined this proposal. Other ways of finding breakage are better.
jds2001.fesco 67
zodbotjds2001: #67 (How to deal with Requires.privates in pkg-config) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/67
jds2001I'm not entirely sure if we've already covered this one or not.
or if it's even our ball of wax, or is it FPC fodder?
nirik.whoowns pkg-config
zodbotnirik: No such package exists.
nirik.whoowns pkgconfig
zodbotnirik: mclasen
abadger1999Anything about telling the pkgconfig maintainer what to do would be FESCo.
abadger1999anything about how to deal with the way pkgconfig works would be FPC
jds2001OK, I misunderstood the ticket I guess.
dgilmoreis it really a problem?
dwmw2we discourage static libraries. Presumably we shouldn't be caring too much about the behaviour of pkgconfig --static
niriksome of this would be moot due to the mass rebuild wouldn't it?
dwmw2so we should probably restore the patch we had before.
nirikie, maintainers already fixed things to work with the current config.
jds2001yeah, this is old.
* nirik dislikes fesco butting in and telling the maintainer what to do. Perhaps they have good reasons for it?
nirikmclasen: can you take a look at https://fedorahosted.org/fesco/ticket/67 and see what you think?
dwmw2I'd certainly not like to make a decision without ... oh, there he is :)
jds2001reporter is listed as bpepple, not sure if he's the "real
jds2001" complainant or opened it for somebody
mclasennirik: I first reverted the patch we carried in rawhide, since people complained that the Fedora pkgconfig didn't match upstream
then I reverted it in F10 and F9 since other people complained that rawhide didn't match the released distros
there's no way to make everyone happy here, I fear
j-rodI'm all for matching upstream.
mclasenI will not reintroduce the patch in rawhide, in any case
and bringing it back in F9 and F10 may only muddy the waters further
mclasensince some packages have already been fixed to build with the current (upstream) behaviour...
jds2001and asking folks to fix it for F9 and F10 when they update isn't that much.
j-rod+1 for matching upstream. if it needs to be changed somehow, push the change upstream.
* nirik nods at j-rod and mclasen
j-rodless patches is moar gooder
nottingj-rod: so, you're saying no change from what we currently have/
* mclasen notes that he only added the patch very reluctantly in the first place (after prodding upstream for months about it)
jds2001so i guess the proposal is to keep everything as we have it now.
+1 to that.
* mclasen goes to feed the guinea pigs
niriksorry to bug you mclasen, and thanks for the input. ;)
jds2001i see seven +1's, so pkgconfig will stay matching upstream.
thx mclasen :)
jds2001.fesco 79
zodbotjds2001: #79 (Lenient hash check for noarch subpackages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/79
jds2001did we already cover this in the past?
* jds2001 is not insane then :)
jds2001well, maybe I am, but that's for another time :)
dgilmore-1 to this
dgilmorethere are way to many corner cases that could cause a build to be failed.
nirikIt could cause more failures, but shouldn't we fix those cases?
dgilmoreits not something that we can do for builds that are noacrh only
jds2001im not exactly sure how this would be implemented in practice. Build once on ppc, and once on x86 for anything with a noarch subpackage and rpmdiff the subpackages? Seems to increase builder load to me, unless I'm completely dense.
dgilmorejds2001: this is noarch subpackages only
abadger1999There are corner cases.  But my thinking is that falsely keeping something from being noarched is better than letting it be noarched incorrectly.
jds2001dgilmore: right, but how do you get the target of the rpmdiff?
dgilmorejds2001: i guess i dont understand your question
dgilmorejds2001: noarch subpackages are built on every arch
jds2001oh, right :)
* jds2001 is assuredly dense.
jds2001 faceplants
nottingso, this is applying stringency to noarch subpackages that we don't actually apply to noarch packages?
nottingthat seems conceptually fishy to me
j-rodapplying it to both would require that fully noarch packages be built on more than one arch tho
instead of building only on the first available builder
nirikwhich would add build load.
jds2001j-rod: right, and that's where i was originally going.
dgilmorenotting: right.  thats part of why i object to making things stricter
nottingright, but if we're trying to prevent noarch packages accidentally being archful... we should be checking both
j-rodwhat's the current algo to decide which build of the noarch sub-package gets into all the trees?
(or does each arch tree take its own?)
* mclasen would like to be able to declare a doc package noarch, even if it contains arch-dependent things due to insufficiencies of gtk-doc...
abadger1999notting: I think so too but I don't have a way to tie that into koji yet :-)
OTOH, noarch subpackages are a bit riskier.
for instance, people have been wanting to make header files noarch.
j-rodyeah, fail.
(at least for the kernel...)
nottingabadger1999: seems like excess complication for not much benefit
j-rodI kinda figure people will not be dumb, and if a problem crops up, a bug will get filed, and it'll get fixed
abadger1999notting: Well.. currently we're doing more checks against noarch subpackages... we just happen to turn off the hash check
j-rodof course, figuring people will not be dumb is probably dumb
abadger1999So there's no extra steps in the big picture... we're allowing the script to run more things.
abadger1999mclasen: That's actually an interesting thing.  I found a noarch package that was broken in documentation containing arch-specific things manually... but this check would not catch it.
j-rodso now why is this a fesco thing and not a packaging committee thing?
abadger1999mclasen: Assuming that the doc was properly marked %doc.
mbonnetdgilmore and I agree that what we have now is decent in terms of leniency, and anything else will cause too many false positives
abadger1999j-rod: This is fesco because it affects checks that the build system would do.
nottingmbonnet: can you answer j-rod's question about where the noarch subpackage that gets stored by koji comes from? first build to finish? other?
abadger1999If it fails here, FPC will have to decide what to allow in terms of noarch subpackages and whether reviewers need to check it.
And how reviewers would check it.
mbonnetI suggest the way to deal with this more completely is for someone to do post-build checks and file bugs.  It should be outside the build system.
j-rodabadger1999: ok, gotcha, thank you for the clarification
abadger1999racor thought FPC might want to say headers are not allowed to be noarch, for instance.
mbonnetnotting: basically first-built
abadger1999I'd rather a build check so that most headers could be noarch.
mbonnet: Show me concrete false positives.
mbonnetabadger1999: we have
j-rodmbonnet: so in that case... what gets into koji really isn't any different than what goes in for pure noarch packages right now
mbonnet.pyc/pyo's for instance
abadger1999mbonnet: No, you haven't given me a single package that fails.
abadger1999mbonnet: pyc, pyo does not fail the current check.
j-rodfirst free arch builds noarch packages, first finished build wins the noarch sub-package race
abadger1999And also, only a few pyc, pyo will fail.
mbonnetabadger1999: that's because you whitelist it, which I think isn't a scalable solution
abadger1999if htey happen to have a very large constant in them.
mbonnetj-rod: correct
abadger1999mbonnet: A whitelist is exactly what I'm asking for.
Things that are different between builds on different arches and are not known to be good need examining.
mbonnetabadger1999: and I'm saying that's exactly what I don't want to do, because we'd need a koji outage everytime we need to update the whitelist, which I think is unacceptable.
abadger1999Whitelisting things that we know are good is safer.
mbonnet: I asked whether you import rpmdiff. Do you?
dwmw2hm, must go get inhalers for wenchlet, lest she die over the weekend; sorry.
abadger1999Or so you invoke it as a script?
mbonnetabadger1999: as a script, but that's not the point
j-rodin my mind, this seems a bit pointless unless we're also looking at all the pure noarch packages for the same sort of issues -- there are a lot more of those, and they're often more critical content then what people are presumably putting into noarch sub-packages (like docs)
mbonnetj-rod: +1
abadger1999docs are whitelisted by checking if they're marked %doc.
mbonnetalso, problems like archful headers being marked noarch will be found *very* quickly by subsequent builds/testing
abadger1999But I don't want to have packagers and reviewers having to manually check header files.
j-rodpackagers would willfully have to change headers into a noarch sub-package right now. presumably, they'll actually inspect the content they're moving to see that they aren't doing something they shouldn't.
nottingj-rod: +1
jds2001abadger1999: how do you get around that?
abadger1999mbonnet: Really?  if I have #define 64bittype long long, won't that be 64 bit on both 32 and 64 bit?
mbonnetabadger1999: if so, how is that not noarch?
jds2001abadger1999: header files are header files - md5 is the same. Doesn't mean they'll work on that arch, but the hash would be teh same.
abadger1999mbonnet: So if build 1 takes the noarch package from a 64 bit build, things start failing, build 2 takes it from the 32 bit build, things mysteriously start working again
j-rodexcept when they aren't the same... :)
j-rod(in reply to 'header files are header files')
mbonnetabadger1999: I'm not saying there aren't cases or archful header files, I'm saying it's not the job of the buildsys to detect them.
Rathannabadger1999: long long could be 128bit on x86_64. if you want 64bit type, just use int64_t
j-rodcan those checks be simply run in informative mode?
abadger1999And I'm saying it's too much of a chore to stick it onto a reviewer.
j-rodi.e., have it trigger sending a notice to the packager?
mbonnetj-rod: not really, koji has no way of "warning" someone, other than failing the build
* mclasen keeps his archful headers below /usr/lib/glib-2.0 anyway...
j-rodah, ok.
abadger1999jds2001: headers are not always the same.  There are headers that are rewritten depending on the arch they're built on
mclasen: You're doing it right.
notting_abadger1999: right, what i'm saying is there really that much benefit to drilling down to that level for noarch subpackages?
abadger1999notting_: I think there is.  But it's before FESCo because there's a difference of opinion :-)
abadger1999We're potentially producing broken packages to optimize space.
nirikideally, for both noarch packages and subpackages we would keep all the builds from all the arches and run them thru the autoqa thing to detect this.
nottingabadger1999: no, that's what i mean - why bother with noarch header packages? just leave them archful
abadger1999and we can have a check that gives us most of the benefits of that optimization with just some corner cases failing.
dgilmoreabadger1999: right.  headers are quite often arch specific
abadger1999notting: That's fine. I can introduce that into FPC if this fails in FESCo.
mbonnetabadger1999: and when we find out they're broken, we'll fix them.  This is the same reason we don't run full test suites in the buildsys.
abadger1999notting: This just seems like the better way to go *to me*
abadger1999and FESCo is the place for that to be decided.
abadger1999mbonnet: We do run full test suites in the buildsys.
nottingabadger1999: i guess it's the other consequence, a pile of 1000 devel packages that all consist of a single .so symlink, that strikes me as wasteful
jds2001so where are folks on this?
abadger1999mbonnet: We don't run exterior test suites if that's what you mean.
nirikabadger1999: now that they are (hopefully) more noarch subpackages would it be possible to run it on the pool of them and see how many corner cases we have? or too hard?
* mclasen wonders how many headers subpackages we have anyway
abadger1999nirik: I could... are they still listed on that page?
mclasen: I saw one when I tested... it came through fine.
* nirik isn't sure.
jds2001we've got a lot more to cover today, and it sorta seems we're going in circles here.
0 to this.
notting-1, on the premise that we should check all noarch subpkgs
jds2001anyone else?
-1, with notting's comment
nirikI agree, but I kinda like it for catching things that should be caught... I'd like to see how much breakage we would see tho.
abadger1999In the previous test, there was only one false positive.
sharkcz-1 also with notting's comment
j-rod-1, what notting said
jds2001i see four -1's and one 0, so we've declined this proposal on the basis that if we do this, we should find a way to check *all* noarch packages.
dwmw2hm, I see I didn't miss much...
jds2001.fesco 89
zodbotjds2001: #89 (Select Fedora representative for LSB) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/89
jds2001dwmw2: nope :)
sharkcz: what's this all about?
dgilmorejds2001: so ive attended the last two lsb meeetings
so this is done?
nottingis this the point where we all shout "not it"?
sharkczbpepple will know more details and dgilmore volunteered
j-rodNOT IT
nottingnot it! :)
nirikdgilmore: anything of use in those meetings?
sharkczwe just wanted to have dgilmore's delegation formalized
notting+1 to dgilmore, then
jds2001+1 to dgilmore being fedora's lsb rep.
dgilmoreso far there has not been alot
jds2001awesome, so dgilmore is confirmed as the lsb rep. Congrats or condolences, whichever is appropriate :)
dgilmoremostly talk about a summit they have coming up
abadger1999(Appologizes for intel driver crash)
dgilmoreand some discuccion on adding motif to lsb
jds2001: thanks
j-rod+1 for not me. I mean, for dgilmore.
jds2001.fesco 96
zodbotjds2001: #96 (Document "Rawhide cannot go backwards" rule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/96
nottingdgilmore: heh, if they do that, fedora can't ever be lsb compliant
jwbah, backwards
so f13 brought this up a couple weeks ago
dgilmorenotting: thats what i said
jwbin that FESCo had declared that we don't revert epoch or release increases in rawhide
jwbas that would cause people to have to manually work around package stuff
nirikI think we stick it on http://fedoraproject.org/wiki/Package_maintainer_policy and be done with it.
jwband essentially make that package go backwards
jds2001right, this seems like common sense.
nirik: +1
jwbawesome, i'll stop summarizing
er, 1
dgilmorenirik: i agree
j-rod+1, "duh"
jwbin general though, we need to get better at documenting the rules we make
jds2001i see five +1's, so we'll add that to the maintainer policy
j-rodalthough... what happens if a package has to get untagged? new build reverting the change rather than going back to the prior package?
jwbj-rod, what?
jds2001jwb: agreed, I put the provenpackager stuff up.
j-rod"we're past freeze, this new build got in somehow, but it breaks the world"
jds2001j-rod: if it's not made it in a compose, just untag.  If it has, new build.
j-rodokey dokey
nirikyeah, if it's not been in a compose untag is still ok...
jwbwhich is interesting around freeze time :)
nirikand we should feel free to override the rule if there is a critical enough reason.
jwbso who is going to write this up?
* jwb will try
jds2001 thought he heard nirik volunteer :)
jwbor if nirik wants to, i'd be happy to review :)
nirikno no, that was jwb. ;)
jwbok, i will
nirikI'd be happy to review too...
jds2001.fesco 99
zodbotjds2001: #99 (Review FPC items) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/99
jds2001so we've got explict requires again - https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
wwoods(parental advisory)
nottingi thought we approved that last week?
jds2001+1 to ExplicitRequires
did we?
* jds2001 missed half the meeting
nottingsee http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090306
jds2001if so, moving right along :)
jds2001.fesco 108
zodbotjds2001: #108 (Would be good if there was an acl for "let all packagers edit this package" in pkgdb) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/108
jds2001: there was a second item there...
in the fpc list
troublesome source urls
jds2001yeah. i figured both were approved last week, were they not?
j-rodor did we already cover that too? (I don't remember it)
jds2001yeah, it's listed as approved.
j-rodoh. so we did.
nirikI thought we did approve them both.
* j-rod must have not been paying close enough attention...
jds2001halfline: you around?
nirikmmcgrath: you around?
mmcgrathnirik: word up?
jds2001this is halfline's proposal to include a checkbox in pkgdb to allow all packagers to commit to a package
i.e. not just provenpackager and maintainer.
nirikso my take on this: we shouldn't change anything on this just now and we should get someone (or someones) to do up a threat assessment.
mmcgrath: you offered at one point, were you serious? or just part of a discussion?
halflineshould probably get tibbs in here, no?
jds2001tibbs|h: ping
mmcgrathwhat did I offfer?
* mmcgrath is missing some context or something
jds2001mmcgrath: 18:16 < jds2001> this is halfline's proposal to include a checkbox in pkgdb to allow all packagers to commit to a package
nirikmmcgrath: to write up a threat assessment... but perhaps I am full of it, and it was not you. Let me look again.
mmcgrathI don't think it was me but it's something we've discussed before.
I haven't looked that closely at it but I'd say this.
dwmw2I see no reason why we should forbid package maintainers from choosing to allow this
mmcgrathI tend to agree.  I think being open is good, especially since someone in packager could just attack their own package anyway.
jds2001dwmw2: i just fear that in time we'll end up right back where we started.
* dgilmore is ok with having people allow packager to commit to there packages if they want. they do need to understand that means every packager can touch there package. including those just sponsored
mmcgrathThe initial threat comes from someone opening up a more popular package and attacking it.
nirikI am very tired of us changing things around. I would like someone or group of someones to write up a real model that explains the threats and how to protect from them and what cost. Then, I would like to change everything one last time based on that model.
* notting agrees with nirik
dwmw2jds2001: I'm not sure we end up back where we started
nirikthe reason this was removed in this specific case was that sponsors then don't like sponsoring people.
dwmw2this doesn't affect the 'want more people to allow provenpacker, so want fewer provenpackagers' dance.
nottingnirik: i'm sure moving to git fixes this
niriknotting: well, that might fix the cvs commit mail issue. ;)
dwmw2nirik: oh, I hadn't heard that one., That's... strange.
nirikdwmw2: so, if I sponsor someone now they get their own package only. If we allow this then they get their own package and all the ones that set this.
dwmw2nirik: that is the deliberate choice of the owners of those packages
nirikdwmw2: but it affects everyone who uses the distro.
jwbso does that package
dwmw2mostly those with tinfoil hats :)
jwbthat the person initially owns
dwmw2this is also true
jwbrpm runs as root, right?
mmcgrathnirik: I'll volunteer to do a threat assessment.
nottingjwb: rather hard to have it work otherwise
halflinei guess the thing is we need to make it clear it's not the sponsor's duty (or burden) to be a whipping boy when the person he sponsors makes mistakes
mmcgrathSpecifically who is my audience?  Who am I writing this to?
nirikI'm not opposed to doing away will all acls personally. I am very opposed to making partial changes all the time. We need a threat model so we can say 'this isn't worth protecting against' or this is solved with this measure easily.
jwbnotting, right.  so all it takes is a single package with %post rm -rf /
jds2001halfline: but it is their duty.
nirikmmcgrath: awesome. Well, I would say end users of fedora?
mmcgrathnirik: you sure you don't want me to write it to FESCo?
jwbnirik, isn't the audience the packagers?
dgilmorehalfline: we explicitly state that it is there place to do that
halflinejds2001: well i'd say that's wrong.  i mean the sponsor should be there to show the ropes and explain the process, but he can't be held strictly accountable for the actions of someone else
nirikwell, the end goal here is to provide a secure and as bug free os right? they don't care how we do it... clearly we need maintainers to maintain packages and update things
jwbaccountable for someone else's actions is different
halflinewe should hold people accountable for their actions, not the actions of others
jwbsponsors are mentors.  mentors should be watching for things
jds2001right, but who holds them accountable?
jwbthat doesn't mean they can prevent malicious intent
jds2001, who watches the watchmen?
nirikbut you are right, we need to take into account maintainers too, as they want to be able to do their job as easily as possible.
mmcgrath: so, perhaps it's from several views. ;(
mmcgrathnirik: but who's actually going to read the assesment and make changes based off it?
jds2001jwb: we do (i.e. we are responsible for sponsor oversight)
nirikmmcgrath: fesco.
jds2001and sponsors are responsible for their sponsorees
mmcgrathK, and you want me to focus just on CVS access?  Or also buildsys and on to distribution?
halflinei'd say maintainers should be responsible for their packages
and if a maintainer opens up a package
mmcgrathme assumes distribution is out of scope.
halflineit's that maintainers responsibility to watch the package
not the sponsor's responsibility to watch the package
nottingjwb: i haven't watched them, yet
jwbnotting, heh.  saw it last night.  was good
halflineif everyone agrees with me, then we should make sure hte sponsorship guidelines are clear
jwbhave you read the sponsorship guidelines?
halflineso that tibbs|h et al won't feel pressured by the 'packager' change
jwbis there something unclear about them?
nirikmmcgrath: I think distribution would be out of scope... depending on the line between that and buildsys.
mmcgrathnirik: k, I'll get to work.
halflinejwb: well i was saying above that i think their wrong
nirikmmcgrath: I think that would be great... although I seem to be the only one saying that, so you might see if fesco really wants you to move forward on this first...
jwbpeople are having there/they're/their problems today :)
jds2001nirik: i do, can't make a decision without being informed.
mmcgrathso should we +1 -1?  Anyone want me to write up a threat assessment to the current model?
* j-rod needs advil and coke, back in a few...
jwbmmcgrath, +
nirik+1 and I'm happy to provide info or feedback.
jwbthough i still claim it only takes one package to screw stuff up
halflineguidelines are here fwiw: http://fedoraproject.org/wiki/Package_sponsor_responsibities
nirikjwb: sure. But on what % of installed machines? and when is the problem detected?
notting+1 to mmcgrath writing a threat assessment
halflineand the guideline that I think should be fleshed out more is: "Sponsors also are responsible for fixing mistakes made by their sponsored maintainers if they are unable to do so."
jwbnirik, good point
halflineremember any package can obsoletes/provides any other
so from a "security threat" point of view
sharkczthere is an area for autoqa to check for at least some malicious actions in packages
halflinehaving access to one package is enough to take over
dwmw2obsoletes: kernel :)
nirikto a point.
if you do that then builds might start failing, or if you do it in release it might be seen at push time, etc.
jds2001so let's table this until mmcgrath comes back with a threat assessment.
just want to make sure we don't forget about the sponsorship guidelines when we consider this issue
nirikI think we could solve a lot of the threats or mitigate them, but we should do it all at once, not bandaid.
halflinealso would be good to make sure tibbs is around the next time this is discussed
nirikhalfline: what do you want that guideline above changed to?
jds2001sure., I'll cc him on the ticket
halflinenirik: well there should be an emphasis on the packager fixing his own mistakes. it's sort of weakly implied in the statement
nirikwell, I thought that was covered in 'if they are unable', but sure...
halflinethe only time a sponsor should be held responsible for cleaning up the mess is if the packager isn't competent enough to do it
it's wording thing mainly
jds2001halfline: either incompetent or unwilling
halflineand there should probably be something in their about how it's not the sponsor's job to watch every commit the pacakger makes to every random module
nirikor doesn't respond, or asks their sponsor to do it because they don't understand, or when it's serious and they are not able to do it in a timely manner, etc.
jds2001the latter obviously being more of a problem.
halflinejds2001: if they're unwilling to fix the mistakes they make
then they need to have their access revoked
i basically think the tone of the paragraph should be hinted toward the sponsor being a facilitator
not a watchdog
nirikhalfline: yeah, I'd be happy to change wording if you think it needs it... can you draft something?
halflineor a drill sergeant type thing
nirik: sure, i can come up with draft for you guys to chew on
i think that was tibbs biggest complaint, was he was worried it would add a lot of undo burden on sponsors
and i think that was just because we're not messaging what a sponsors responsibilities are quite right
jds2001that page also looks a little out-of-date
abadger1999halfline: Well... I think it is a change.
In the past we have said that a sponsor is quite responsible for their sponsorees.
halflineabadger1999: sure, i'm just saying it was fuzzy before and leaning toward a direction i think was wrong
abadger1999No problem.
Change that's more concrete is good :-)
nirikI think sponsors should be mentors/facilitators... but if there is a problem with someone people can ask them to talk to their sponsoree/fix issues/etc.
jds2001so shall we move on?
* nirik nods.
jds2001.fesco 21
zodbotjds2001: #21 (ext4 default filesystem) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/21
jds2001we said we'd revisit this one. Beta readiness meeting is on Tuesday, I'd like to take this opportunity to get a gauge on where we'
we're at.
jwbaside from KDE being dumb and freaking people out, i think we're in good shape
jds2001awesome :)
nirikso, hows ext4 looking sandeen ?
as default that is.
sandeenon fedora or on ubuntu?  :)  I haven't had many bug reports about it ....
i've found & fixed a couple bugs since alpha; the only one reported in fedora was the livecd creation problem AFAIK
jds2001cool, so I'd say we're good to go?
sandeenand I did put in the paranoid flush-on-close-if-truncated-and-on-rename to try to plug the holes for some of these apps that don't fsync
it seems like it
assuming people really have been using ext4 in alpha :)
nirikthe alpha live media was ext3, so we didn't get as much coverage there.
sandeentrue, I dunno how many people use that to install
jds2001lots i'd imagine.
sandeenI didn't get grub to grok ext4 in the end, btw, but I'm not too hung up about that
nirikso /boot will be ext3?
it's usually separate anyway due to lvm
* sandeen is used to a separate boot anyway so ....
jds2001yeah, not a biggie
sandeenhm, it'd be nice if smolts somehow kept track of if the systems were installed via livecd or via normal install
jds2001i assume it will grok ext4 in F12?
sandeenjds2001, I have a patch for it but haven't tested it yet TBH.  grub wasn't building in fedora for a while ... not a great excuse but just didn't get it tested
jwbis it really important either way?
sandeenif you don't use lvm it might be nice to not *require* a separate /boot
but *shrug*
jds2001not really, just curiousity really.
jwbeveryone seems to be all forgone on btrfs being in for f12 anyway
sandeenI don't think ext4 is *bulletproof* at this point but people seem to be surviving just fine :)
my only concern is the bugs reported outside fedora; I hope that this doesn't mean it didn't actually get much use in alpha
jwbthat's ok.  we're looking for enterprise, not military
sandeenbut, those are getting fixed too. :)
drago01sandeen: kill the flex_group printk
jwb(poor joke)
sandeendrago01, oh, yeah
ted did send a patch for that, too
* sandeen will do that today
j-rodI've pretty thoroughly beat the crud out of ext4 from an end-user point of view
no issues here anytime lately
jds2001cool. Anything else folks wanna bring up for the beta readiness meeting?
* jds2001 has nothing really, wondering what other folks have.
jds2001 assumes that means nothing :)
jds2001we have one more item, the CC repo
wanna push that to next week, or do we wanna discuss that now?
abadger1999sandeen: What will the default setting for ext4 be WRT the safety vs performance of delayed alloc?
Just asking what our mount options will default to.
sandeenthey'll be default
all this hubbub... the same window was in ext3, but smaller
sandeenI know that does matter in the end ...
so, I think we should leave delalloc on, but there are also these fsync patches added
they will probably get cleaned up before .30; but worst-case for beta is that they are a little heavy-handed
I'd rather be a bit slower and safer than run out of town on a rail by kde users ;)
nottingsandeen: do they print out which apps need fixed? :)
sandeen(the patches essentially sync the file on close if it has been truncated to 0, or if it is renamed over an existing file)
notting, I prefer the fs to not be a nanny
we could pop up a window saying "an application has requested a close without fsyncing. are you sure? [y/n/wtf]"
notting, in all seriousness I don't think we can know. it's the apps job to know if its data needs to be persistent at that point
* nirik needs to go soon.
jwbsandeen, complete with shifting sysfs paths for the kernel events?
drago01sandeen: can we have a  -o idontcareaboutbrokenapps mount option?
jwbdrago01, no...
I hope to make the fsyncing a bit less heavyweight so that if some other fsync handles it in the normal course of the file's life (if, say we come across some ap that actually does it...) it'll clear the sync-on-close flag
... this is how xfs does it
jds2001alright, shall we put a fork in this meeeting and delay the CC repo to next week?
we'll cover it first next week j-rod :)
dwmw2I thought we were trying for three hours...
* jds2001 ends the meeting in 15
mejla just wants to remind that voting on his membership in the provenpackager group has been deferred to today's meeting to be able to get input from sponsors...will be delayed too?
jds2001oops, yeah we're pretty much out of time :)
mejla: can you file a trac ticket so I don't forget?
* jds2001 is a forgetful person
mejlajds2001: ok...I'll request membership in fas again, right?
jds2001yeah, that'd work too.
mejlajds2001: (I've been added and again removed by you last time, so there is now no request)
jds2001right, sorry about that.
* jds2001 got click-happy :)
sharkczmejla: you can create the ticket at https://fedorahosted.org/fesco/
jds2001i owe a few sponsor nominations still.
mejlasharkcz, jds2001: shall I *both* file the ticket and re-request?
jds2001just filing the ticket would do.
I can manually add you after it's approved.
mejlajds2001: ok

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