| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| * jwb is here | ||
| jwb | or will be shortly | |
|---|---|---|
| bpepple | FESCo 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 | ||
| tibbs | Not bad turnout considering. | |
| * warren here | ||
| dgilmore slaps dwmw2_BOS | ||
| che present | ||
| dwmw2_BOS | fish | |
| warren | fish | |
| bpepple | tibbs: 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 | ||
| warren | Do we really need to discuss this? | |
| * c4chris is here (ADSL link is a bit flaky at times) | ||
| warren | +1 from me | |
| tibbs | I +1'ed this last week, although #6 might be troubling. | |
| notting | +1 | |
| bpepple | +1 | |
| jwb | other than my repeated "i don't get the rawhide thing", +1 | |
| dwmw2_BOS | jwb: rawhide is for evolution bugs | |
| nirik | +1 here... #6 might be best with some kind of redirection to a wiki page or something... | |
| warren | With the other renaming of "development" to rawhide, it should become less confusing. | |
| dwmw2_BOS | they 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 | ||
| c4chris | +1 | |
| jwb | warren, yeah that's the stuff i don't get. it's an aside on the broader topic | |
| dwmw2_BOS, heh :) | ||
| warren | jwb, there were plans to rename the directory on the mirrors from development to rawhide, and to use the rawhide name in more places. | |
| bpepple | ok, I see seven '+1' for the proposal, so it's been approved. | |
| dgilmore | dwmw2_BOS: so cynical, evolution is bug free. its all features | |
| +1 from me | ||
| warren | jwb, Mandriva has "cooker". We just have to make our equivalent more known. | |
| dwmw2_BOS | +1 | |
| bpepple | warren: agreed. | |
| jwb | warren, i know that. unrelated to the topic at hand and i shouldn't have brought it up | |
| warren | k | |
| bpepple | ok, anything else on this, or should we move on? | |
| --- bpepple has changed the topic to: MISC - Deadline to drop kmods - f13 | ||
| bpepple | I don't see f13, so I'm not sure what kind of deadline he was looking for on this. | |
| tibbs | And f13 couldn't make it. | |
| jwb | i thought it was by F9 | |
| tibbs | But obviously they need to actually go before F9 release day. | |
| jeremy | he wants to drop them early/soon I think | |
| jwb | right | |
| bpepple | jeremy: I don't see a problem with that. | |
| dwmw2_BOS | what kmods do we have left? | |
| jwb | i'm sure he wouldn't be opposed to "today" | |
| notting | i suppose the question is, if they're not going to be in F9, what do we gain by having them in rawhid? | |
| jeremy | notting: more spam about broken deps? :) | |
| dwmw2_BOS | nothing. Kill them now | |
| jwb | dwmw2_BOS, sysprof and e800 or something | |
| gregdek_home | KILL! | |
| jwb | dwmw2_BOS, the only two we've ever had | |
| dwmw2_BOS | let us promote an attitude of violence towards them | |
| dgilmore | dwmw2_BOS: the poor modules. wont someone think of the modules | |
| :) kill em | ||
| jwb | i thought the idea was to allow the maintainers a bit of time to work on getting them upstream and/or in the kernel package | |
| bpepple | alright, is there anyone that opposed dropping the kmods as soon as possible? | |
| gregdek_home | *crickets* | |
| stahnma | jwb: +1 | |
| dwmw2_BOS | make them dead | |
| dwmw2_BOS | jwb: we _have_ done that | |
| we _are_ doing that | ||
| bpepple | jwb: what kind of time do you think we should give them? | |
| jwb | me personally? they've had enough time | |
| dwmw2_BOS | that's why we kept them in F8. | |
| bpepple | dwmw2_BOS: agreed. | |
| * jeremy thinks they've been given time too | ||
| bpepple | Proposal: Drop kmods immediately in Rawhide. | |
| +1 | ||
| jwb | +1 | |
| dwmw2_BOS | +1 | |
| warren | +1 | |
| nirik | +1 | |
| jeremy | +1 | |
| tibbs | +1 can't think of any reason not to. | |
| dgilmore | +1 | |
| notting | +1 | |
| c4chris | +1 | |
| warren | (NOTE: Be sure to note in the announcement that this is *only* the actual kmods, not supporting tools.) | |
| bpepple | ok, that proposal has been approved. | |
| jwb | progress | |
| warren | go go! | |
| bpepple | warren: 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 | ||
| bpepple | dwmw2_BOS: where are we on this discussion? | |
| jwb | i think dwmw2_BOS and f13 had an agreement on the list | |
| bpepple | ok, most have missed that. Do we still need to discuss this then? | |
| s/most/must/ | ||
| jwb | yes | |
| 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? | ||
| dgilmore | +1 | |
| jwb: he got pulled away | ||
| jwb | ah | |
| i'm pretty sure that was the agreement | ||
| * spot is pretty sure that was what we agreed to. | ||
| dgilmore | but thats fair on what was agreed to | |
| c4chris | +1 | |
| bpepple | +1 | |
| jeremy | +1 | |
| tibbs | Seems fair to me. | |
| nirik | seems fine. | |
| tibbs | But do we have a PPC arch team? | |
| jwb | tibbs, yes | |
| nirik | BTW, whats the current sparc/arm/ia64/whatever status? | |
| tibbs | Besides just dwmw2_BOS? | |
| jwb | tibbs, it will be expanded to more than that soon | |
| nirik, i think spot had f7 almost built on spar? | ||
| er, sparc | ||
| warren | question | |
| dgilmore | nirik: its being worked on. I need to publish the code that i have | |
| warren | the secondary arch team is supposed to host the bits | |
| nirik | cool. | |
| jwb | warren, not in this proposal | |
| warren | does 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 | ||
| jwb | warren, this is a compromise for now. buildsys and hosting remains as-is today | |
| warren | oooh | |
| ok | ||
| bpepple | jwb: I'm assuming your a '+1' for this proposal, which in case gives us seven '+1'. | |
| dwmw2_BOS | we're not speaking of changing the hosting arrangements | |
| warren | +1 | |
| jwb | bpepple, actually i haven't voted yet | |
| dwmw2_BOS | basically 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. | ||
| jwb | spot, dwmw2_BOS: vote on that? | |
| spot | +1 | |
| dgilmore | +1 | |
| dwmw2_BOS | on that agreement, and _not_ including any reference to the somewhat ambiguous phrase "secondary arch": +1 | |
| bpepple | ok, that more than 50% of FESCo. the proposal has been approved. | |
| dwmw2_BOS | dependent on f13 actually sending me some of the ppc machines he's been using as text boxen, which was also agreed. | |
| jwb | dwmw2_BOS, i think that is going to happen | |
| notting | +1 | |
| dwmw2_BOS | yeah, I'm sure it will. | |
| dgilmore | dwmw2_BOS: i asked him to have that for me tommoorow | |
| jwb | bpepple, and for the record, i abstain | |
| bpepple | jwb: np. | |
| dwmw2_BOS | dgilmore: that's just the mini. There's more to be shipped | |
| dgilmore | dwmw2_BOS: ok | |
| dwmw2_BOS | ok, 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_BOS | so, I'll be needing some way of uploading the composes, etc. I'm a bit clueless about how all that works | |
| dgilmore | dwmw2_BOS: there are people to help you | |
| dwmw2_BOS | yep; thanks | |
| * jwb sees he's been volunteered | ||
| dwmw2_BOS | jwb: I spoke to Hugh on the phone a couple of days ago... :) | |
| jwb | dwmw2_BOS, assuming he's sending me a machine i'm cool with it :) | |
| dwmw2_BOS | heh | |
| jwb | actually, either way i'll be glad to help | |
| bpepple | ok, anything else? or should we move on? | |
| dwmw2_BOS | how about this... think IBM send me hardware, then I send you some of what Sony sent me? | |
| jwb | dwmw2_BOS, let's work that outside of the meeting :) | |
| dwmw2_BOS | yep | |
| --- bpepple has changed the topic to: MISC - Drop orphans from F8< at some point during F9 - f13 | ||
| bpepple | Hmm, f13 had a lot of topics for this week. | |
| dgilmore | bpepple: /me votes to do that next week | |
| jwb | agreed | |
| dgilmore | i.e drop all pre f8 orphans | |
| tibbs | do the topic or do the dropping of orphans? | |
| dgilmore | tibbs: the dropping of orphans | |
| jwb | oh, wait | |
| dgilmore | do it early in the release cycle | |
| nirik | what does dropping mean here? removal from repos and dead.package? | |
| tibbs | Oh, yes, please drop the orphans soon. | |
| dgilmore | nirik: yes | |
| tibbs | But we need to calculate dependencies and such and make sure that we don't break non-orphaned packages. | |
| bpepple | Proposal: Drop F8 orphan packages next week from Rawhide. | |
| nirik | yeah, the sooner the better. | |
| notting | might want to list them | |
| jeremy | where's the current list? | |
| nirik | tibbs: yeah, especially in fc6/f7 | |
| notting | nirik: i think it's only drop orphans in -devel | |
| bpepple | notting: agreed. | |
| tibbs | yeah we can't drop anything from release branches. | |
| dwmw2_BOS | +1 drop them from rawhide | |
| bpepple | +1 | |
| dgilmore | tibbs: its rawhide early in the cycle. breakage is expected | |
| nirik | ok, that makes more sense. I was seeing all the F8 in there... | |
| yeah, drop ++ | ||
| tibbs | Do we have a current list? | |
| nirik | there 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_BOS | btw, returning briefly to the kmod thing: Ville asked us to consider what happens to other packages which depend on kmods. | |
| tibbs | That URL isn't quite right. | |
| dgilmore | thats alot fo orphans | |
| tibbs | clamav isn't orhpaned, for example. | |
| Just in EPEL. | ||
| dgilmore | tibbs: we need things that are orphaned in rawhide only | |
| warren | drop as in block? | |
| nirik | yeah. this is everything that has a orphan branch | |
| tibbs | Plus many of those packages are already gone from the distro. | |
| jwb | +1 | |
| warren | Did we already give sufficient warning "here is what we plan on dropping, claim now"? | |
| nirik | right. It's packages that have even a single orphan branch... | |
| jeremy | can 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) | |
| warren | I'll do it. | |
| bpepple | warren: 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 | ||
| tibbs | AWOL detection is tough in any case. | |
| notting | i'd like to get 'don't rebuild' pushed to maintainers a bit better | |
| tibbs | But 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. | |
| warren | doens't rebuild reports have to be sent to individuals | |
| nirik | notting: 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. | |
| tibbs | Sometimes I wonder if we couldn't use idle buildsys time to just try random package rebuilds. | |
| warren | tibbs, 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. | ||
| tibbs | And rpmlint complaints, and.... | |
| But we can dream all day. | ||
| warren | send that note to wwoods, that is his department =) | |
| tibbs | Still, 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. | ||
| jwb | i wouldn't want to | |
| warren | and large automated e-mails to a list with many problems are problematic | |
| individuals have to receive mail about their own packages | ||
| jwb | i thought that was done already | |
| dgilmore | warren: yes but they also must respond to the emails and bugs | |
| tibbs | It should just be an SMOP, but I don't think the scripts are public so this all sort of falls on Matt. | |
| warren | I 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. | |
| dgilmore | warren: yes | |
| jwb | tibbs, i asked him to post his scripts somewhere | |
| (and what is an SMOP)? | ||
| tibbs | simple matter of programming. | |
| warren | abadger1999 has always wanted to make a notification server... lets see if he has any plans/code. | |
| jwb | ah | |
| warren | a more general notification server could be used for many other things | |
| abadger1999 | No code. I'd love to do it but it hasn't seemed as high a priority as wiki/pkgdb/cmd line clients/etc. | |
| nirik | I think we need a more detailed plan that just the 'doesn't rebuild' for finding awol maintainers... | |
| warren | I guess generally we need to put together a specification of what we want a notification server to do. It would help these other needs. | |
| bpepple | nirik: agreed. | |
| c4chris | for the time beeing, we could dig the ml archives a bit, and file BZ against repete offenders... | |
| warren | For now, sending individual e-mails to maintainers about their broken package is a doable start. | |
| c4chris | s/repete/repeat/ | |
| dgilmore | warren: it could send notifies by xmmp, smtp, etc | |
| warren | dgilmore, let's not go into such details now | |
| dgilmore | sure | |
| warren | Simple 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. | ||
| tibbs | The problem with deadlines is that packages can stop building at just about any time. | |
| nirik | well, I don't think that detects awol maintainers... | |
| tibbs | It helps to detect some awol maintainers, but it's not a comprehensive solution. | |
| nirik | yeah, so if it fails, gets fixed, then fails again a day before the deadline they get marked as awol... ? | |
| dgilmore | nirik: it helps if they dont respond | |
| nirik | so there would need to be something collecting responses then? | |
| dgilmore | nirik: no the fix would reset the clock | |
| warren | In order to truly detect AWOL maintainers and make it scale, it must be an automated, database driven process. | |
| bpepple | warren: agreeed. | |
| mdomsch | hey 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 | ||
| jwb | mdomsch, where are they? | |
| dwmw2_BOS, that's exactly what i was asking for :) | ||
| mdomsch | jwb: 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 | ||
| jwb | i think we can handle that :) | |
| nirik | yeah. 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? | |
| jwb | nirik, agreed | |
| bpepple | nirik: agreed. | |
| c4chris | nirik: yes | |
| * notting agrees too | ||
| jeremy | nirik: +100 | |
| bpepple | ok, let's move on then.... | |
| warren | I hope this is not the only method of detecting AWOL, but in agreement. | |
| nirik | yeah, should be a variety of stuff... | |
| --- bpepple has changed the topic to: MISC - acpi package/acpi subsytem bugs - Patrice Dumas | ||
| jwb | ? | |
| * notting doesn't see why this is a fesco issue. you get kernel bugs, reassign to kernel. | ||
| dgilmore | notting: i agree | |
| warren | notting, it is annoying to the acpi package maintainer | |
| notting | warren: misfiled bugs are annyoing everywhere. *shrug* | |
| dgilmore | warren: deal with it. people misclassify bugs all the time | |
| jwb | no kidding | |
| wtf is fesco supposed to do about that? | ||
| bpepple | notting: 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 | ||
| nirik | perhaps they could re-name acpi to 'acpi-script' upstream? :) | |
| spot | i just reassign them to kernel. | |
| jwb | davej, ping? | |
| notting | bpepple: asking the kernel to be initialcc on acpi bugs is different than just reassigning misfiled bugs | |
| c4chris | I think they object to the auto-CC, not the refiling | |
| jeremy | part 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 | |
| warren | perhaps we should have all bugs assigned to NOBODY at first and a triage team sorts them. | |
| davej | jwb: pong | |
| warren | but that's beyond the scope of this | |
| bpepple | ok, I'll tell Patrice that he should reassign the bugs that belong to the kernel. | |
| nirik | warren: that would be great, but we would need a large group of triage people... who I suspect won't appear. ;( | |
| c4chris | bpepple: +1 | |
| dwmw2_BOS | how about "we shouldn't have an ACPI-specific package at all; stuff should be exposed through proper generic APIs instead" :) | |
| warren | nirik, I think it would be possible to organize, it would be an easy way for less experienced people to get involved. | |
| nirik | bpepple: +1 here too... | |
| notting | bpepple: +1 | |
| bpepple | ok, let's move on.... | |
| dgilmore | davej: if acpi bugs that are kernel related you dont object to the being assigned to you correct? | |
| nirik | warren: yeah... they could start now tho... just go thru the new bugs as they are filed and make sure they are correct... ;) | |
| davej | s/you/kernel-team/ but yes, sure. | |
| dgilmore | dwmw2_BOS: thats to logical | |
| davej: yeah :) | ||
| nirik | dwmw2_BOS: this is a small script that spews out acpi info... (the 'acpi' bugzilla component/package) | |
| warren | nirik, 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. | |
| nirik | warren: yeah, I think bugzilla will even get you a rss feed. ;) | |
| warren | oh | |
| notting | new bugs in the last <time frame> is easy | |
| nirik | next item? | |
| bpepple | ok, we've got 5 minutes left. | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| c4chris | wow, we cleaned the agenda ? | |
| bpepple | anything people want to discuss before we wrap up for today? | |
| c4chris: not completely, but pretty close. | ||
| c4chris | cool :) | |
| tibbs | Weren't we going to talk about merge reviews? | |
| bpepple | tibbs: I figured we would table it, since we only had 5 minutes left. | |
| but we can talk about it, if you wish. | ||
| tibbs | I don't think it's urgent. | |
| bpepple | tibbs: that's where I was at also. | |
| tibbs | The review queue is still coming down slowly. | |
| bpepple | Ok, last call before we wrap up. | |
| c4chris | wrap++ | |
| tibbs | Is koji scratch build stuff supposed to be used by everyone now? | |
| dgilmore | tibbs: in what way? | |
| jwb | that's hard to do unless you're already in FAS | |
| tibbs | Well, 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. | ||
| jwb | i wonder how hard it would be to setup a scratch/review builder | |
| dgilmore, ? | ||
| tibbs | My problem is that about 60% of the packages I tried to review over the weekend didn't build. | |
| dgilmore | jwb: i was asking tibbs in what context should people be using it ? | |
| mdomsch | oh crud | |
| wrong window | ||
| bpepple | tibbs: I've add scratch build links to some of my reviews to save the reviewers some time. | |
| jwb | dgilmore, reviewing packages | |
| dgilmore | jwb: a box that people could ssh into and run mock builds? | |
| jwb | dgilmore, no, a dedicated koji builder | |
| warren | jwb, 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. | ||
| dgilmore | jwb: given appropriate hardware hosted somewhere it wouldnt be hard | |
| jwb | warren, hence my request for a dedicated server | |
| tibbs | I wasn't talking about letting folks with no FAS account do builds. | |
| dgilmore | jwb: it would require at least two servers and lots of storage | |
| tibbs | But even if it's just someone doing triage, the SRPM is still going to come from a completely untrusted source. | |
| jwb | dgilmore, two? | |
| dgilmore | jwb: there is not room or hardware in phx to host it | |
| jwb: one x86_64 and one ppc | ||
| jwb | dgilmore, i think we can skip ppc for now | |
| for this task | ||
| * jeremy has to disappear | ||
| tibbs | This wouldn't be used all that often, and ppc isn't really necessary for this task. | |
| mbonnet | um, why can't they just use the Fedora Koji instance? | |
| dgilmore | jwb: ok it would still require a box and disk | |
| dgilmore | mbonnet: disk | |
| jwb | mbonnet, they could. i was just trying to prevent load on the buildsys for scratch stuff | |
| mbonnet | dgilmore: scratch builds don't hang around for that long | |
| tibbs | jwb: Well, warren says no due to security. | |
| dgilmore | though they could we would just need to be very agressive in cleaning up scratch builds | |
| mbonnet | and we can lower that duration if we need to | |
| jwb | tibbs, that's false since it can already be done today | |
| warren | Security will always be a concern even for our existing cvsextras users | |
| mbonnet | yeah, we have to trust people with FAS accounts to a certain extent | |
| warren | but for people who aren't in cvsextras yet, for packages in no VCS, the risk is even higher. | |
| dgilmore | mbonnet: we probably should avaluate that | |
| jwb | mbonnet, how busy are the builders when we have kernel or ooffice builds going? | |
| tibbs | So, core question 1: Does anyone care if someone runs thrrough all open review tickets and does scratch builds of them? | |
| dgilmore | tibbs: i dont | |
| mbonnet | jwb: busy, but not saturated. It varies a lot. | |
| warren | mbonnet, 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. | |
| jwb | tibbs, i don't | |
| dgilmore | tibbs: i added make scratch-build to Makefile.common yesterday | |
| mbonnet | warren: right, I meant cvsextras people. We need to trust package maintainers. | |
| warren | mbonnet, there is no disputing that. | |
| dgilmore | the arch specific part is not working currently though | |
| jwb | mbonnet, warren: your discussion is a bit silly | |
| mbonnet | tibbs: if you're going to do that, please run those builds with --background | |
| jwb | for review builds, you'd have to trust the maintainer already verified the package under review doesn't contain malicious code | |
| warren | mbonnet, should scratch builds get --background by default? | |
| jwb | s/maintainer/reviewer | |
| bpepple | warren: probably. | |
| mbonnet | *shrug* | |
| nirik | I 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. | ||
| bpepple | ok, 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 | ||
| c4chris | nirik: agreed | |
| * bpepple will end the meeting in 30 | ||
| warren | In 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 | |
| tibbs | I 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. | |
| bpepple | Thanks, everyone! | |
| tibbs | Thanks 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.) | |
| nirik | tibbs: they have to be in cvsextras to do scratch builds currently tho, right? | |
| warren | nirik, yes | |
| c4chris | thanks (and happy Thanksgiving) | |
| nirik | thanks bpepple | |
| jwb | nirik, yes. the reviewer could do the builds | |
| tibbs | Yes. But anyone who doesn't need sponsorship is already in cvsextras. | |
| warren | Hmm... a review VCS might be doable sooner... | |
| tibbs | So the only submissions that should come in without a verified build are those that block FE-NEEDSPONSOR. | |
| c4chris | later folks | |
| tibbs | BTW, weren't we going to rename cvsextras? | |
| warren | Example: /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 | ||
| nirik | tibbs: 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 | ||
| tibbs | warren: If that gets us to the point where the formal CVS branch comes prepopulated then awesome. | |
| Because that always trips up new contributors. | ||
| warren | tibbs, something like that | |
| tibbs | I was actually going to write something up about a review CVS. | |
| nirik | warren: 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 | |
| tibbs | Being able to collaborate on packages would be pretty nice. | |
| Well, collaborate on new packages. | ||
| warren | nirik, 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!