Meeting:Packaging IRC log 20060720

(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-6.1.7.2jpp?
(13:43:42) tibbs: sorry, blah-1-6.1.7.2jpp.
(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.