(Redirected from Packaging:IRCLog20060720)
(09:06:27) The topic for #fedora-packaging is: Channel for Fedora packaging related discussion | Next Meeting: Thursday, July 20th, 2006 16:00 UTC (09:06:51) spot: lets try to do the easyfix items (09:07:02) spot: RPMGroups (09:07:15) spot: right now, the RPMGroups page is confusing, it has two lists of groups (09:07:18) tibbs: I added the second list there just to show what was actually being used in core. (09:07:27) tibbs: That was a long time ago, though. (09:07:31) scop: I say we stick with /usr/share/doc/rpm-*/GROUPS and be done with it (09:07:42) scop: Group is not very useful today anyway (09:07:51) spot: i agree that Group is pretty much throwaway (09:07:57) scop: comps works better, but *some* Group tag needs to be set (09:08:12) spot: it would be worth seeing how much of what is in Fedora is not in /usr/share/doc/rpm-*/GROUPS (09:08:21) tibbs: So no Dev/Lib/Java? Core folks seem to really want it. (09:08:34) abadger1999: We don't have dev/lib/python... (09:08:34) scop: I wonder why that would be an exception (09:08:52) tibbs: No idea, myself. Java wants to be special all over. (09:08:56) scop: note that everything imported from jpackage probably has something that's not in GROUPS (09:09:10) scop: because jpackage uses freshmeat (or was it sourceforce?) categories (09:09:28) spot: one option would be to take everything that exists today in core or Extras and make it the "standard" (09:09:38) tibbs: Some of that really is crap, though. (09:10:07) spot: perhaps we should just compile a list of everything in use and try to simplify that (09:10:38) scop: too much work IMO... turns this something that's not an easyfix (09:11:02) spot: this is utterly irrelevant, but we know the Java folks will get up in arms over it (09:11:16) spot: and there is really no technical reason we can't permit Dev/Lib/Java in Group (09:11:29) thimm [n=thimm] entered the room. (09:11:48) tibbs: If anything needs its own group for reasons of quantity, it would be Perl. (09:11:52) scop: there is no technical reason why it couldn't be proliferated completely, either (09:12:30) spot: we need to standardize on something, i worry that the GROUPS file in rpm is too restrictive (09:12:47) thimm: esr had suggested Troove (09:13:08) abadger1999: Does using trove require changing the way rpm behaves, though? (09:13:17) spot: umm, i have no idea what Troove is. this looks less and less like an easyfix to me. (09:13:28) scop: well, if someone wants to work on it, be my guest, but I'll put a blanket 0 vote for anything else than sticking with GROUPS (09:13:32) abadger1999: Or is the suggestion to just use some sort of separator character? (09:13:53) spot: i'll work on this one, lets set it aside for now (09:14:02) abadger1999: (Trove is what sourceforge and freshmeat use. It was an esr project at one point.) (09:14:28) abadger1999: (Allows multiple catagories) (09:14:29) thimm: abadget1999 & spot: troove is the categiry used at freshmeat for instance (09:14:38) tibbs: http://catb.org/~esr/trove/ (09:14:44) thimm: Just another set of GROUP-like entries (09:14:53) spot: i'll look into trove. see how disruptive it would be. (09:15:10) spot: Next easyfix: Perl tweaks (09:15:37) spot: basically, this is the removal of OPTIMIZE for noarch packages and marking up the perl template (09:15:38) scop: *cough* notabug *cough* (09:15:58) spot: is it worth just making two templates? (09:16:25) tibbs: No need for two templates. Just needs to be clarified that cweyl's packaging style is forbidden. (09:16:37) tibbs: Either that or people stop flaming me. (09:16:43) tibbs: I leave it to the committee to decide. (09:16:52) spot: tibbs: where he is using OPTIMIZE for noarch? (09:16:54) abadger1999: Was there a reason that packaging style is forbidden? (09:17:05) tibbs: Ralf says so. (09:17:15) racor: spot: all over the place (09:17:35) tibbs: Let me dig up a spec... (09:18:12) scop: the perl spec template can be easily modified to fail if no *.bs are present but the line removing them is there (09:18:14) spot: OPTIMIZE isn't actually harmful on noarch, doesn't do anything, just makes it a bit more cluttered, right? (09:18:20) scop: but is it REALLY worth it? (09:18:28) tibbs: http://cvs.fedora.redhat.com/viewcvs/rpms/perl-POE-Filter-IRCD/devel/perl-POE-Filter-IRCD.spec?root=extras&rev=1.2&view=markup (09:19:05) cweyl: in my own defense -- and I defer to the committee -- I'd only left them in to try to stick as close to the spec template as humanly possible. (09:19:10) ***cweyl shuts his rabble mouth now :) (09:19:20) scop: that is not the purpose of templates (09:19:34) ***spot hates to have to write down too much "use your own common sense" (09:20:01) spot: i think adding a comment to the template above the entries where items are not needed for noarch is sufficient (09:20:23) spot: # if the package is noarch, remove the following line (09:20:36) tibbs: I posted a proposed patch that did this. (09:20:50) racor: racor: I had hoped so, but the tibbs/cweyl experience has taught me wrong (09:21:16) tibbs: The entire world doesn't share precisely the same opinion as you. (09:21:31) spot: alright. lets vote on adding the comments to the template (man, this is minor) (09:21:39) thimm: +1 (09:21:41) scop: 0 (09:21:48) tibbs: +1 (09:21:58) racor: +1 (09:22:01) spot: +1 (09:22:02) abadger1999: It's scops package.... (09:22:18) scop: abadger1999, that does not mean that I get to decide on packaging guidelines alone (09:22:26) jpo: gvim (09:22:37) abadger1999: +1, then. (09:22:41) scop: jpo, rm -rf / # :) (09:22:55) spot: jpo: wrong window, this is the voting on comments window (09:23:12) jpo: +1 (and I will also update an old document I had describing the perl specfile template) (09:23:18) spot: ok, passes with 6 (09:23:19) thimm: That's 6 (09:23:19) jpo: (sorry) (09:23:55) spot: next easyfix: directory ownership in perl-land (09:24:02) scop: I'll add those comments right away (09:24:15) scop: any examples? (09:24:19) spot: right now, most of the perl packages are owning directories that other packages own. (09:24:23) scop: (of the dupe ownership) (09:24:27) tibbs: We just need to loosen up that statement a bit. (09:24:34) rdieter: * arrives (sorry I'm late) (09:25:11) tibbs: perl-Net-Blah will live under blahblah/Net/Blah and therefore must own the Net directory. Other modules do the same. (09:25:12) racor: and it's right(tm) they are doing so. (09:25:21) spot: the directory ownership rules were designed to ensure that if rpm ever evolved into something that could perform sane ordered removals, we wouldn't need drastic changes (09:25:27) racor: perl modules aren't a strict hierarchy (09:25:53) racor: nor does a strict owner<->module correspondence exist (09:26:00) scop: many unrelated Net-Foo modules may install into blahblah/Net (09:26:09) spot: the suggestion is that it be reworded to say "packages must not own files or directories already owned by any package above it in the dependency chain" (09:26:15) scop: s/unrelated/independent/ (09:26:44) spot: this would pretty much bring perl into compliance (09:27:08) racor: spot: -1, this is not applicable to perl-modules (09:27:35) tibbs: This hits other things as well; perl is just the simplest example. (09:27:47) spot: racor: sure it is. if perl-Net-Foo requires perl-Net-Bar, and perl-Net-Bar owns a directory, then perl-Net-Foo can't own it (09:28:06) spot: but, if perl-Net-Foo doesn't require perl-Net-Bar, then they can both own it (09:28:07) racor: spot: who own Net? (09:28:33) spot: racor: top entry in the dependency chain (09:28:37) rdieter: I think spot's suggestion is reasonable, +1 (09:28:37) jpo: Spot: we also have problems if Net::Bar is a core module (differente base dircetory) (09:28:40) tibbs: Any module with files in Net that doesn't require something that owns Net. (09:29:23) scop: spot++, to me the current wording in the guidelines sounds like a thinko/typo (09:29:32) tibbs: +1 from me as well. (09:29:33) racor: spot: There is NO dependency chain, perl modules line up in parallel (09:29:41) spot: racor: then they can all own it (09:29:43) racor: -1 (09:29:56) spot: if there is no dependency chain, then there is no conflict (09:30:04) tibbs: racor: So what is your suggestion? (09:30:07) racor: spot: exactly (09:30:12) spot: so, my wording: (09:30:33) spot: packages must not own files or directories already owned by a package ::: above it in the dependency chain ::: (09:30:42) spot: note the last part, thats the new change (09:31:00) spot: since there would be no dependency chain ownership for the vast majority of perl modules... (09:31:16) abadger1999: +1 (09:31:19) tibbs: +1 (09:31:22) scop: +1 (09:31:29) thimm: +1 (09:31:31) racor: Do as we do it until now: All perlmodules must own all directories above a *.pm and below vendordir (09:31:39) rdieter: +1 (09:31:41) racor: -1 (09:31:52) thimm: spot: The wording is difficult for newbees (09:31:57) spot: racor: perl is required for perl modules. (09:31:58) thimm: Maybe add an example? (09:32:06) spot: so they don't need to own anything that perl does (09:32:44) spot: but outside of that, what you're suggesting matches up with this guideline (09:32:49) racor: spot: yes (09:32:49) jpo: -1 (09:32:51) scop: how about "..owned by one of its dependencies (recursively)" (09:33:00) jpo: the above fails if we upgrade perl (09:33:08) spot: jpo: how so? (09:33:10) tibbs: I don't see why Perl alone should be special in this. (09:33:10) jpo: 5.8.8 -> 5.8.9 (09:33:25) jpo: the base directories can move (09:33:43) spot: mmm. that is a good point. (09:33:48) spot: perl is unique in that aspect (09:33:50) jpo: we have to rebuild everything when a new perl version gets released (09:33:56) racor: tibbs: perl isn't necessarily special, other scripting langs might have this issue, too. (09:33:57) scop: ? (09:34:30) scop: newer perl versions own their backwards compat dirs too (09:34:41) tibbs: By that reasoning, any package might have this issue. (09:34:44) spot: scop: if that's the case, then we're covered (09:34:44) rdieter: scop's right, just checked. (09:34:45) jpo: yes but now upgrade Net::Bar (09:35:00) jpo: without rebuild Net::Foo (09:35:06) tibbs: Which leads to every package owning every directory except ones that are guaranteed not to change. (09:35:13) scop: oh, now I got it (09:35:48) thimm: How important is proper directory ownership (let me continue): (09:36:04) thimm: Either it's important becasue we don't want leftovers (09:36:13) racor: thimm: It assures proper cleanups. (09:36:19) thimm: and then we should consider a long.term solution (fixing rpm) (09:36:32) scop: rpm has already been fixed upstream... (09:36:34) thimm: or it's not ... (09:36:38) spot: scop: no, it hasn't. (09:36:47) spot: not as of three weeks ago at least. (09:36:50) scop: spot, wrt. erasure order? (09:36:53) spot: scop: yes. (09:37:15) spot: i dont have the bugzilla handy, but jbj claimed it was fixed and i tested the example and it still failed (09:37:15) scop: spot, jbj has told me otherwise in bugzilla (09:37:24) scop: ok, I see (09:37:38) scop: spot, are you using upstream rpm? (09:37:40) ndim [i=hun] entered the room. (09:37:48) spot: scop: i built upstream rpm for that test (09:37:56) scop: ack (09:38:17) thimm: I'm not thinking of ordering only, but of implicitely owned dirs (09:38:30) spot: so, the original reason that i wrote the directory ownership rule was to make life easy if rpm ever fixed itself (09:38:35) tibbs: Looks like nothing's an easyfix today. (09:38:47) scop: unowned dirs also (at least used to) break with 0700 umasks when installing (09:39:05) racor: thimm: which implicitly owned dirs, this case doesn't happen with perl-modules (09:39:49) thimm: Racor: Implictly owned dirs would be defined as all dirnames of all explicitely mentioned files/dir in %files (recursively) (09:40:04) thimm: with a potential cap to avoid each and every package to own /, /urs and so on (09:40:17) spot: the only way that i can see perl modules not breaking (because perl can shift underneath them) is for perl modules to own the entire directory structure they live in (09:40:38) thimm: aka implicitely onwed dirs :) (09:40:59) rdieter: spot: I don't see that, since perl owns all the "shifted" dirs. ?? (09:41:00) thimm: It's a backwards compatible change in rpm (09:41:20) thimm: rdieter: consider another setup (09:41:27) scop: okay, example time (09:41:30) devrimgunduz left the room (quit: "Leaving"). (09:41:31) thimm: perl-Net-A depends on perl-Net-B (09:41:39) thimm: So perl-Net-B has ownership (09:41:48) thimm: perl-Net-B gets rebuilt for newer perl (09:42:00) rdieter: OK, I see where you're going... (09:42:02) thimm: suddenly perl-Net-A is installed in unowned dirs (09:42:10) rdieter: yuck. (09:42:34) rdieter: and, since we can't guarantee they'll all get upgraded atomically... (09:42:52) racor: non issue, if both own the dirs the use (09:42:55) scop: so how about spot's wording, plus an exception for things installed into versioned dirs that are subject to changes like this? (09:43:28) rdieter: racor: yep, so we need an exception for verioned dirs (09:43:31) tibbs: The Perl packaging page would also need to be updated to indicate this issue. (09:43:44) thimm: Too many rules, exceptions :( (09:43:55) thimm: We need a general attack against dir ownerships (09:44:16) thimm: Today it's perl, tommorrow it's something else and the guideline will have special handling all along (09:44:23) rdieter: thimm: do you have a better suggestion? (09:44:29) thimm: I suggest to keep specfiles small and target fixing rpm (09:44:43) thimm: To add implicitely owned dirs to the package's manifesto (09:44:49) racor: tibbs,thimm: You both are solving non-issue, perl package in FE work this way since ever they exit. (09:45:10) tibbs: racor: We still have to document it so that people will know what to do.l (09:45:11) spot: racor: yes, but they have been violating the guidelines (09:45:23) spot: we're trying not to change perl, but change the guidelines to fit perl (09:45:32) racor: jpo once had it written up somewhere for fedora.us (09:45:44) jpo: http://gsd.di.uminho.pt/jpo/perl/specfiles/specfiles.html (09:46:27) spot: iirc, that document doesn't cover directory ownership (09:47:13) jpo: I will update it to FE (and also add examples about the directory ownership) (09:47:17) rdieter: nice. (09:47:28) tibbs: "Packages should not own files or directories already owned by other packages except when that is not possible" ? (09:47:41) tibbs: Nice and vague. (09:47:55) scop: it's always possible :) (09:48:10) rdieter: and don't forget: "except on cloudy tuesdays" (09:48:22) spot: i really don't want to write anything vague. (09:48:39) tibbs: spot: Then pick a list of system directories not to be owned and leave it at that. (09:49:14) spot: tibbs: that doesn't solve the problem that the ownership rule is trying to solve (09:49:25) tibbs: Nothing else seems to either. (09:49:36) tibbs: But at least that rule is unambiguous. (09:50:56) rdieter: since these things can get upgraded at any time (including perl itself), I see no better alternative to the perl packaging practice as it is now... (09:51:00) scop: "...except when not doing so could conceivably cause unowned directories due to changes in dependencies" ? (09:51:24) tibbs: How about sticking with the "don't own directories owned by your dependencies" and living with the corner case of unowned directories on perl module upgrades? (09:51:24) spot: How about this: A package should own all the files and directories it creates, unless: A) one of its dependencies already owns it or B) it is in a versioned path (e.g. perl) (09:51:40) rdieter: spot++ (09:51:47) tibbs: spot: +1 (09:51:58) thimm: Still has the issue with dependent packages moving to new perl folders (09:52:10) spot: thimm: old perl owns all the compat dirs (09:52:23) jpo: spot: perl modules going core (09:52:27) thimm: No, I mean the exmaple with perl-Net-A and perl-Net-B above (09:52:42) tibbs: That's in a versioned path, no? (09:52:42) scop: "versioned" might not be the only case where this matters (09:52:54) spot: thimm: yeah, thats a versioned path (09:52:58) thimm: k (09:53:08) racor: all perl modules depend perl(:MODULE_COMPAT_XXX), (09:53:16) tibbs: A definition of "versioned path" will be necessary in any case. (09:53:27) racor: this would break and should trigger packagers to rebuild (09:54:03) spot: racor: are you saying that the perl-Net-A perl-Net-B example shouldn't be possible? (09:54:25) tibbs: New core perl packages will provide the old module_compat symbols (assuming that they didn't break compatibility, of course). (09:54:33) racor: spot: I say it's impossible (09:54:57) spot: so... if so, then we really don't need the versioned path exception? (09:55:14) scop: racor, I disagree until proven otherwise (09:55:20) abadger1999: I think the perl-Net-A and perl-Net-B is still broken (ie: perl-Net-A creates and owns Net/ & Net/A perl-Net-B requires perl-Net-A and owns Net/B perl-Net-A moves and then nothing owns Net/) (09:55:39) scop: exactly (09:55:43) racor: not if both own the dirs (09:55:59) spot: racor: but in order for them both to own the dirs, we need the exception (09:56:13) thimm: Is this checken and egg? :=) (09:56:40) spot: the exception will let perl-Net-A and perl-Net-B own the dirs (09:56:44) spot: thus, the problem is avoided (09:56:53) ***scop quietly parrots "...except when not doing so could conceivably cause unowned directories due to changes in dependencies" (09:57:01) racor: Nope, just document what all perl packagers currently do, and what the perl template does. (09:57:19) racor: <~~ bureaucrats (09:57:47) spot: We need a simple rule for the majority, and we need a way to let perl do what it needs to do (09:57:51) scop: 3 minutes, by the way (09:58:11) spot: i think what i've proposed will do this effectively, AND we can document all the fun stuff that perl and its template does (09:58:17) tibbs: So, again, Perl alone gets to be special? The point is to have a single rule that applies to all packages where this is needed. (09:58:32) abadger1999: spot: Don't we need the opposite of the exception? A package should own all the files and directories it creates, unless one of its dependencies already owns it. The exception to this exception is when the package resides in a versioned path (ie: perl) and doesn't depend on the package providing the versioned path. Then you must still own the directories even though another package provides them. (09:58:38) jpo: What other exceptions we have besides perl? (09:58:54) abadger1999: Which obviously isn't suitable for the guidelines, but I think is the correct logic.... (09:59:04) spot: abadger1999: umm, yes. thats right. (09:59:07) racor: spot: It already does so. (09:59:10) rdieter: abadger1999++, nice general rule. (: (09:59:27) spot: racor: it does not say that. right now, perl is in violation. (09:59:50) scop: what does the "the" in "must still own the directories" mean? (10:00:04) scop: exactly what directories? (10:00:08) racor: spot: I really find it poor, to require this amount of bureaucracy.- (10:00:34) spot: racor: simply because you know how to do everything properly without clear documentation does not mean that everyone does. (10:00:41) thimm: YEs, we should nail the problem at the root, rpm. (10:01:08) thimm: We're trying to meneuver around a design limitation of perl, which is fixable IMO (10:01:19) spot: well, thats all of our time. we'll try and revisit this next week. (10:01:20) thimm: s/perl/rpm/ (10:01:21) tibbs: Can we agree in principle that the current guideline needs to change? (10:01:27) racor: thimm: it's not a limitation it's a feature (10:01:43) abadger1999: scop: Hmmm... for perl it would be everything not owned by perl through the perl(:MODULE_COMPAT_XXX) stuff. (10:01:45) thimm: Not really, but the time is up ;) (10:01:45) rdieter: yes, we need clarification (change) (10:01:57) scop: clarification++ (10:02:25) rdieter: I think abadger1999's last suggestion makes the most sense. (10:02:30) racor: It's every dir below /usr/lib/perl/*/ (10:02:52) jpo: racor: not owned by the perl package (10:03:03) racor: jpo: yes ++ (10:03:05) f13: d'oh! I missed the meeting. (10:03:07) f13: sorry guys. (10:03:40) abadger1999: clarification++ but the rule to describe it is so complex maybe we're pursuing the wrong direction. (10:03:51) f13: so did anything get decided on today? (10:04:17) tibbs: f13: We agreed to tweak the Perl template to solve the flame war over cweyl's packages. (10:04:20) rdieter: don't think so. ): (10:04:29) rdieter: ok, that's something anyway. (10:04:36) scop: yes, comment addition to perl spec template (10:04:57) tibbs: We agreed to do something about RPM groups, but I'm not sure what. (10:05:17) abadger1999: think about them? (10:05:22) abadger1999: think real hard? (10:05:24) f13: ok. (10:05:49) ***f13 tries to remember what was tabled last week. (10:05:51) f13: oh yeah. (10:05:55) f13: arch specific noarch packages. (10:05:57) scop: spot promised to have a look at groups (10:06:04) spot: i'm going to look at groups (10:06:23) abadger1999: Darn. We should have voted whether to remove the double list until then. (10:07:05) tibbs: The double list was just something I added to show what was in use at the time. it shouldn't be part of any guideline. (10:07:07) abadger1999: Since that's just recording that there's a discrepancy, not showing a policy. (10:07:17) abadger1999: tibbs: Right. (10:07:38) tibbs: I'm happy to delete it now, although I'll leave the command line in case someone finds it useful. (10:08:55) jpo: scop: Any luck with bugzilla's XML::RPC/SOAP interface? (10:09:21) scop: jpo, no, nobody ever responded to my request for pointers to documentation :( (10:09:35) scop: so I haven't done anything about it (10:09:54) abadger1999: tibbs: I'm for that -- is that fine with others? (10:10:27) scop: certainly (10:10:57) jpo: bummer. I will have to play with WWW::Bugzilla (10:11:17) cweyl: jpo: I could never get that to work as expected with RH bugzilla. (10:11:52) jpo: I am able to extract comments from tickets with it (10:11:56) cweyl: which might be just me, FWIW, but I think RH added additional fields that WWW::Bugzilla isn't handling. (10:12:10) cweyl: hmm.. I was trying to create bugs (10:12:33) jpo: Haven't tried yet. But I will try. (10:12:43) ndim: I have used SOAP to access bugzilla. AFAICT, one receives the complete metadata concerning the components, products, versions, and so forth. (10:12:58) ndim: Then one can use these to query stuff. (10:13:46) ndim: However, the data structure containing all that metadata was a little complex, so I didn't manage to write a clone of Debian's reportbug for Fedora within a few hours. (10:13:50) jpo: ndim: Do you have links to examples/docs? (10:14:02) f13: crap (10:14:08) ndim: jpo: Wait a sec, I'm looking for the code. (10:14:13) f13: we didn't decide in a java naming scheme did we? (10:14:18) ***f13 sees a java package up for Core review (10:14:19) jpo: I only found this https://bugzilla.mozilla.org/show_bug.cgi?id=224577 (10:14:39) abadger1999: f13: It must either follow the current naming guidelines or it can't go in :-) (10:15:01) spot: there has not been any changes to the naming scheme. (10:15:43) f13: feck. (10:15:46) f13: it won't make it in then. (10:15:56) abadger1999: We need a response from gbenson et al about what the goals are for putting the jpackage version in the Release otherwise we're stalled (and stalled means Guidelines remain as they are.) (10:15:56) f13: and since this week is the feature freeze.... (10:16:14) abadger1999: We can vote over email. But we need the extra information. (10:16:23) spot: f13: see what abadger1999 said. this is what is holding us up. (10:16:41) f13: nod (10:22:43) ndim: jpo: http://n-dimensional.de/software/fedora-reportbug/ and the code is based on http://people.redhat.com/jrb/files/bugtool-0.1-1.src.rpm (10:23:37) jpo: ndim: thks (10:30:26) ndim: jpo: The query-info.txt is the collected metadata one needs to grok the structure of. (10:31:07) scop left the room ("Leaving"). (10:40:34) racor left the room (quit: "Leaving"). (10:46:23) jorge__ [n=jorge] entered the room. (10:58:59) jpo left the room (quit: "Leaving"). (11:26:53) tibbs: Is anyone still interested at all in getting the PHP stuff finished? (11:32:07) abadger1999: tibbs: Tangentially related: I think it's time to start running the agenda according to priority rather than ease of fixing. (11:32:39) tibbs: abadger1999: I think you're correct. Unfortunately arriving at concensus is just taking too much time. (11:32:45) tibbs: More pre-discussion on-list would help. (11:35:48) abadger1999: Yes. I think we're not doing enough of our homework :-) we need to start coming up with -- 1) This is the proposal. 2) What issues do people see with them? 3) We will vote on this by the end of the week. (11:36:07) abadger1999: So then we have an incentive to identify any issues we have before we get to the meeting. (11:57:15) f13: spot: might want to move http://fedoraproject.org/wiki/DistTag under Packaging/ (11:57:35) spot: f13: i'll do that right now (12:02:23) spot: moved, and a redirect put in place. (12:07:03) f13: cool (12:07:17) tibbs: I'd really like to clean up ReviewGuidelines, but now it's a committee issue.... (12:08:04) tibbs: I guess I'll copy it into the drafts hierarchy and start hacking at it. (12:08:05) abadger1999: Make a draft and then we can vote on it as one chunk of changes. (12:08:14) abadger1999: tibbs: You read my mind. (12:08:55) tibbs: Needs to be split into ReviewProcess so the reviewer can just see the guidelines without that huge screenshot. (12:09:10) tibbs: All of the checklist items need to link back to the guidelines. (12:09:27) tibbs: And I think there are still a few MUST items in that list that aren't reflected in teh guidelines at all. (12:10:12) tibbs: abadger1999: As if we could actually get a clean vote on anything. (12:12:30) abadger1999: spot, f13: I moved previous meeting's decisions into Action Items with "ratify" next to them. For things that got an okay from FESCo/Fedora Core, they should be changed to "writeup" (so we know they're all but done) or moved into the resolved section if it's all done. (12:12:56) f13: abadger1999: sounds good to me. (12:13:08) abadger1999: tibbs: heh. Just wait, in a few months we'll be rubber stamping everything :-) (12:13:14) tibbs: Yum. 2000 messages in linux-kernel. (13:08:14) f13: whoops (13:08:30) f13: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a <-- those kismet packages have no Version, just a Release. (13:10:13) abadger1999: 1.0 what we want for the version? (13:15:14) f13: well, pre-release will probably be Version 0 (13:15:26) f13: post-release could be 1.0 (13:15:37) f13: or actually pre-release 0.1 (13:15:57) f13: kismet-0.1-0.2.<date>svn.fc6 (13:16:49) abadger1999: Unless upstream's first release is kismet-0.0.1.tar.gz :-) (13:19:28) abadger1999: spot gave the packaging group edit permission today. I'll change it to kismet-0-0.2.<date>svn.fc6 (13:19:36) abadger1999: Does that look right? (13:20:37) tibbs: Shouldn't RPMGroups be under Packaging? (13:24:25) f13: abadger1999: sure. (13:29:04) abadger1999: f13: Changes saved. (13:33:14) ***f13 has a possible solution to jpp naming fun. (13:33:26) f13: fnasser is mulling over proposition will echo here in a moment. (13:33:50) abadger1999: Cool (13:34:10) tibbs: Awesome. (13:37:05) ***spot passes out from holding his breath (13:37:31) f13: ok. (13:37:40) f13: Jpackage releases foo-1.0-5jpp (13:38:00) f13: Fedora rebuilds it as: foo-1.0-6.fc6, and one more time as foo-1.0-6.fc6.1 (13:38:11) f13: Jpackage then goes on to release foo-1.0-6jpp (13:38:35) f13: -6jpp will be rpmnewer than -6.fc6, so jpackage newer package cna take precidence (Goal #1) (13:38:49) f13: Fedora respins 6jpp into foo-1.0-7.fc6 (13:39:10) f13: spec file can have a comment: # Based on 6jpp, # Based on 7jpp (13:39:22) f13: (goal #2) (13:40:00) f13: Goal #3 is not really obtainable. (13:40:10) spot: fnasser was ok with that? (13:40:17) tibbs: Seems imminently reasonable, and generalizable to any situation where we want to interleave releases with upstream. (13:40:25) tibbs: What was goal 3? (13:40:30) spot: tibbs: profit (13:40:49) spot: sorry, old joke. (13:40:55) tibbs: http://www.google.com/finance?q=RHAT (13:41:00) f13: spot: fnasser doesn't immediately hate it, and will be thinking about it over night and talking with other folks. (13:41:22) f13: Goal 3 was 'Update only jpp packages from jpp, update only Fedora packages from Fedora' (13:41:31) spot: i personally like it. it only requires some careful documentation for Packaging/Java and no overarching changes (13:41:32) f13: http://www.fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming (13:41:43) f13: spot: yep, 0 changes to guidelines (13:42:02) abadger1999: I like it too. (13:42:12) spot: also, it gets all of that _jpp8675309 nonsense OUT OF FEDORA. (13:42:12) f13: the only thing is we have to wait for a new jpp release before existing packages can move (13:42:30) f13: actually, no, it doesn't (13:42:38) f13: wow, thats even better than I thought. (13:42:50) f13: any 6jpp package in fedora can just become 7 (13:42:55) spot: f13: you win the internet. (13:43:01) ***f13 adds to the draft (13:43:26) tibbs: Are we assuming that jpp won't get hooked on the crackrock and release blah-220.127.116.11jpp? (13:43:42) tibbs: sorry, blah-1-18.104.22.168jpp. (13:44:45) spot: tibbs: supposedly, the jpp rules don't permit this (13:44:57) tibbs: As long as they don't, we should be in good shape. (13:44:59) spot: but if they screw around, we can angrily point at them. (13:46:00) abadger1999: How does this interact with snapshots? (13:47:40) tibbs: What are the jpackage rules about snapshots? Assuming they have any. (13:47:48) abadger1999: I think this is jpp's format: foo-1.0-0.20060525.5jpp (13:48:03) abadger1999: Judging from example, not from reading their guidelines.) (13:48:31) abadger1999: (And there are some examples that don't match up with this either.) (13:51:10) f13: still works. (13:51:19) f13: although breaks our pre-release guidelines. (13:51:24) f13: although... (13:51:37) f13: foo-1.0-0.20060525cvs.6.fc6 (13:51:59) f13: just won't work when they do the same snapshot but 6jpp, because our 'cvs' will make the snapshot newer (13:52:54) abadger1999: Yeah -- this part I don't like so much. The integer release number should come before the snapshot information. (13:54:36) f13: spot: can I make a small change to NamingGuidelines? Core now supports dist tag, I want to remove that note. (13:55:00) abadger1999: Otherwise this breaks: foo-1.0-0.20060525cvs.6.fc6 => foo-1.0-0.M1.6.fc6 (13:55:27) spot: f13: go ahead (14:05:13) f13: done, and done. (14:05:20) f13: new proposal added. (14:10:34) f13: ok, so I've passed that mental kidney stone.