--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* jwb is here
jwbor will be shortly
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* tibbs here
jeremy waves
nirik is here.
notting is here
dgilmore is here
jwb is here
tibbsNot bad turnout considering.
* warren here
dgilmore slaps dwmw2_BOS
che present
bpeppletibbs: yeah, more than I was expecting.  cool.
ok, might as well get started.
--- bpepple has changed the topic to: MISC - Minor changes to bugzilla https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01161.html - poelcat
warrenDo we really need to discuss this?
* c4chris is here (ADSL link is a bit flaky at times)
warren+1 from me
tibbsI +1'ed this last week, although #6 might be troubling.
jwbother than my repeated "i don't get the rawhide thing", +1
dwmw2_BOSjwb: rawhide is for evolution bugs
nirik+1 here... #6 might be best with some kind of redirection to a wiki page or something...
warrenWith the other renaming of "development" to rawhide, it should become less confusing.
dwmw2_BOSthey never get fixed; it's boring to have to reassign them to a new release each time
might as well just leave them assigned to rawhide for ever
* spot is here
jwbwarren, yeah that's the stuff i don't get.  it's an aside on the broader topic
dwmw2_BOS, heh :)
warrenjwb, there were plans to rename the directory on the mirrors from development to rawhide, and to use the rawhide name in more places.
bpeppleok, I see seven '+1' for the proposal, so it's been approved.
dgilmoredwmw2_BOS: so cynical,  evolution is bug free.  its all features
+1 from me
warrenjwb, Mandriva has "cooker".  We just have to make our equivalent more known.
bpepplewarren: agreed.
jwbwarren, i know that.  unrelated to the topic at hand and i shouldn't have brought it up
bpeppleok, anything else on this, or should we move on?
--- bpepple has changed the topic to: MISC - Deadline to drop kmods - f13
bpeppleI don't see f13, so I'm not sure what kind of deadline he was looking for on this.
tibbsAnd f13 couldn't make it.
jwbi thought it was by F9
tibbsBut obviously they need to actually go before F9 release day.
jeremyhe wants to drop them early/soon I think
bpepplejeremy: I don't see a problem with that.
dwmw2_BOSwhat kmods do we have left?
jwbi'm sure he wouldn't be opposed to "today"
nottingi suppose the question is, if they're not going to be in F9, what do we gain by having them in rawhid?
jeremynotting: more spam about broken deps? :)
dwmw2_BOSnothing. Kill them now
jwbdwmw2_BOS, sysprof and e800 or something
jwbdwmw2_BOS, the only two we've ever had
dwmw2_BOSlet us promote an attitude of violence towards them
dgilmoredwmw2_BOS: the poor modules.  wont someone think of the modules
:) kill em
jwbi thought the idea was to allow the maintainers a bit of time to work on getting them upstream and/or in the kernel package
bpepplealright, is there anyone that opposed dropping the kmods as soon as possible?
stahnmajwb: +1
dwmw2_BOSmake them dead
dwmw2_BOSjwb: we _have_ done that
we _are_ doing that
bpepplejwb: what kind of time do you think we should give them?
jwbme personally?  they've had enough time
dwmw2_BOSthat's why we kept them in F8.
bpeppledwmw2_BOS: agreed.
* jeremy thinks they've been given time too
bpeppleProposal: Drop kmods immediately in Rawhide.
tibbs+1 can't think of any reason not to.
warren(NOTE: Be sure to note in the announcement that this is *only* the actual kmods, not supporting tools.)
bpeppleok, that proposal has been approved.
warrengo go!
bpepplewarren: agreed.  I'll add that bit to my summary.
ok, onto the next topic....
--- bpepple has changed the topic to: MISC - PPC Secondary Arch? - https://www.redhat.com/archives/fedora-advisory-board/2007-November/msg00078.html - f13, dwmw2
bpeppledwmw2_BOS: where are we on this discussion?
jwbi think dwmw2_BOS and f13 had an agreement on the list
bpeppleok, most have missed that. Do we still need to discuss this then?
an ack on the agreement was asked for
here it is:
for ppc/ppc64, the buildsys bits stay the same as they are today. the actual QA and rel-eng processes are done by the arch team
dwmw2_BOS, is that a fair summary?
jwb: he got pulled away
i'm pretty sure that was the agreement
* spot is pretty sure that was what we agreed to.
dgilmorebut thats fair on what was agreed to
tibbsSeems fair to me.
nirikseems fine.
tibbsBut do we have a PPC arch team?
jwbtibbs, yes
nirikBTW, whats the current sparc/arm/ia64/whatever status?
tibbsBesides just dwmw2_BOS?
jwbtibbs, it will be expanded to more than that soon
nirik, i think spot had f7 almost built on spar?
er, sparc
dgilmorenirik: its being worked on.  I need to publish the code that i have
warrenthe secondary arch team is supposed to host the bits
jwbwarren, not in this proposal
warrendoes that include the release ISO's, or the entire tree including updates?
a bit awkward because updates are built/pushed through the standard means
* dwmw2_BOS returns
jwbwarren, this is a compromise for now.  buildsys and hosting remains as-is today
bpepplejwb: I'm assuming your a '+1' for this proposal, which in case gives us seven '+1'.
dwmw2_BOSwe're not speaking of changing the hosting arrangements
jwbbpepple, actually i haven't voted yet
dwmw2_BOSbasically we've agreed that the PPC SIG will take over doing the final composes and QA work
i.e. relieving the work that f13 &c are doing.
jwbspot, dwmw2_BOS: vote on that?
dwmw2_BOSon that agreement, and _not_ including any reference to the somewhat ambiguous phrase "secondary arch": +1
bpeppleok, that more than 50% of FESCo.  the proposal has been approved.
dwmw2_BOSdependent on f13 actually sending me some of the ppc machines he's been using as text boxen, which was also agreed.
jwbdwmw2_BOS, i think that is going to happen
dwmw2_BOSyeah, I'm sure it will.
dgilmoredwmw2_BOS: i asked him to have that for me tommoorow
jwbbpepple, and for the record, i abstain
bpepplejwb: np.
dwmw2_BOSdgilmore: that's just the mini. There's more to be shipped
dgilmoredwmw2_BOS: ok
dwmw2_BOSok, that's settled then. for F9 the composes and QA will be done by jwb, but the bits will go onto the mirrors in the same place as they currently do
dwmw2_BOSso, I'll be needing some way of uploading the composes, etc. I'm a bit clueless about how all that works
dgilmoredwmw2_BOS: there are people to help you
dwmw2_BOSyep; thanks
* jwb sees he's been volunteered
dwmw2_BOSjwb: I spoke to Hugh on the phone a couple of days ago... :)
jwbdwmw2_BOS, assuming he's sending me a machine i'm cool with it :)
jwbactually, either way i'll be glad to help
bpeppleok, anything else?  or should we move on?
dwmw2_BOShow about this... think IBM send me hardware, then I send you some of what Sony sent me?
jwbdwmw2_BOS, let's work that outside of the meeting :)
--- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - f13
bpeppleHmm, f13 had a lot of topics for this week.
dgilmorebpepple: /me votes to do that next week
dgilmorei.e drop all pre f8 orphans
tibbsdo the topic or do the dropping of orphans?
dgilmoretibbs: the dropping of orphans
jwboh, wait
dgilmoredo it early in the release cycle
nirikwhat does dropping mean here? removal from repos and dead.package?
tibbsOh, yes, please drop the orphans soon.
dgilmorenirik: yes
tibbsBut we need to calculate dependencies and such and make sure that we don't break non-orphaned packages.
bpeppleProposal: Drop F8 orphan packages next week from Rawhide.
nirikyeah, the sooner the better.
nottingmight want to list them
jeremywhere's the current list?
niriktibbs: yeah, especially in fc6/f7
nottingnirik: i think it's only drop orphans in -devel
bpepplenotting: agreed.
tibbsyeah we can't drop anything from release branches.
dwmw2_BOS+1 drop them from rawhide
dgilmoretibbs: its rawhide early in the cycle.  breakage is expected
nirikok, that makes more sense. I was seeing all the F8 in there...
yeah, drop ++
tibbsDo we have a current list?
nirikthere is this: https://admin.fedoraproject.org/pkgdb/users/packages/orphan
but not sure if the bug where it listed something that was only orphaned on one branch is still happening there.
* nirik wonders if he can orphan tpb. ;)
dwmw2_BOSbtw, returning briefly to the kmod thing:  Ville asked us to consider what happens to other packages which depend on kmods.
tibbsThat URL isn't quite right.
dgilmorethats alot fo orphans
tibbsclamav isn't orhpaned, for example.
Just in EPEL.
dgilmoretibbs: we need things that are orphaned in rawhide only
warrendrop as in block?
nirikyeah. this is everything that has a orphan branch
tibbsPlus many of those packages  are already gone from the distro.
warrenDid we already give sufficient warning "here is what we plan on dropping, claim now"?
nirikright. It's packages that have even a single orphan branch...
jeremycan someone take the item of getting the list of what we're actually going to be dropping and send the list to fedora-devel?
and then we can vote on dropping them next week
jeremy(also that will give people ~ a week and a half to step up and take over packages they care about)
warrenI'll do it.
bpepplewarren: thanks.
ok, let's table this till next week then.
--- bpepple has changed the topic to: MISC - Using Matt Domsch's "doesn't rebuild" bugs as AWOL detection, mark as orphaned at some point in F9, drop in F9+ - f13
tibbsAWOL detection is tough in any case.
nottingi'd like to get 'don't rebuild' pushed to maintainers a bit better
tibbsBut sure, if we know a package doesn't build and the maintainer doesn't fix it before <date> then the package does need to get dropped.
warrendoens't rebuild reports have to be sent to individuals
niriknotting: agreed. It would be nice to get one report say once a week with 'don't rebuild' 'multiarch conflicts' and 'source file mismatches' and everything else we can think of to check in one place.
tibbsSometimes I wonder if we couldn't use idle buildsys time to just try random package rebuilds.
warrentibbs, it might be valuable for not just "does it build" but also compare it to the past build, to see if anything in the result changed.
tibbs, new deps, new files, missing deps, missing files, etc.
tibbsAnd rpmlint complaints, and....
But we can dream all day.
warrensend that note to wwoods, that is his department =)
tibbsStill, Matt has all of this CPU to throw at the task and if he's willing then it would be great to use it.
But the issue still comes down to notification.
I take it we don't want to auto-file "doesn't build" bugzilla tickets.
jwbi wouldn't want to
warrenand large automated e-mails to a list with many problems are problematic
individuals have to receive mail about their own packages
jwbi thought that was done already
dgilmorewarren: yes  but they also must respond to the emails and bugs
tibbsIt should just be an SMOP, but I don't think the scripts are public so this all sort of falls on Matt.
warrenI guess a notification server would have to not only notify, but also keep track how old a particular failure is.  If failure older than say 2 weeks, then escalate to FOO.
dgilmorewarren: yes
jwbtibbs, i asked him to post his scripts somewhere
(and what is an SMOP)?
tibbssimple matter of programming.
warrenabadger1999 has always wanted to make a notification server... lets see if he has any plans/code.
warrena more general notification server could be used for many other things
abadger1999No code. I'd love to do it but it hasn't seemed as high a priority as wiki/pkgdb/cmd line clients/etc.
nirikI think we need a more detailed plan that just the 'doesn't rebuild' for finding awol maintainers...
warrenI guess generally we need to put together a specification of what we want a notification server to do.  It would help these other needs.
bpepplenirik: agreed.
c4chrisfor the time beeing, we could dig the ml archives a bit, and file BZ against repete offenders...
warrenFor now, sending individual e-mails to maintainers about their broken package is a doable start.
dgilmorewarren: it could send notifies by xmmp, smtp, etc
warrendgilmore, let's not go into such details now
warrenSimple proposal for now, while we lack a notification server:
1) Script individual e-mails.
2) Set a deadline (all issues of type FOO not fixed by date BAR, then BAZ)
We can do this without any fancy server.
tibbsThe problem with deadlines is that packages can stop building at just about any time.
nirikwell, I don't think that detects awol maintainers...
tibbsIt helps to detect some awol maintainers, but it's not a comprehensive solution.
nirikyeah, so if it fails, gets fixed, then fails again a day before the deadline they get marked as awol... ?
dgilmorenirik: it helps if they dont respond
nirikso there would need to be something collecting responses then?
dgilmorenirik: no the fix would reset the clock
warrenIn order to truly detect AWOL maintainers and make it scale, it must be an automated, database driven process.
bpepplewarren: agreeed.
mdomschhey folks - my scripts do email each maintainer separately
when their builds fail
as well as copying the list
and the scripts are public, though they're somewhat specific to my environment
* dwmw2_BOS should set them up
jwbmdomsch, where are they?
dwmw2_BOS, that's exactly what i was asking for :)
mdomschjwb: http://linux.dell.com/files/fedora/FixBuildRequires/
the kicker is you really need a local mirror else it's too slow to be usable
~5k SRPMS now
jwbi think we can handle that :)
nirikyeah. I agree we come come up with a flow based on non-rebuilding to mark someone awol, but perhaps it should be written up in detail and presented after it's been thought about, rather than ad-hoc trying to make it in this meeting?
jwbnirik, agreed
bpepplenirik: agreed.
c4chrisnirik: yes
* notting agrees too
jeremynirik: +100
bpeppleok, let's move on then....
warrenI hope this is not the only method of detecting AWOL, but in agreement.
nirikyeah, should be a variety of stuff...
--- bpepple has changed the topic to: MISC - acpi package/acpi subsytem bugs - Patrice Dumas
* notting doesn't see why this is a fesco issue. you get kernel bugs, reassign to kernel.
dgilmorenotting: i agree
warrennotting, it is annoying to the acpi package maintainer
nottingwarren: misfiled bugs are annyoing everywhere. *shrug*
dgilmorewarren: deal with it.  people misclassify bugs all the time
jwbno kidding
wtf is fesco supposed to do about that?
bpepplenotting: from Patrice's e-mail: 'I proposed that to the kernel maintainer (well I proposed them to be initial CC), but they refused."
* spot gets tons of alsa bugs on alsamixergui
nirikperhaps they could re-name acpi to 'acpi-script' upstream? :)
spoti just reassign them to kernel.
jwbdavej, ping?
nottingbpepple: asking the kernel to be initialcc on acpi bugs is different than just reassigning misfiled bugs
c4chrisI think they object to the auto-CC, not the refiling
jeremypart of being a package maintainer involves the (annoying and thankless) task of reassigning bugs which are misfiled...  but unless we had an army of dedicated triagers, that's not going to change
warrenperhaps we should have all bugs assigned to NOBODY at first and a triage team sorts them.
davejjwb: pong
warrenbut that's beyond the scope of this
bpeppleok, I'll tell Patrice that he should reassign the bugs that belong to the kernel.
nirikwarren: that would be great, but we would need a large group of triage people... who I suspect won't appear. ;(
c4chrisbpepple: +1
dwmw2_BOShow about "we shouldn't have an ACPI-specific package at all; stuff should be exposed through proper generic APIs instead" :)
warrennirik, I think it would be possible to organize, it would be an easy way for less experienced people to get involved.
nirikbpepple: +1 here too...
nottingbpepple: +1
bpeppleok, let's move on....
dgilmoredavej: if acpi bugs that are kernel related you dont object to the being assigned to you correct?
nirikwarren: yeah... they could start now tho... just go thru the new bugs as they are filed and make sure they are correct... ;)
davejs/you/kernel-team/ but yes, sure.
dgilmoredwmw2_BOS: thats to logical
davej: yeah :)
nirikdwmw2_BOS: this is a small script that spews out acpi info... (the 'acpi' bugzilla component/package)
warrennirik, hmm, I guess a simple page with a canned query of NEW bugs in the last 24 hours and some simple instructions might get people started.
nirikwarren: yeah, I think bugzilla will even get you a rss feed. ;)
nottingnew bugs in the last <time frame> is easy
niriknext item?
bpeppleok, we've got 5 minutes left.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
c4chriswow, we cleaned the agenda ?
bpeppleanything people want to discuss before we wrap up for today?
c4chris: not completely, but pretty close.
c4chriscool :)
tibbsWeren't we going to talk about merge reviews?
bpeppletibbs: I figured we would table it, since we only had 5 minutes left.
but we can talk about it, if you wish.
tibbsI don't think it's urgent.
bpeppletibbs: that's where I was at also.
tibbsThe review queue is still coming down slowly.
bpeppleOk, last call before we wrap up.
tibbsIs koji scratch build stuff supposed to be used by everyone now?
dgilmoretibbs: in what way?
jwbthat's hard to do unless you're already in FAS
tibbsWell, when I first heard about it, it was a "don't pass this around" kind of thing.
jwb: Yes, but most review submissions could still be tested via koji.
And for the others, someone doing triage could do the builds and link to them.
jwbi wonder how hard it would be to setup a scratch/review builder
dgilmore, ?
tibbsMy problem is that about 60% of the packages I tried to review over the weekend didn't build.
dgilmorejwb: i was asking tibbs in what context should people be using it ?
mdomschoh crud
wrong window
bpeppletibbs: I've add scratch build links to some of my reviews to save the reviewers some time.
jwbdgilmore, reviewing packages
dgilmorejwb: a box that people could ssh into and run mock builds?
jwbdgilmore, no, a dedicated koji builder
warrenjwb, tibbs: the thing is, you could possibly put the build server at security risk if unknown users throw .src.rpm's at it.
jwb, tibbs: a bit too easy to include malicious payload and break out of the chroot.
dgilmorejwb: given appropriate hardware hosted somewhere it wouldnt be hard
jwbwarren, hence my request for a dedicated server
tibbsI wasn't talking about letting folks with no FAS account do builds.
dgilmorejwb: it would require at least two servers and lots of storage
tibbsBut even if it's just someone doing triage, the SRPM is still going to come from a completely untrusted source.
jwbdgilmore, two?
dgilmorejwb: there is not room or hardware in phx to host it
jwb: one x86_64 and one ppc
jwbdgilmore, i think we can skip ppc for now
for this task
* jeremy has to disappear
tibbsThis wouldn't be used all that often, and ppc isn't really necessary for this task.
mbonnetum, why can't they just use the Fedora Koji instance?
dgilmorejwb: ok  it would still require a box and disk
dgilmorembonnet: disk
jwbmbonnet, they could.  i was just trying to prevent load on the buildsys for scratch stuff
mbonnetdgilmore: scratch builds don't hang around for that long
tibbsjwb: Well, warren says no due to security.
dgilmorethough they could  we would just need to be very agressive in cleaning up scratch builds
mbonnetand we can lower that duration if we need to
jwbtibbs, that's false since it can already be done today
warrenSecurity will always be a concern even for our existing cvsextras users
mbonnetyeah, we have to trust people with FAS accounts to a certain extent
warrenbut for people who aren't in cvsextras yet, for packages in no VCS, the risk is even higher.
dgilmorembonnet: we probably should avaluate that
jwbmbonnet, how busy are the builders when we have kernel or ooffice builds going?
tibbsSo, core question 1: Does anyone care if someone runs thrrough all open review tickets and does scratch builds of them?
dgilmoretibbs: i dont
mbonnetjwb: busy, but not saturated.  It varies a lot.
warrenmbonnet, yes, but we have safeguards in place.  We can't extend that trust to anybody who creates a FAS account and does not obtain cvsextras from a human.
jwbtibbs, i don't
dgilmoretibbs: i added make scratch-build to Makefile.common yesterday
mbonnetwarren: right, I meant cvsextras people.  We need to trust package maintainers.
warrenmbonnet, there is no disputing that.
dgilmorethe arch specific part is not working currently though
jwbmbonnet, warren: your discussion is a bit silly
mbonnettibbs: if you're going to do that, please run those builds with --background
jwbfor review builds, you'd have to trust the maintainer already verified the package under review doesn't contain malicious code
warrenmbonnet, should scratch builds get --background by default?
bpepplewarren: probably.
nirikI think scratch builds would be nice for review... but just doing all of them might not be so good... since some might sit there a long time before review and need a new build again before review starts...
but you could weed out the ones that don't build.
bpeppleok, we're over the hour point for the meeting.  I'm going to wrap this up, since I need to head back to work.
* bpepple will end the meeting in 60
c4chrisnirik: agreed
* bpepple will end the meeting in 30
warrenIn the future a review could be more organized than this, put into step-by-step process in a TG app, where scratch builds are an official step.  This description is only vapor, but both that and this today would require isolated build hardware for security reasons.
* bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
tibbsI think I'll update the relevant wiki pages to request that folks don't need sponsorship do scratch builds just to make sure things are OK.
bpeppleThanks, everyone!
tibbsThanks folks.
warren(Also a review VCS... lots of useful improvements that happen during the package review are lost because reviews don't happen in VCS.)
niriktibbs: they have to be in cvsextras to do scratch builds currently tho, right?
warrennirik, yes
c4christhanks (and happy Thanksgiving)
nirikthanks bpepple
jwbnirik, yes.  the reviewer could do the builds
tibbsYes.  But anyone who doesn't need sponsorship is already in cvsextras.
warrenHmm... a review VCS might be doable sooner...
tibbsSo the only submissions that should come in without a verified build are those that block FE-NEEDSPONSOR.
c4chrislater folks
tibbsBTW, weren't we going to rename cvsextras?
warrenExample: /cvs/pkgreview with the same structure as /cvs/pkgs.   make build does a --scratch build by default.  If the submitter isn't cvsextras yet, then reviewer can import and build.
tibbs, yes
niriktibbs: ah, I misread your sentence... "folks don't need sponsorship do scratch builds" mislead me... folks that are already in cvsextras/sponsored should do scratch builds...
* warren writes this idea to the list
tibbswarren: If that gets us to the point where the formal CVS branch comes prepopulated then awesome.
Because that always trips up new contributors.
warrentibbs, something like that
tibbsI was actually going to write something up about a review CVS.
nirikwarren: should be a rss feed of new f8 bugs. Not sure how much load it would put on bugzilla to keep generating it however: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=f8&component=&bug_status=NEW&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&ctype=rss
tibbsBeing able to collaborate on packages would be pretty nice.
Well, collaborate on new packages.
warrennirik, if load becomes an issue, the RSS feed can be mirrored to a static URL
tibbs, exactly

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