= 2006 October 12 FESCo Meeting = Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings == Attending == * thl * bpepple * abadger1999 * tibbs * rdieter * scop * dgilmore (late) * jwb (late) == Summary == === Mass Rebuild === * All done. === EPEL === * Branching of the CVS Repository is waiting on jeremy to have time. === Packaging Committee Report === * Ruby Provides should now be versioned like so: "Provides: ruby(Foo) = Version" * Alternative method to disable GConf schema install "%configure --disable-schemas-install" * Packages must not modify anything outside of %buildroot, %_builddir, and temporary locations (/tmp /var/tmp $TMPDIR %{_tmppath}) === FESCo Summaries === * Last two meetings weren't completed. thl has posted logs. Thanks thl! === Approve kmods === * zaptel is waiting on upstream to get a chance to discuss it. === New Extras Policy === * A package that's been orphaned for more than three months must be re-reviewed on resubmission. === comps.xml === * Waiting on jeremy. * jeremy has to get FC6 out the door before he has time to work on other things. === Misc === ==== Multiply owned directories script ==== * Could checkin to status-report-scripts on http://cvs.fedora.redhat.com/viewcvs/?root=fedora or could wait until the new VCS. ==== Maintainer Responsibility: Fixing other People's Packages ==== * For the specific case of nas, rdieter did the right thing. * Communication is necessary before fixing things in others packages. * A bugzilla bug is the best way to satisfy that requirement. * Sponsors and other trusted people could perhaps fix things in cvs and ask the maintainer to rebuild. If there's no reply by a certain time, the non-maintainers can build. * There should be a list of these "trusted people" somewhere. * Changes should be limited to what is necessary to fix the problem at hand, not cleaning up the aesthetics of the spec file. === Maintainer Responsibility: How Long to Maintain === * http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy * Would be better for people to add their arguments to the wiki page rather than scattered around the mailing list. * How many releases does Extras support is the fundamental question. Two popular possibilities: 1. As long as Core including Legacy 2. As long as Core excluding Legacy (or on a per package basis once it hits Legacy) * The end user experience is better if everything is supported in the same way for the same length of time. * Packagers should have a say in how long they have to support a package for. * Core officially does not support legacy releases; instead The Legacy Project does that. One way of looking at it is that Extras should not officially support legacy releases either, some other Fedora sub-project should. * If a package is orphaned in legacy releases it would be marked unmaintained (and available for orphaned pickup). * We cannot "force" maintainers to maintain for legacy releases. If there is not massive buy-in from the Extras maintainers, it won't work to require them to fix things for legacy releases. * Supporting legacy releases is hard work that takes away from work that could be done on the current release instead. * The Legacy Project feels too overworked to try supporting Extras as well. But if Legacy has problems attracting manpower is Extras any better equipped to motivate people to do it or is supporting legacy releases so unglamorous that we won't be able to get people interested in doing it either. * If maintainers may or may not support their packages on legacy releases we need a flag to tell which packages are not supported. Proposals: * Revive tibbs's idea to place a file in the CVS repository (similar to dead.package). * Have maintainers reassign bug reports to the security Response Team mailing list if they are not going to deal with them on legacy releases. * Would be great to automate this but that might have to wait for the packageDB. * Reassign bugs to an FEN-orphan user when the package goes Legacy and the maintainer isn't going to maintain it for those releases. * The Security Team doesn't want to have all Legacy work dumped on them but may be willing to work on some packages and maintainers interested in Legacy work on others. * Possibly Extras on legacy releases (and Core Legacy?) could cherrypick releases to support. Like FE3 and FE5 but skip FE4. Should be brought up with f13 and the Legacy Project folks to see what they think about it. ==== EVR Problems ==== * To ensure packages upgrade successfully when FC6 comes out, EVR's listed in the daily mailing list report need to be fixed before the release. == Log == {{{ (10:00:30) thl has changed the topic to: FESCO Meeting -- init (10:00:50) thl: hi everybody; who's around? how long will the packaging committee meeting last? (10:00:56) ***bpepple is here. (10:01:38) ***abadger1999 is here (10:01:51) ***mmcgrath is here (10:01:59) tibbs: packaging committee is just wrapping up. (10:02:05) ***rdieter is here (10:02:38) thl has changed the topic to: FESCO Meeting -- M{ae}ss-Rebuild (10:02:43) thl: let's start slowly (10:03:00) thl: I think we can consider the M{ae}ss-Rebuild finished? scop? (10:03:38) ***scop arrives (10:03:42) scop: yep (10:04:09) thl: k, I'll remove it from the shedule soon (10:04:20) thl has changed the topic to: FESCO Meeting -- Enterprise Extras (10:04:40) thl: branching in CVS and the initial stepps couldn't start (10:04:45) mmcgrath: any word on that? (10:04:48) mmcgrath: I haven't heard anything. (10:05:15) thl: there are some things that need to be sorted out first (10:05:30) mmcgrath: got'cha (10:05:33) thl: mmcgrath, yes, I got in contact with jeremy today; we'll sorting this out (10:05:43) mmcgrath: danke (10:05:52) mmcgrath: so for now should I just wait to hear back from you? (10:05:52) thl: I hope that will get solved quickly (10:06:05) thl: so I assume there isn't anything else to discuss now (10:06:08) thl: mmcgrath, yes (10:06:18) ***thl will move on soon (10:06:39) thl has changed the topic to: FESCO Meeting -- Use comps.xml properly (10:06:49) thl: dgilmore, no progress? (10:07:02) thl: I'll move that down on the schedule (10:07:17) thl has changed the topic to: FESCO Meeting -- Packaging Committee Report (10:07:25) thl: scop, abadger1999, tibbs ? (10:07:27) tibbs: Actual progress! (10:07:37) abadger1999: :-) (10:08:20) scop: Provides: ruby(something) to be changed to Provides: ruby(something) = VERSION (10:08:40) tibbs: Sorry, I'm furiously scrolling back. (10:08:52) scop: alternative way to disable gconf schema install being added to scriptletsnippets (--disable-$something, I forgot) (10:09:20) scop: consider it an error if a package build modifies something outside of %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) (10:09:41) bpepple: scop: --disable-schemas-install (10:09:49) scop: bpepple, thanks (10:09:56) scop: that's it unless I forgot something (10:10:00) ***nirik suggests someone mail the list of changes (perhaps with links to wiki pages where they changed) to the extras list? (10:10:13) bpepple: nirik: +1 (10:10:17) thl: nirik +1 (10:10:17) tibbs: Yes, this will be done. (10:10:32) tibbs: But we only finished voting something like two minutes ago. (10:10:43) thl: btw, there were no summaries from the past two FESCo meetings either iirc :-/ (10:10:58) jima: if anyone needs logs, i have them. (10:11:07) abadger1999: Hmm.. Warren was grabbing the one two ago. (10:11:21) thl: abadger1999, can you write todays log again? (10:11:28) thl: abadger1999, I'll put the other two in the wiki (10:11:31) abadger1999: I can get last weeks (just finishing a busy two weeks) (10:11:41) devrimgunduz [n=Devrim] entered the room. (10:11:43) abadger1999: thl: Or you can get last weeks :-) (10:11:46) rdieter: Last thing voted on in packaging: (10:11:48) abadger1999: yes I can start again (10:11:49) rdieter: Build scripts of packages (%prep, %build, %install and %check) may only alter files under %{buildroot}, %{_builddir} and valid temporary locations like /tmp, /var/tmp (or $TMPDIR or %{_tmppath} as set by the rpmbuild process) (10:12:02) thl: abadger1999, start with today (10:12:17) abadger1999: thl: k (10:12:33) thl: I'll put the old two in the wiki without summaries -- if someone writes them good, if not, well, that sucks, but that's life now and then (10:12:52) thl has changed the topic to: FESCO Meeting -- approve kmod's (10:13:05) thl: I think we postpone zaptel even more (10:13:11) thl: two further weeks? (10:13:11) bpepple: thl: +1 (10:13:19) thl: nirik ? (10:13:22) nirik: yeah, at least until after they have a chance to talk about it internally... (10:13:38) rdieter: thl: +1 (10:13:41) nphilipp left the room (quit: "Leaving"). (10:13:46) thl: I got no other request for kmods in extras (10:13:50) thl: so let's move on (10:14:03) scop: one thing related to kmods (10:14:14) ***thl waits (10:14:14) scop: the thinkpad stuff may be resurrected soonish (10:14:34) scop: a couple of people have pinged me about them, but no progress so far due to time constraints (10:14:59) scop: do we want to re-evaluate/review it, or is it just a matter of unorphaning? (10:15:14) scop: (it = thinkpad-kmod*) (10:15:20) thl: hmmmm (10:15:42) thl: good question; what do we enforce normally for packages that are orphaned? re-review iirc (10:15:52) scop: nope (10:15:56) drpixel [n=drpixel] entered the room. (10:16:02) abadger1999: Normal is just unorphan (10:16:43) rdieter: +1 for normal unorphan process (10:16:45) scop: thinkpad stuff is more than orphaned though, IIRC it hasn't been shipped in a long time (10:16:49) ***thl wonders if we shound at least re-review packages if they are orphaned for a long time (10:16:49) jima: isn't a re-review a good idea if there's a big version jump involved? (10:17:03) rdieter: ok, good point. (10:17:11) bpepple: I think a re-review would be a good thing. (10:17:12) scop: I'm afraid in this case there's not a big jump (10:17:16) abadger1999: jima: It is. So far we've left it up to the new packager to decide.... (10:17:26) ***jima nods (10:17:30) thl: re-review for packages that are orhaned for more than 3 month? (10:17:37) thl: months (10:17:49) abadger1999: What if there's been only a bugfix release in that time? (10:18:00) abadger1999: release(s) (10:18:09) scop: actually, it may be that the thinkpad stuff has *never* been shipped in FE (10:18:12) rdieter: then the (re)review should be easy. (: (10:18:17) abadger1999: :-) (10:18:21) scop: so definitely a re-review for it (10:18:21) thl: abadger1999, well, we need to set a point somewhere; I think 3 months are fair (10:18:27) ***jima was thinking the same thing as rdieter (10:18:39) bpepple: thl: +1, sounds good. (10:18:39) abadger1999: We could base off of upstream release version instead (10:18:56) rdieter: +1 for cutoff, 3 mos sounds reasonable (10:18:59) abadger1999: (Just an alternative. I don't care either way.) (10:19:19) tibbs: I think everything should get re-reviewed periodically, but I know we don't have the manpower for it. (10:19:35) thl: so once again: re-review after 3 moths orphaned: +1 (10:19:38) tibbs: I think three months is reasonable for an orphaned package. (10:19:40) tibbs: +1 (10:19:44) abadger1999: +1 (10:19:45) scop: 3months++ (10:20:36) thl: btw, this brings us to a another point: is this FESCo area? OR PAckaging Committee? (10:20:47) scop: fesco (10:20:52) tibbs: This is fesco policy. (10:20:57) thl: btw, no one yelled, so I consider 3 months settled (10:21:32) thl: agreed; but some Extras policys live in the Packaging/ part of the wiki (10:21:45) thl: should we change that to make such stuff more clear? (10:22:21) thl: or do we simply continue to ignore it? (10:22:31) scop: thl, do you have some specific examples in mind? (10:22:50) thl: scop, no, just an impression I got (10:23:09) thl: let's forget about it (10:23:12) thl: and move on (10:23:22) dgilmore: sorry im late (10:23:35) thl has changed the topic to: FESCO Meeting -- misc (10:23:55) scop: yep (I think Packaging/ is fairly well clear of Extras specifics) (10:23:56) thl: dgilmore, any news on the comps stuff? (10:24:12) dgilmore: thl: not yet i need to get some of jeremy's time (10:24:20) thl: k (10:24:40) jeremy: dgilmore: hopefully, my time starts to exist again the beginning of the week (10:24:46) thl: so, where to continue? (10:24:50) ***rdieter feels a bit sorry for Jeremy these days. (10:24:58) thl: we visited all the important point on the schedule (10:25:03) dgilmore: jeremy: :) (10:25:21) thl: we still have the AWOL enhancement (10:25:22) thl: http://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers?action=recall&rev=2 (10:25:31) jeremy: speaking of the beginning of next week, my current thinking is to do the extras branch dance then. I'll send mail when I have a more firm date (10:25:39) thl: but I suspect nearly nobody knows the details (10:25:46) thl: so let's look at it next week (10:25:56) thl: jeremy, thx (10:26:08) dgilmore: jeremy: cool i have all the buildsys stuff mostly ready to go just waiting on cvs branching (10:26:17) thl: jeremy, some people want to build some stuff after the branch dance and before FC6 release (10:26:30) thl: jeremy, so early Monday would be really a good time (10:26:42) jeremy: thl: for fc6 or devel? (10:26:45) thl: and the mirrors need time to sync, too (10:26:57) thl: jeremy, they want to build stuff for fc6 iirc (10:27:23) scop: yep, things like smart and apt config packages (10:27:24) jeremy: thl: okay. since there won't be a "new" rawhide until probably the day after fc6 availability (maybe day of. we'll see how coordinated I can get :) (10:27:43) tibbs: I would like to get the bits for generating the multiply owned and unowned directory reports checked in somewhere. (10:28:14) jeremy: dgilmore: I'll try to sync with you about the buildsys stuff later this afternoon. /me is multiple meeting'ing at the moment tibbs tibbs|h (10:28:29) thl: tibbs, http://cvs.fedora.redhat.com/viewcvs/?root=fedora ? (10:28:42) dgilmore: jeremy: :) ping me when you have time (10:29:05) thl: tibbs, there all those stuff live afaics (10:29:10) abadger1999: tibbs: that would be the place. Do any of those projects look like the right place? (10:29:38) abadger1999: Or do you need a new project in there? (10:29:50) Eitch left the room (quit: Remote closed the connection). (10:30:00) tibbs: Hmm, it doesn't really fit into any of those, but a generic tools directory might not be a bad idea. (10:30:01) Eitch [n=hugo] entered the room. (10:30:12) tibbs: Unfortunately there's already a 'tools' module under fedora-security. (10:30:29) tibbs: That confused me a bit. The structure isn't completely regular. (10:30:36) abadger1999: I was thinking maybe status-report-scripts (10:30:47) scop: my .02€: just drop it somewhere in the "fedora" root, and let's see about reorganizing if/when the scm changes sometime (10:30:54) thl: scop, +1 (10:31:00) bpepple: scop: +1 (10:31:39) dgilmore: +1 (10:31:48) thl: k, seems settled (10:32:03) thl: so where to continue today? (10:32:03) sylvinus left the room (quit: Remote closed the connection). (10:32:08) thl: Comaintainership (10:32:13) thl: Package Database (10:32:20) thl: Feature support in Extras (10:32:27) thl: MISC -long term (10:32:30) bpepple: Maintainer Responsibilities? (10:32:39) thl: "If there's something to be fixed and someone wants to fix it, then fix, it" (10:33:10) thl has changed the topic to: FESCO Meeting -- Maintainer Responsibilities (10:33:12) abadger1999: But what about if there's something to fix and no one wants to fix it? (10:33:29) dgilmore: abadger1999: find someone to fix it (10:33:34) thl: Proposal (from the wiki): Package maintainers should limit updates within a single Fedora release to those which do not require special user action. Many users update automatically, and if their applications stop working from no action of their own then they will be upset. This goes doubly for services which may break overnight. (10:33:41) dgilmore: i think rdieter did the right thing with nas (10:33:48) scop: me too (10:33:50) bpepple: dgilmore: +1 (10:33:59) thl has changed the topic to: FESCO Meeting -- If there's something to be fixed and someone wants to fix it, then fix, it (10:34:10) thl: yes, rdieter did the right thing (10:34:14) ***nirik thinks communication is very important... people shouldn't just go update/fix something without talking to the maintainer... there might be some reason they haven't yet done so. (10:34:17) ***jima (rabble) agrees (10:34:35) jima: nirik: that should have been addressed on the open bug. (10:34:43) bpepple: nirik: I agree. As long as they try to contact the maintainer I have no problem with it. (10:34:44) nirik: yes. Agreed. (10:34:51) schlobinux left the room (quit: "Leaving."). (10:35:14) jima: nirik: but yes, as (someone?) said on the list, there should have been a best-effort attempt to contact the owner (which there was). (10:35:19) nirik: I think we want to make sure not to say: "go to town and fix whatever you like in any package without talking to the maintainer" (10:35:19) thl: I don't think each and everything has to go trough the maintainer/bugzilla (10:35:23) dgilmore: bugzilla is the most appropritae place for communications whith package issues if a maintainer does nothing due to whatever reasons then things are covered (10:35:45) bpepple: dgilmore: +1 (10:35:57) thl: I'd really like to see something like this: sponsors and opther trusted people are check in changes and ask the maintainer to build them (10:36:10) dgilmore: maintainers should ensure they get bugzilla mail (10:36:16) rdieter: dgilmore: +1 (10:36:56) jima: thl: or co-maintainers can kick off builds? (10:36:58) thl: s/are check/are free to check/ (10:37:15) rdieter: co-maintainers: +1 (10:37:20) jwb: +1 (10:37:21) thl: jima, co-maintainership is the proper framework to solve this problem imho (10:37:24) ***jwb has been here for a while (10:37:30) dgilmore: thl sure but if a maintainer has made no response then trusted person should build (10:37:42) thl: dgilmore, agreed (10:37:44) bpepple: dgilmore: +1 (10:37:48) nirik: yeah, co-maintainership would be great... basically sponsors and other trusted people are co-maintainers to all packages. ;) (10:38:12) dgilmore: nirik: yup (10:38:33) thl: well, I'll try to write down an easy policy that we can use until co-maintianership is in place (10:38:38) nirik: I just want to make sure we don't get people rushing into changes on packages they don't know much about... (10:39:15) thl: anything else regardingthis topic? (10:39:23) delero: one reservation: "sponsors and other trusted people" limit their changes to things that are well agreed upon. i.e. dont fix things considered somewhat controversial (like the rpath issue) (10:39:37) thl: delero, agreed (10:40:03) ***rdieter didn't know rpath was controversial. (10:40:12) abadger1999: neither did I... (10:40:19) delero: rdieter: it's not, but not everyone agrees on the perfect way to fix it (10:40:22) ***thl would like to get rid of somewhat controversial (like the rpath issue) (10:40:30) nirik: there should also be a list of "sponsors and other trusted people" if there is going to be a policy allowing them to do things. ;) (10:40:31) ***thl would like to get rid of rpath's (10:40:34) dgilmore: rdieter: it shouldnt be there should be no use of it (10:40:51) scop: anyway, changes done by others should be limited to absolute minimum in order to fix the problem at hand, no while-at-it stuff (10:41:07) ***nirik agrees with scop (10:41:07) thl: let's stop here (10:41:07) abadger1999: scop: +1 (10:41:10) tibbs: It's all about common courtesy. (10:41:13) thl: I'll write something up (10:41:15) rdieter: and common-sense. (10:41:15) tibbs: We shouldn't try to overlegislate. (10:41:20) thl: and we can discus sit in the next meeting (10:41:34) ***thl types to fast today (10:41:34) bpepple: thl: sounds good. (10:41:47) scop: thl missed the "h" (10:42:01) abadger1999: thl: what about the other side of Maintainer Responsibility:: http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy (10:42:22) thl has changed the topic to: FESCO Meeting -- Maintainer Responsibilities (10:42:28) thl: scop, ;) (10:42:30) tibbs: Everyone is still welcome to add their arguments to that page. (10:42:53) thl: tibbs, I think that's really needed before we can discuss this further (10:43:15) thl: but I think we shound't mix those two things to much (10:43:26) thl: only where it's needed (10:43:38) abadger1999: I can add to the page, but I've also sent my arguments to the mailing list... (10:43:48) abadger1999: thl: I agree. They are two separate issues. (10:44:16) thl: well, then this is your homework for the next week: work on http://www.fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy so we have something to discuss next week (10:44:30) abadger1999: thl: :-) Will do (10:44:34) rdieter: is this going to be on the test? (10:44:38) thl: that'S probably better then taking here now (10:44:42) thl: rdieter, no ;-) (10:44:55) thl: rdieter, but well, I'd really like if more poeple could partipiate in the wiki (10:45:14) tibbs: We are really going to have to sit down and decide how many releases extras supports. It is an absolutely fundamental question. (10:45:21) thl: so we all know the same basics when we discuss stuff in the meetings tibbs tibbs|h (10:45:32) thl: mailing list discussions are also important (10:45:41) thl: but stuff get's lost in the noise there quickly (10:45:52) thl: that's why I think these pages in the wiki are imporatant (10:45:52) abadger1999: tibbs: I definitely agree. (10:46:01) jwb: tibbs, what exactly do you mean? (10:46:15) thl: tibbs, there IMHO is not much to discuss (10:46:25) thl: tibbs, I think we have to maintain it as long as core (10:46:29) thl: inkluding legacy (10:46:33) tibbs: jwb: "How long to maintain?" in the wiki page under discussion. (10:46:45) thl: especially as "core and extras" will merge soon (as everybody says) (10:46:54) abadger1999: thl: I very strongly dissent. (10:46:55) tibbs: Well, it's the "including legacy" part that some seem to disagree with. (10:46:57) jwb: thl, that's exactly what i thought too (10:47:27) scop: I disagree with "including legacy" too (10:47:40) tibbs: "including legacy" is what was told to me when I first signed on. I was unaware until recently that there were dissenting opinions there. (10:47:41) abadger1999: thl: If Core and Extras merge, then legacy would take over Extras legacy as well (j/k) (10:47:49) dgilmore: we owe it to the users to support until end of legacy (10:47:52) bpepple: I disagree with "including legacy" also. (10:48:24) abadger1999: We owe it to the packagers to give them the choice (10:48:25) tibbs: The problem is, if extras really isn't a second class citizen, it needs to not act like it and actually support the full release timeline. (10:48:29) thl: hey, a really controversial topic :) (10:48:37) abadger1999: thl: Yep ;-) (10:48:40) Eitch left the room (quit: Read error: 60 (Operation timed out)). (10:48:49) bpepple: abadger1999: +1 (10:48:52) thl: abadger1999, we need the pacakge database for it IMHO (10:48:54) cweyl: abadger1999++. let the packagers choose. (10:48:55) rdieter: There's a *reason* why core (officially) dropped legacy support, and why the legacy team was created. (10:49:36) nirik: if someone chooses not to maintain their packages for legacy, then what? they are deleted? people who have it installed are out of luck? (10:49:58) rdieter: not deleted, effectively unmaintained though. (10:50:19) thl: rdieter, that's IMHO not a big problem as long as security stuff get's fixed (10:50:33) jwb: it makes the packages available under orphans too (10:50:34) tibbs: And who is going to do that if the maintainer won't bother? (10:50:39) jwb: someone else (10:50:46) thl: and security fixes are not needed that often (10:50:58) thl: tibbs, the security sig can jump in (10:50:59) rdieter: doesn't matter really, the issue is the same, core doesn't support legacy releases, neither should Extras (officially) (10:51:38) nirik: there are currently 24 open/new/assisgned bugs against fc3 extras packages... and 72 against fc4. (10:51:39) thl: rdieter, well, we IMHO need to maintain a common look and feel to the outside (10:51:40) abadger1999: nirik: That's part of the question. Do we have Extras Legacy to pick up those pieces? Are they simply orphaned? Do we "force" (and how exactly do we do that?) the primary maintainers to fix the Legacy releases as well? (10:51:40) rdieter: if maintainers want to help out legacy-team/project and and continue support for legacy releases, fine... (10:52:06) thl: rdieter, so either suppport all (Core and Extras) only for s short time; or both for longer (Legacy and Extras) (10:52:16) jwb: forcing anyone to do it won't work (10:52:39) rdieter: thl: yeah, Core+Extras for supported releases, legacy-team/project gets everything else. (10:52:53) thl: rdieter, they are overloaded already afaik (10:53:02) abadger1999: jwb: +1. If Extras maintainers are to do it, we need massive buy-in from them. (10:53:03) nirik: IIRC legacy doesn't want to maintain extras legacy too. (10:53:03) tibbs: Oh, sure, just try telling that to the legacy folks. (10:53:05) rdieter: right, *for a reason*. (10:53:06) thl: so this will not work and we can drop it right from the start afaics (10:53:15) rdieter: supporting legacy, frankly, sucks. (10:53:29) jwb: i think we're making this too hard (10:53:38) rdieter: and it's hard work, taking away from good work that can be done on *current* releases. (10:53:38) thl: jwb, +1 (10:53:45) bpepple: jwb: agreed. (10:53:54) tibbs: Then how to make it easy? (10:54:13) dgilmore: rdieter: but its not that time consuming here and there to fix and test a security fix (10:54:14) rdieter: imo, Easy = Extras doesn't (officially anyway) support legacy, period. (10:54:17) jwb: thl, that's the 1,000,000 dollar question (10:54:20) jwb: er, tibbs (10:54:39) ***dgilmore guesses that there are many many security bugs in extras that are unknown (10:54:43) jwb: rdieter, ok.. but nothing should _prevent_ _other_ people from doing so (10:54:51) rdieter: dgilmore: fine, if a maintainer *wants* to support/help-out legacy, fine, but it shouldn't be forced policy (imo) (10:55:02) bpepple: rdieter: +1 (10:55:05) thl: dgilmore, I thought we have security SIG to prevent that? (10:55:05) tibbs: If we're going to say that maintainers aren't expected to help maintain old releases, then there needs to be a way to indicate that. (10:55:13) dgilmore: rdieter: it should be strongly encouraged tibbs tibbs|h (10:55:25) dgilmore: thl: we do (10:55:31) tibbs: I proposed a flag in each unmaintained branch in CVS, but that was discouraged. (10:55:45) rdieter: dgilmore: +1 fine, but I oppose making legacy support mandatory/obligatory (10:55:50) gregdek_gone is now known as gregdek (10:55:52) abadger1999: tibbs: Perhaps for now we could have a mailing list that maintainers can set bugzilla reports to? (10:56:07) dgilmore: thl: im not saying just legacy extras but current also. not many of the smaller oss projects get security audits (10:56:11) jwb: abadger1999, i like that idea (10:56:17) scop: I think the security SIG is quite seriously in need of more manpower, btw, not only for legacy issues (10:56:20) abadger1999: So if I don't want to maintain FC3 but a security bug is open for that release, I reassign to that mailing list? (10:56:20) tibbs: You can't set bugzilla destinations separately per release, can you? And if you can, how do we tap into that? (10:56:24) nirik: how about reassign all bugs to a 'feN-orphan' when it goes to legacy, and then if people want to step in they can? (10:56:41) scop: s/security sig/security response team/ (10:56:52) dgilmore: scop: +1 (10:57:07) thl: nirik, I think packages in legacy supported dists don't need any bugfixes (10:57:15) thl: only in case of security issues (10:57:37) thl: and that's normally not to much work afaics (10:57:47) dgilmore: abadger1999: extras security issues should get CC'd to fedora-security-list redhat.com (10:58:24) nirik: so maintainers could close WONTFIX any bug report, if it's security they fix it, or cc the security list to look at it? (10:59:07) dgilmore: they should CC the security list and say they dont want to fix it so its known someone needs to do it (10:59:14) thl: nirik, I think that roughtly how it should work (10:59:19) rdieter: yup. tibbs tibbs|h (10:59:38) abadger1999: dgilmore, scop, tibbs: ISTR the security team didn't want to handle legacy. Is that correct? Does that apply? (11:00:06) tibbs: The point is that the security team doesn't want to be the only people doing legacy work. (11:00:15) scop: speaking for myself, *I* have no interest in legacy (11:00:20) dgilmore: abadger1999: where did you get that idea? (11:00:25) tibbs: It exists to help maintainers with security stuff. (11:00:40) thl: abadger1999, there was somebody who wanted to work in the security team to maintain FE3 (11:00:42) tibbs: Not to fix all of the security issues in Extras. (11:00:47) thl: otherwise we had EOL'ed it last june (11:00:49) rdieter: scop: I don't think many do... (including me either, frankly) (11:00:53) abadger1999: dgilmore: I guess from scop and tibbs :-) (11:00:53) dgilmore: abadger1999: im mostly intrested in legacy as far as extras goes as i support Extras for Aurora Linux (11:01:11) dgilmore: abadger1999: that is extras security (11:01:46) ***nirik sees the security list is low traffic and subscribes. (11:02:15) dgilmore: thl: it was I who wanted FE3 to continue support (11:02:22) thl: dgilmore, I know ;-) (11:02:39) thl: well, I'll try to prepare a mail on this topic and will send it to the list (11:02:47) dgilmore: but honestly i dont have alot of intrest in FE4 as Aurora doesnt have a FC-4 build (11:02:54) dgilmore: but it will have a FC6 build (11:02:55) thl: we can revisits this topic then next week (11:03:11) abadger1999: Maybe we should cherrypick releases? (11:03:31) abadger1999: FE3 is a supported legacy platform, FE4 is not? (11:03:40) abadger1999: (Would have to coordinate with regular Legacy though) (11:03:46) thl: abadger1999, that would we a good solution for core, too (11:04:11) nirik: or the suggestion on the security list of only fixing HIGH/CRITICAL vulnerabilities. (11:04:18) thl: abadger1999, let's talk with f13 about that aftger FC6 is finished (11:04:20) nirik: leaving the more minor stuff alone. (11:04:26) abadger1999: thl: k (11:05:01) thl has changed the topic to: FESCO Meeting -- fee dsicussion (11:05:11) thl: anything else we shound discuss? (11:05:15) jima: how much is the fee? (11:05:18) thl has changed the topic to: FESCO Meeting -- free dsicussion (11:05:32) thl: stupid me again :-/ (11:05:34) scop: how free is the dsicussion? (11:05:39) ***scop ducks (11:05:46) jima: scop: hey now, you're just beating a dead horse ;) (11:05:48) dgilmore: scop: as free as you want it to be (11:05:49) ***thl hits scop with a stick (11:05:53) jwb: scop, free as in speech ;) (11:05:56) ***scop screams (11:06:09) nirik: are all the EVR problems going to get fixed before fc6 is out? (11:06:12) dgilmore: scop: put some clothes on :D (11:06:35) delero: itpp approved! (11:06:50) tibbs: Are the EVR problems actually being reported to the core folks? (11:07:04) ***nirik was wondering that too. (11:07:27) nirik: mozilla at least would need to be fixed in legacy (11:07:33) tibbs: I think they probably aren't, becuase the fixes are so easy and yet haven't been done. (11:07:50) tibbs: Honestly the FC5 > FC6 ones really do need to get fixed. (11:07:54) nirik: delero: ed will be happy to hear that. ;) (11:08:24) rdieter: gotta run, lunch is calling... (11:08:26) tibbs: But I fear it's too late to fix them. (11:08:36) abadger1999: I think ?jima gave f13 heads up about the Core packages (11:08:43) thl: seem we need somebody from core that looks at the EVR problems mail now and then to poke the proper people (11:08:45) abadger1999: rdieter: See you later (11:08:58) thl: rdieter, cu (11:09:12) rdieter is now known as rdieter_away (11:09:35) jima: abadger1999: correct. (11:09:42) thl: anything else? (11:09:53) scop: it'd be nice to have a "bugger" script that would file bugs instead of/ in addition to list spams for the upgrade paths and other things (11:09:54) thl: otherwise I'd say we close the meeting for today (11:09:57) jima: err, i gave f13 a heads-up about packages tagged fc5 (11:10:08) thl: scop, that would be the best (11:10:13) jima: he resolved one of the two, last i checked. (11:10:28) dgilmore: thl: i think we are done (11:10:35) mspevack left the room (quit: "Leaving"). (11:10:36) ***thl will close the meeting in 30 (11:10:39) tibbs: scop: I could generate about 10000 bugs that way. (11:10:43) ***jima still sees perl-PDL-2.4.2-4.fc5.1.ppc.rpm (11:10:49) scop: tibbs, ;) (11:10:52) ***thl will close the meeting in 15 (11:11:08) thl: -- Mark -- Meeting end }}}
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
