bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* notting is here
nirik is here.
tibbs here
jwbi'm here
* c4chris is here
bpeppleI was traveling yesterday, so I wasn't able to send out an agenda announcement, so subsequently we really don't have anything on the schedule for today.
tibbsNote that I'm at home and my connexion here sucks, so I may be dropping in and out.
bpeppletibbs: np.
bpeppleDoes anyone have anything they wish to discuss for this week?
nottinganything from fpc?
* bpepple does remember mschwendt having a question about orphaned packages.
tibbsNote also that there's nothing up from the FPC this week, although our meeting is moving one hour earlier (and still every other week).
nirikyeah, when should orphaned packages be removed from the repos...
I think we have had that discussion before, but never reached any final conclusion.
tibbsI don't think we can remove anything within a release.
If a security issue crops up, we'll still need to be able to push updates.
nirikthen what happens when it has broken deps/security/unanswered bug reports?
--- bpepple has changed the topic to: - Misc - Ophaned Packages
tibbsSomeone has to take care of them.
nottingthey get assigned to the local package social worker?
bpepplenotting: ;)
c4chris:) good one
tibbsThe security team exists to deal with security issues.
nirikit would be nice if there was a way in the update data to push out "hey, this package is orphaned now, remove it? (y/n)" or something.
but that gets complicated.
bpeppletibbs: are they willing to take that on for orphaned packages?
tibbsI'm not really concerned with other issues, although if someone wants them fixed badly enough they could consider stepping up and maintaining.
It was one of the reasons the security SIG was started; to take care of things if the maintainers couldn't.
bpeppletibbs: ok, we should add that info to the orphaned packages wiki page.
nirikhumm, but if we remove the package from the repo, at least no new people would install it...
tibbsThis is the kind of thing that the distro just has to take care of.
* nirik agrees with tibbs on security, but there are other issues with orphaned packages that make the distro look bad too.
nottingit's really hard to remove things that are shipped in the release in the release + updates model
tibbsWe can't remove packages from media that's already been burned.
niriktrue. ;(
tibbsYes, we really shouldn't deny someone an update to an orphaned package.
bpepplenotting: agreed.  I don't think we can be removing packages from stable releases.
tibbsReally, it's only for a maximum of six months.
They should go from rawhide as soon as they're orphaned, though.
bpeppletibbs: +1
tibbsWe could release twice as often, and then we'd only have to worry about orphaned packages for three months maximum.
tibbsPlease only throw 24" or larger monitors at me.  Thanks.
nirikso, when a package is orphaned, remove from devel, leave in all release beanches, security sig handles security issues with them in releases, other breakage is just ok?
tibbsThe thing about "other breakage" is that if it bothers someone enough, they could perhaps offer to maintain the package.
c4chrisnirik: yea
tibbs: agreed
nirikyeah, but it looks bad in any case to end users... broken deps in release, or package doesn't function.
* dgilmore is here
tibbsIt would still be really nice if we could get "orphaned" pushed to the package metadata somehow.
f13here now.
nirikor bug reports are ignored (not that thats too different from some other real packages)
f13spot is on the way.
tibbsBut we don't want to push an update just to get that.
* spot is here now
nirikyeah, and we don't want to nuke a existing package on someones machine just because it's orphaned.
bpepplehow are we marking the devel branch of orphaned packages?  are we still using the dead.package file?
tibbsAnyone know if that's remotely possible?
nirikbpepple: yes.
bpepplenirik: thanks.
nottingtibbs: possible with bodhi enhancements, i suppose
nirikBTW, possible to not branch any package with 'dead.package' in it for F-8? or does the mass branch take that into account already?
tibbsI guess it's possible for that kind of data to come from someplace other than the package itself.
f13nirik: I'll talk about that later, but it should be mostly taken into account
nottingnirik: depends how we do the branch, i suppose
f13nirik: (so long as it was actually blocked from koji)
nirikhttps://admin.fedoraproject.org/pkgdb/users/packages/orphan also has orphans
bpeppleok, anything else about orphaned packages, or should we move on?
nirikbut it's not entirely accurate yet
tibbsWhat's our deadline for making sure nothing orphaned gets into F8?
nirikSo did we reach any decision that should be added to the wiki/communicated?
f13tibbs: before the end of next week would be good
bpepplenirik: I was going to add a bit to the orphaned page about the security team handling updates.
f13tibbs: if somebody volunteers to query what koji thinks is in F8 vs what is orphaned but didn't follow process and is still in F8 that would be good.
tibbs: but it's really really late to be removing a big pile of packages
nirikbpepple: 'security updates' right?
bpepplenirik: correct.
f13tibbs: since there is the difference between orphaned and end of lifed.
or maybe there isn't. hrm.
tibbsThe problem is that if an orphaned package gets into F8, someone gets to maintain it (albeit minimally).  We just don't any other choice.
f13right, and if we remove a pile of them and find broken deps...
ideally orphaned packages would be removed prior to the FEature freeze, and if you didn't orphan it before the, you're stuck with it for that release.
However I never communicated this and nobody agreed upon this yet so we can't enforce it.
tibbsPlus we can't force people to maintain something they don't want to maintain.
bpepplehow about we do that for F9 then?
nirikcan we agree to that for next cycle at least now?
f13tibbs: no, but feature freeze would be the timeline where we'd do removals of orphans.  Anything orphaned after that would just have to be picked up by somebody (with reasonable exceptions)
nirikI see 207 packages with dead.package in devel
f13nirik: in devel as in in rawhide or...?
nirikin the cvs snapshot checkout from yesterday.
tibbsBut hopefully some of those have been dead for ages.
f13Proposal: Remove orphaned packages up to Feature Freeze, after feature freeze orphans will not be removed and must be picked up by somebody (with reasonable exceptions)
nirik: that's just packages that have been orphaned or obsoleted or whatever. We're interested in the dead packages that are still living in rawhide (:
nirikmust be picked up? meaning someone has to sign up to maintain them?
bpepple+1, with the caveat that if no one steps up the security team is responsible for any security updates.
tibbsI think we can make "reasonable exceptions" for leaf packages, can't we?
nirikright. So the interesting stat will be how many of those are still in repos/not blocked in koji
f13tibbs: probably yes.  THat would fall under reasonable exception.
nirikso how do you force people to sign up for them?
f13nirik: querying the contents of 'f8-final' would be the best target for that.
warrenf13, +1
f13nirik: when all else fails, the security team and/or releng pick them up.
c4christhis dates a bit, but there were only 4 orphans in rawhide at that point: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-caeb47ba8d83a49681f8c3d55981b12c7b0671ca
f13nirik: we just make it known that at a project level we'd really rather not see packages "go away" at that point so we urge somebody to pick it up at least for the next release.
nirikdoes that mean they formally add in pkgdb as maintainer? or ?
f13nirik: that's probably the best for now.
tibbsBut the fun question becomes: what do we do with any broken deps caused by orphaned package removal?  Drop those packages as well?
f13nirik: we can look at some way of marking packages as deprecated to alert users later.
tibbs: deal with it on a case by case basis?
tibbsI guess so.
bpeppletibbs: It would be handed as it is now.  most of the time the people affected step up.
tibbs"glibc orphaned: distro dumped."
* spot notes that for F9, jpo's packages are effectively orphaned
nirikso for now, we send out a plea? and anything left gets maintained by releng/security for f8 cycle? ok.
warrenspot, jpo quit?
spotwarren: no commits since July.
tibbs"quit" implies some affirmative action.
dgilmorespot: how come?
warrendgilmore, he was very much upset about the perl split.
tibbsOoh, the perl split was just so difficult to deal with.  Not.
bpeppleok, I see four '+1' for f13's proposal.
spoti fixed most of his packages, but not all of them.
nirik+1 as well here.
c4chris+1 for f13's proposal here
bpeppleok, that's seven.  we'
tibbsI keep saying that in the end we're better off without maintainers who say things like "I'll quit if the committee makes a decision I don't like".
bpeppletibbs: agreed.
nottingwhat about the ones who continually say that and don't? :)
tibbsAlthough it sure sucks in the short term.
tibbsspot: If you need help fixing up the rest of those packages, just ask.  I'm off of work today.
bpeppleok, anything else people want to discuss regarding orphaned packages?
nottingoih, and +1
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
c4chrisoih is another tla I don't know about ?
nottingno, i just can't type. s/i//
tibbsIf by "tla" you mean "typo"...
c4christhree letter acronym
f13FYI I posted my developement changes proposal
tibbsMore for the FPC, but we really need Java guidelines.
nirikok, so of the 207 packages with a dead.package in devel, only 4 are in the f8-final koji tag
f13I'm gathering feedback, and want to see maybe a Nov 1st meeting to hash it out and vote on it
spottibbs: s/Java/someone to write Java/
bpepplef13: that sounds good.
tibbsspot: Indeed.
f13also I'm hoping to mass branch CVS this evening
(if I ever get any #(*#$$& time)
bpepplef13: sweet.  I was about to make a bunch of requests for cvs branching.
c4chrisnirik: the same as on the wiki PackageStatus page ?
dgilmoref13: that lokoed pretty sane
abadger1999f13: Keep me in the loop re: branching.
f13bpepple: I'll announce well ahead of time so that we can have a CVS outage and not do any branch requests in the middle of it.
abadger1999f13: I'll need to manually update a few things to the "packager" group afterwards.
f13abadger1999: yeah, I want to use pkgdbclient and pkgdb2branch to do this.
bpepplef13: cool.
tibbsDidn't pdftk have licensing issues?
abadger1999f13: As long as it's fast enough they should work.
bpeppleanything else people want to discuss?
niriktibbs: not sure... might have
tibbsnirik: http://www.mail-archive.com/itext-questions@lists.sourceforge.net/msg32960.html
f13bpepple: I can't think of anything off the top of my head.  Full steam ahead to F8!
nirikoh yeah.
so we should nuke that one.
and then the other 3 are up for grabs.
bpeppleok, unless there's anything else, we can probably wrap up for this week.
* bpepple will end the meeting in 60
nirikoh, any news on fudcon?
* bpepple isn't aware of any.
f13nirik: I haven't heard anything,which likely means it won't happen in Dec.
nirikok, just wondering.
* bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End

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