16:01:14 <geppetto> #startmeeting fpc
16:01:14 <zodbot> Meeting started Thu Sep 15 16:01:14 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:14 <zodbot> The meeting name has been set to 'fpc'
16:01:14 <geppetto> #meetingname fpc
16:01:14 <zodbot> The meeting name has been set to 'fpc'
16:01:14 <geppetto> #topic Roll Call
16:01:20 <orionp> hello
16:01:21 <geppetto> #chair Rathann
16:01:21 <zodbot> Current chairs: Rathann geppetto
16:01:22 <tomspur> Hi
16:01:27 <geppetto> #chair orionp
16:01:27 <zodbot> Current chairs: Rathann geppetto orionp
16:01:31 <geppetto> #chair mbooth
16:01:31 <zodbot> Current chairs: Rathann geppetto mbooth orionp
16:01:34 <geppetto> #chair tomspur
16:01:34 <zodbot> Current chairs: Rathann geppetto mbooth orionp tomspur
16:02:02 <geppetto> tibbs: you here?
16:02:08 <tibbs> Howdy.
16:02:18 <tibbs> Yes, just distracted.
16:02:47 * Pharaoh_Atem just finished the last updates to the draft versioning spec
16:03:17 <geppetto> #chair tibbs
16:03:17 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs tomspur
16:03:33 <geppetto> Ok, give everyone else a couple more minutes
16:05:24 <geppetto> #topic Schedule
16:05:27 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/ILYFVN7BWITSSUXQ7BQSETIM3LS5ZHUF/
16:05:27 * limburgher here but total space cadet
16:05:34 <geppetto> #chir limburgher
16:05:37 <geppetto> #chair limburgher
16:05:37 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp tibbs tomspur
16:05:49 <geppetto> Space cadet?
16:06:01 <geppetto> #topic #628  Reserve UID/GID for cassandra (allocation process)
16:06:06 <geppetto> .fpc 628
16:06:07 <zodbot> geppetto: #628 (Reserve UID/GID for cassandra) – fpc - https://fedorahosted.org/fpc/ticket/628
16:06:12 <limburgher> My attention is in a different orbit.
16:06:35 <geppetto> Ahh :)
16:06:57 <geppetto> So ... the big problem here is that previously packagers just tended to allocate the uid themselves, after asking us if it was ok
16:07:31 <Pharaoh_Atem> brb
16:07:31 <geppetto> But we kind of had policy saying we would do it ... and the cassandra devs. were like, ok you do it :)
16:07:41 <limburgher> Right.  Which was problematic, leading us to ask us to ask, or use dynamic allocation whenever remotely possible.
16:08:01 <limburgher> ask them to ask us rather.
16:08:03 <limburgher> See?
16:08:48 <tibbs> I've filed a ticket on the trac for the setup folks.  Will wait another day or so and then file a bugzilla ticket against the setup package.
16:08:53 <tibbs> That should be sufficient.
16:08:57 * geppetto nods ... I'm happy to add something that says "when you get a yes, go speak to the setup maintainer and reference this ticket as approval"
16:09:23 <limburgher> Sounds like a plan.
16:09:27 <tibbs> I've also just changed the guidelines to say that FPC will communicate with the setup folks instead of giving the git repository and whatnot.
16:09:44 <geppetto> tibbs: Do we want to do that though?
16:09:46 <tibbs> Because... that was bizarre anyway.  And I don't think any of us ever had access to that repo on Fedorahosted.
16:10:00 <geppetto> Maybe spot did?
16:10:06 <limburgher> I imagine so.
16:10:24 <tibbs> It's just one ticket, referencing our ticket.  I don't think it's a huge deal, and probably better than having the person requesting it do it.
16:10:52 <tibbs> Just need to figure out where the setup maintainers are actually listening.  Their trac had only spam (which is now cleaned up).
16:11:30 <geppetto> ok
16:12:35 <geppetto> We don't get that many uid requests, so even if it takes an extra hour or two dealing with the ticket it's not the end of the world.
16:13:13 <geppetto> I just figure the requester will be happier to deal with it, and likely looking a lot closer at it etc.
16:13:19 <limburgher> Right, and it makes sense to have someone sanity check it, to make sure static allocation is appropriate.  We seem as logical as any a party to do so.
16:14:02 <tibbs> I have no problem doing it, and this way we at least know that it is getting done.
16:14:24 <geppetto> ok ... so nothing to do on this ticket?
16:14:56 <tibbs> Just move it it to writeup until I get a response from the setup folks.
16:15:02 <geppetto> ok
16:15:04 <tibbs> I don't want to forget about it.
16:15:23 <geppetto> I can just mentally ignore it for a couple of weeks too
16:15:25 <geppetto> if that's easier
16:15:32 <geppetto> #topic #646  Versioning the Packaging Guidelines
16:15:38 <geppetto> .fpc 646
16:15:39 <zodbot> geppetto: #646 (Versioning the Packaging Guidelines) – fpc - https://fedorahosted.org/fpc/ticket/646
16:15:41 <tibbs> Nah, I've taken "writeup" to mean "I need to handle this".
16:15:45 <geppetto> :)
16:15:48 * Rathann has to shut off power @home
16:16:00 <tibbs> Ouch.
16:16:10 <tibbs> On 646, I've written my opinion.
16:16:23 <tibbs> I do think there are things we can do a whole lot better.
16:16:39 <geppetto> To quote you: """Personally I'm not interested in adding or maintaining additional version formalization to the guideline pages"""
16:16:42 <geppetto> +1
16:16:50 <tibbs> I don't think we have the ability to go foll-on debian bureaucracy mode.
16:17:19 <geppetto> Debian has a lot of overhead for their guidelines, and we've never really wanted that
16:17:28 <tibbs> If packagers want to note somewhere that they brought a package up to the guidelines as of a certain date, I think that's great.
16:17:39 <tibbs> What we as a committee could definitely be doing, though:
16:18:01 <tibbs> Add rpmlint tests (or filters) when appropriate.
16:18:02 <limburgher> I think that's already accomplished by saying "it's in compliance now" in the changelog, which is, cleverly, dated.
16:18:13 <geppetto> Yeh, reviews post merge would be nice etc. ... but I don't want to version the guidlines. And if others want to then just putting a date there would be fine.
16:18:25 <tibbs> Tell people what they should change, if we pass some guideline that encourages them to change.
16:18:29 <Pharaoh_Atem> it would be nice if the guidelines could be better codified in rpmlint
16:18:37 <tibbs> Do more semi-automated package cleanup.
16:18:44 <geppetto> You/we already publish changelog type summaries too
16:18:53 <Pharaoh_Atem> from my experience, people are somewhat trained to ignore rpmlint nowadays :(
16:18:57 <tibbs> I want to actually say somewhere "Don't use %clean" and then remove it from every package.
16:19:00 <geppetto> Pharaoh_Atem: Yeh
16:19:17 <tibbs> rpmlint has its own problems.  They won't be fixed overnight but we can try to make progress.
16:19:29 <geppetto> tibbs: Why, because everyone uses mock now?
16:19:48 <tibbs> I think it's going to take more manpower than we have to make real progress, unless Red Hat wants to employ someone to do it.
16:20:04 <tibbs> geppetto: Regarding %clean?  Because it's entirely unnecessary on every Fedora and EPEL release.
16:20:07 <Pharaoh_Atem> I'm not saying make rpmlint a giant blocker on packages, but it'd be nice if rpmlint could provide information corresponding to the guidelines, and maybe some mock integration to run against spec, srpm, and built rpms
16:20:10 <tibbs> RPM just does it.
16:20:22 <tibbs> rpmlint already gets run by taskotron.
16:20:30 <tibbs> It's not blocking because it would be useless to make it blocking.
16:20:40 * geppetto nods
16:20:42 <tibbs> I have another proposal related to that, but I'll wait for open floor.
16:20:44 <Pharaoh_Atem> tibbs: sure, but when people do local builds, that when they fix things
16:21:04 <tibbs> Pharaoh_Atem: Sure; the point is that we have infrastructure in place to _enforce_ it.
16:21:14 <Pharaoh_Atem> sure, but I don't think we will
16:21:16 <tibbs> We just can't due to rpmlint and the lack of one thing I want to talk about later.
16:21:26 <tibbs> I think we will eventually, after enough work and that one thing.
16:21:34 <geppetto> ok
16:21:34 <Pharaoh_Atem> alright, now I'm curious :)
16:21:35 <tibbs> I'm talking years, though.
16:21:52 <tibbs> Anyway, I don't know what to do about this ticket.
16:22:05 <geppetto> Close it with -9 votes?
16:22:14 <Pharaoh_Atem> maybe say that there's a plan to address this differently and close it
16:22:29 <tibbs> We can add a guideline section encouraging maintainers to make a note of the version of the guideline the package conforms to.
16:22:30 <geppetto> Tell people to put a date somewhere, if they want to say what version they read/complied with ... and close with -9 votes?
16:22:36 <tibbs> But even then, there's no guarantee.
16:22:48 <geppetto> Make the changelogs for policy more prominent?
16:23:07 <limburgher> geppetto: Yes. :)
16:23:14 <tibbs> Really I think the situation is so bad now that we need to do other things, and then come back to something like this after the rapture when all of our packages look nice.
16:23:23 <geppetto> haha
16:23:24 <Pharaoh_Atem> I'll say though, there's nothing quite like having youri (Mageia) or OBS (SUSE) fail out your packages because of rpmlint :P
16:23:38 * geppetto creates an event in his calendar for sometime never
16:24:24 <tibbs> I do think there are things we can take away from this ticket, but I don't see anything we can actually act upon.
16:24:59 <tibbs> As such, I'd suggest we do say that we don't want to be debian but we do want to do other things to make the situation better.  And then close it.
16:25:13 <mbooth> geppetto: Sometime in Q5?
16:25:14 <geppetto> I'm fine with that
16:25:20 <geppetto> mbooth: +1
16:25:30 <geppetto> tibbs: You want to write a comment and close the ticket?
16:25:35 <tibbs> Sure.
16:25:42 <tibbs> And I actually have a fifth quarter.
16:25:54 <tibbs> It's actually a 13th month, but even then it rarely closes out in a month.
16:26:02 <tibbs> Government accounting.
16:26:11 <mbooth> Crazy
16:26:17 <orionp> I like the collected changelog for the guidelines idea, but otherwise yeah I don't see the point in versioning.
16:26:17 <mbooth> Q6, then
16:26:24 <Pharaoh_Atem> Q10
16:26:41 <geppetto> #action tibbs Write comment about using 13th months of year to fix policy, and make everything better.
16:26:54 <orionp> Even when updating packages to "current guidelines" one is never sure one has updated *everything*
16:27:10 <geppetto> ᕕ( ᐛ )ᕗ
16:27:12 <orionp> unless there is a validation tool
16:27:47 <Pharaoh_Atem> which is what rpmlint is *supposed* to do
16:28:24 <geppetto> Yeh, if rpmlint/quto-qa stuff followed policy a lot better life would be better for everyone :(
16:28:49 <Pharaoh_Atem> I thought autoqa is dead?
16:28:57 * limburgher dreams of a future where the guidelines are machine-readable and directly interpreted by rpmlint
16:29:02 <geppetto> But as tibbs said, most of that requires a lot of work ... and nobody has found time
16:29:17 <Pharaoh_Atem> limburgher: you just evoked debianness
16:29:19 <geppetto> Pharaoh_Atem: Yeh, but I can whistfully remember the unicorns I wanted years ago
16:29:27 <Pharaoh_Atem> heh
16:29:28 <limburgher> They were so pretty. . .
16:29:46 <limburgher> Manes all a-sparkle. . .
16:30:09 <geppetto> #topic #645  Clarify policy on obsoleting non-directly-replaced packages
16:30:12 <Pharaoh_Atem> geppetto: fwiw, we could probably jumpstart some of the rpmlinty stuff by "borrowing" from our friends that use rpmlint more rigorously than us
16:30:13 <geppetto> .fpc 645
16:30:15 <zodbot> geppetto: #645 (Clarify policy on obsoleting non-directly-replaced packages) – fpc - https://fedorahosted.org/fpc/ticket/645
16:30:36 <geppetto> Pharaoh_Atem: Did you just volunteer ?;)
16:30:47 <Pharaoh_Atem> I'm willing to help out, sure
16:31:19 <geppetto> So 645 ... FESCo threw the hot potato back at us :)
16:31:31 <tibbs> I did make a package.
16:31:44 <tibbs> Which actually got some pushback from one FESCo member.
16:31:59 <geppetto> fedora-obsolete-packages?
16:32:15 <tibbs> Yes, I forgot to post the link to the review ticket in our trac ticket.
16:32:18 <tibbs> ticket ticket ticket.
16:32:34 <tibbs> https://bugzilla.redhat.com/show_bug.cgi?id=1376149
16:32:44 <Pharaoh_Atem> ugh
16:33:13 <Pharaoh_Atem> I remember being present for that discussion
16:33:13 <tibbs> I could have just added it but I figured nobody would yell if I acked it.
16:33:17 <tibbs> Anyway, basically I make no suggestions as to how this thing is used, or how it actually gets into the system.
16:33:27 <tibbs> I would suggest that those decisions have nothing at all to do with us.
16:33:43 * Pharaoh_Atem shrugs
16:33:51 <geppetto> I mean ... you created it ... so you own it now. Those are the rules, right?
16:34:10 <Pharaoh_Atem> this global fedora-obsolete-packages should probably be required by fedora-release
16:34:15 <tibbs> Yep, my address is the last one in the changelog.
16:34:31 <geppetto> I'm mostly happy for anyone who owned a package to add a versioned obsolete to it; bump and rebuild
16:34:31 <tibbs> Pharaoh_Atem: I would suggest not, and at least one FESCo member would be rather upset by that.
16:35:03 <geppetto> Pharaoh_Atem: Not that, as then you have to install it ... better to just have it in the @core group
16:35:04 <tibbs> The package gives... someone... a convenient way to track what packages need to go away in order for updates to work.
16:35:05 <sgallagh> Pharaoh_Atem: Recommends: maybe. But there *will* be people who will want to be able to opt out
16:35:05 <limburgher> So how does this get out into the world and function?
16:35:16 <geppetto> or @base or whatever
16:35:16 <tibbs> limburgher: I'm not even suggesting that it does.
16:35:23 <tibbs> Or that we have anything at all to do with that.
16:35:24 <Pharaoh_Atem> sgallagh: then supplements from fedora-obsolete-packages
16:35:37 <geppetto> limburgher: Well the obsoletes will bring it in anyway
16:35:39 <Pharaoh_Atem> Supplements: fedora-release
16:35:40 <orionp> no need to require it right? Only obsoletes will pull it in?
16:35:48 <tibbs> My suggestion was that if anything grows any dependency, it should be the dnf system-upgrade plugin.
16:36:09 <tibbs> Because that's the supported way to upgrade, and that's the thing which would actually trip over the dependency failures.
16:36:16 <geppetto> tibbs: That doesn't work because that runs on the old system
16:36:21 <limburgher> tibbs: Interesting, then it could be tracked and pruned in one place.
16:36:25 <geppetto> And you need this in the transaction
16:36:28 <tibbs> geppetto: I don't see why not.
16:36:46 <tibbs> You install the system-update plugin, your system gets cleaned up.
16:36:57 <geppetto> I guess
16:37:05 <tibbs> But I think a better suggestion is not to have dependencies on this thing at all.
16:37:27 <geppetto> Yeh, I think people will be a lot happier if they can just exclude it if they don't like it for some reason
16:37:29 <tibbs> Let comps pull it in, or let dnf system-upgrade install it if it feels that it needs to do so.
16:37:36 <tibbs> Or just uninstall it.
16:37:39 * geppetto nods
16:37:52 <tibbs> But I think for our purposes, that's pretty much irrelevant.
16:37:59 <geppetto> They'd need to also exclude it or it'll do it's thing anyway though :)
16:38:08 <tibbs> We add a small guidelines section:
16:38:38 <tibbs> If there is no obvious package which should obsolete the one you're retiring, then do one of these things:
16:38:52 <tibbs> Nothing, if the package won't cause dependency issues on upgrade.
16:39:17 <tibbs> Add a versioned obsolete to a related package, even if it's not providing equivalent functionality.
16:39:22 <tibbs> (yes, that's badly worded)
16:39:40 <tibbs> Petition FPC to add an obsolete to fedora-obsolete-packages.
16:39:45 <tibbs> That's it.
16:39:52 <Pharaoh_Atem> it would be important to contain obsoletes for all packages generated by srpm, wouldn't it?
16:40:07 <tibbs> Depends on the situation.
16:40:29 <mbooth> Pharaoh_Atem: Not necessarily
16:40:31 <tibbs> Depending on what you're asking, you just need a base dependency to obsolete it.
16:40:33 <geppetto> tibbs: I think we should say that do nothing should be contingent on not having = deps, or something like that?
16:40:36 <limburgher> Pharoah_Atem: Maybe subpackages into the base package, and base into f-o-p?  For simplicity?
16:40:51 <geppetto> tibbs: Also do we really need them to create an fpc ticket?
16:41:07 <geppetto> Just a BZ against the package seems fine
16:41:26 <tibbs> geppetto: To be fair, I don't actually know if there are any cases which wouldn't actually cause dependency issues eventually.
16:41:27 <Pharaoh_Atem> limburgher: sounds right
16:41:42 <geppetto> I'm happy to be a co-maintainer, if you want
16:41:47 <tibbs> But... we've gotten along this far without any mechanism at all, so something must not be that bad.
16:41:54 * geppetto nods
16:42:05 <Pharaoh_Atem> tibbs: I think we just haven't had as much plumbing churn :/
16:42:20 <Pharaoh_Atem> things are getting gutted and replaced more frequently now than in the past
16:42:30 <Pharaoh_Atem> and we've never supported officially live upgrades until f22
16:42:31 <geppetto> We've had enough ... but people just swap info on how to fix it up by hand
16:42:36 <tibbs> As someone who has been here from the beginning, I don't believe that to be true.
16:42:38 <limburgher> *cough*jasper*cough*
16:42:44 <Pharaoh_Atem> :S
16:43:03 <limburgher> tibbs: I agree, it's always been with us.
16:43:03 <tibbs> But in any case, can we agree that we can at least add the package?
16:43:12 <limburgher> I think so.
16:43:20 <geppetto> yeh
16:43:23 <tibbs> And I'll make a simple draft to tell people what to do in this case.
16:43:24 <limburgher> I can do the review if no one else wants to.
16:43:24 <mbooth> Sure
16:43:37 <geppetto> I'm mostly happy to +1 your policy chage too
16:43:40 <tibbs> And then we can say "ok, here's this package".
16:43:46 <limburgher> MmmHmm.
16:43:50 <Pharaoh_Atem> and if it never gets used, oh well
16:43:56 <Pharaoh_Atem> but at least the mechanism is there
16:43:59 <tibbs> "People who work on the update stack, see how you want to use it."
16:44:09 <tibbs> And let them handle the other arguments.
16:44:16 <limburgher> And if it withers from disuse. . .fine.
16:44:27 <tibbs> And I think that filing a tidket against fedora-obsolete-packages is probably sufficient.
16:44:31 <Pharaoh_Atem> that would be ideal because then nothing has going horribly FUBAR that we need it
16:44:34 <limburgher> It's like a dusty fire extingiusher.
16:44:53 <tibbs> I just didn't know if we wanted to be super safe by being the gateway, since we're effectively pulling things off of people's computers.
16:45:03 <limburgher> Which is like a fire extinguisher.
16:45:17 <Pharaoh_Atem> it's better than scaring people with requiring --allowerasing
16:45:20 <tibbs> But then again, the glibc or kernel maintainers have the power to do that now (add any obsolete they want) and nobody seems worried.
16:45:33 <limburgher> and python, and rpm, and bash, and coreutils, . . .
16:45:44 <Pharaoh_Atem> and every proven packager out there
16:45:44 <tibbs> So.... do we even need a vote here?
16:45:51 <limburgher> Oh why not.  It's fun!
16:45:53 <limburgher> +1
16:45:53 <tibbs> Maybe a vote on the draft after I've written it?
16:46:05 <tibbs> I'll vote +1 before I've written it.
16:46:23 * Pharaoh_Atem snorts
16:46:25 <tibbs> (Though I've definitely written drafts that I wouldn't +1.)
16:46:35 <limburgher> wibbly-wobbly votey-wotey. . .stuff.
16:46:40 <tomspur> +1
16:46:47 <Pharaoh_Atem> limburgher: really?!
16:47:10 <limburgher> Pharaoh_a
16:47:32 <limburgher> Eleventh_Doctor: I'm sorry.  I'm, so, so sorry.
16:47:40 <geppetto> +1
16:47:55 <Eleventh_Doctor> come along...
16:48:36 <Pharaoh_Atem> brb
16:48:46 <limburgher> tibbs: Should I wait for the draft before I do the review?
16:48:58 <tibbs> Of the package?  I don't think so.
16:49:00 <geppetto> need one more vote, mbooth; orionp
16:49:08 <mbooth> +1
16:49:13 <orionp> sorry, visitor here...
16:49:20 <tibbs> It's just a package; if we decide not to use it then we just retire it.
16:49:25 <limburgher> Ok, cool.
16:49:36 <tibbs> Too bad we can't have anything obsolete it in that case so it goes away, though.
16:49:39 <geppetto> #action tibbs Write up policy change for obsolting package fedora-obsolete-packages (+1:5, 0:0, -1:0)
16:49:52 <geppetto> :)
16:50:03 <limburgher> tibbs: <headdesk>
16:50:14 <limburgher> Maybe if we packaged a small wooden badger. . .
16:50:25 <mbooth> tibbs: We'll just add another package to... wait a minute...
16:50:26 <tibbs> Added to my list.  Should be an easy one.
16:50:38 <Pharaoh_Atem> back
16:51:31 * Pharaoh_Atem bashes his head into the ground from the recursion
16:54:03 <limburgher> Ok, I have a hard stop in 7 minutes.  Anything further on this?
16:54:15 <tibbs> Hopefully not.
16:55:13 <geppetto> #topic #398  Tilde in version
16:55:18 <geppetto> .fpc 398
16:55:22 <zodbot> geppetto: #398 (Tilde in version) – fpc - https://fedorahosted.org/fpc/ticket/398
16:55:43 * Pharaoh_Atem inhales
16:55:53 <tibbs> This has turned into something of a mess.
16:56:15 <tibbs> I haven't had a chance to look at the most recent changes.
16:56:17 <geppetto> there's a lot of talk ... but I think the draft is sane now
16:56:36 <geppetto> There was a worrying bit when they were asking for rpm changes etc.
16:56:51 <tibbs> The use of '+' causes problems, and I think I saw a proposal to change rpm's ordering algorithm to deal with it.
16:56:53 <geppetto> But I think it all just works, only requiring the ~ feature
16:57:06 <Pharaoh_Atem> it took a bit of thinking and realizing I accidentally skipped a part of openSUSE's guidelines when I ported things over
16:57:28 <tibbs> The whole thing is now more complex than what we have.
16:57:33 <geppetto> tibbs: That was befor ethe last change ... to just put "git 2016,.." instead of "2016...git"
16:57:38 <orionp> The rpm request I think is moving forward but with changing the behavior of "^"
16:57:53 <tibbs> Well then we can use that after... EL7 goes EOL?
16:58:02 <geppetto> I'm not sure ... as it's not needed for this draft anymore
16:58:03 <tibbs> So come back in ten years?
16:58:08 <Pharaoh_Atem> it's not needed anymore
16:58:10 <tibbs> But yeah, that's not relevant.
16:58:11 <limburgher> Seems legit.
16:58:35 <Pharaoh_Atem> if the caret thing even does happen, it can probably be backported, but there's no pressure to do so
16:58:38 <tibbs> So, this means changing absolutely everything about how we generate snapshots.
16:58:52 <tibbs> Pharaoh_Atem: Red Hat will almost certainly never do that in any RHEL release.
16:58:56 <tibbs> But anyway.
16:58:59 <Pharaoh_Atem> tibbs: they did already for tilde
16:59:13 <Pharaoh_Atem> it's been discussed already, as well
16:59:24 <Pharaoh_Atem> but it won't happen for a little while
16:59:40 <tibbs> We can never assume anything about what Red Hat will do.  We basically assume that things like that will never, ever happen and go on with life.
16:59:40 <geppetto> tilde has been around for a long time ... and I'm not sure builders got changed
16:59:52 <tibbs> But still, it's not relevant.
16:59:55 <geppetto> Yeh
17:00:02 <limburgher> Ok, I must away.  Thanks all!
17:00:32 <geppetto> The new model seems simpler in design ... ~foo for pre-releases +foo for post releases
17:00:39 <tibbs> So, I like the way versioning looks with this.
17:00:42 <tibbs> I really do.
17:00:44 <geppetto> Upstream stuff in version, distro. stuff in release
17:00:58 <tibbs> But I'm still not sold on the huge amount of change this requires.
17:01:19 <tibbs> We also need to make sure that you can change from the old scheme to the new one and maintain ordering.
17:01:45 <tibbs> And I haven't yet had a chance to read how the "unordered alphatag" thing was handled.
17:01:57 <Pharaoh_Atem> prepend it with a letter
17:02:08 <tibbs> Ah, that was what I suggested originally.
17:02:14 <Pharaoh_Atem> yep
17:02:23 <tibbs> Which I actually... like, even though it's kind of ugly.
17:02:23 <geppetto> tibbs: I'm not as bothered by needing to convert easily ... that should sort itself out
17:02:30 <tibbs> geppetto: Depends.
17:02:33 <orionp> why a letter and not a number?
17:02:38 <Pharaoh_Atem> because letters are lower than numbers
17:02:40 <tibbs> Because numbers sort lower.
17:02:48 <Pharaoh_Atem> numbers sort above letters
17:03:01 <Pharaoh_Atem> and I *really* want to avoid more patchwork in rpm
17:03:05 <tibbs> Right.
17:03:29 <ffesti> 0.1+2000gitfoo > 0.0.1
17:03:38 <tibbs> Hey, it's ffesti.
17:03:39 <ffesti> 0.1+2000gitfoo > 0.1.1
17:03:42 <tibbs> Who dragged you in here?
17:03:44 <Pharaoh_Atem> yay ffesti :D
17:03:57 <Pharaoh_Atem> tibbs: I asked him to be here
17:04:02 <ffesti> Pharaoh_Atem
17:04:33 <orionp> ah, that last one seems problematic...
17:04:33 <Pharaoh_Atem> he does a much better job explaining rpm version rules than I do
17:04:43 <tibbs> ffesti: Yeah, that's why there was mention of putting the "git" first.
17:04:47 <tibbs> Which is yet another change.
17:05:07 <ffesti> yup, it needs to start with a char
17:05:16 <ffesti> and things work out just fine
17:05:22 <Pharaoh_Atem> tibbs: I could have thrown in a period between the "git" and the snapshot date for good measure if you like :P
17:05:23 <ffesti> otehrewise bad things can happen
17:06:00 <ffesti> if upstream adds a more minor version number
17:06:12 <tibbs> But again, I'm of two minds here.
17:06:31 <tibbs> I like the way this all looks.  I like the semantic separation between version and release.
17:06:51 <tibbs> I don't like not knowing whether packagers can easily convert to the new scheme while keeping ordering.
17:06:59 <tibbs> I don't like the amount of churn required.
17:07:08 <orionp> I guess my main reservation is that we're moving the complicated stuff from release up to version - and if you messed up release you could probably fix it in version, but if you mess up in version, you need to bump epoch
17:07:25 <tibbs> Yes, that's certainly one of the issues.
17:07:34 <geppetto> orionp: It's at the end of version ... so you can probably still fix it in version
17:07:41 <tibbs> It's basically how we handle things when someone gets it wrong.
17:07:42 <Pharaoh_Atem> geppetto: yep
17:07:51 <Pharaoh_Atem> that's the reason why it's at the end of the version string
17:08:04 <Pharaoh_Atem> if you must, you can fix it by prepending a separator and bumping it
17:08:09 <geppetto> But the page does still reference changing epoch under some conditions which don't seem like they'd need it.
17:08:10 <tibbs> I know racor is on record as not accepting anything like this.
17:08:32 <Pharaoh_Atem> geppetto: the text on epoch comes from the current draft
17:08:38 <tibbs> Is there anyone else who is not a fan of the underlying concept?
17:08:40 <geppetto> Ha
17:08:40 <Pharaoh_Atem> I felt there's no reason to remove it since it's already approved
17:08:51 <Pharaoh_Atem> err, not draft, current published version
17:09:03 <tibbs> Right, we have Epoch: as the last resort way out.
17:09:12 <tibbs> We always have, and that's fine.
17:09:25 <geppetto> Pharaoh_Atem: I think it gives a different impression now though ... the bit at the end of post-release packages.
17:09:29 <mbooth> tibbs: Me. I forget what the benefits of the change are...
17:09:50 <tibbs> mbooth: Yes, that's a completely valid issue to have.
17:09:55 <Pharaoh_Atem> geppetto: the one complaint I have about this document is that it's poorly organized
17:10:08 <Pharaoh_Atem> but I didn't reorganize it from its original structure on purpose
17:10:12 <tibbs> I can take a pass over it.
17:10:21 <geppetto> Pharaoh_Atem: It gives the impression of "try adding a char, but don't worry you can just bump epoch too" ... where it's more "This is how you do it properly, by adding a char, but if you or upstream really screw up you can use epoch to get out of it"
17:10:23 <Pharaoh_Atem> it's hard for me to compare when they don't line up
17:10:28 <tibbs> Summarize exactly what's changing because a diff won't be useful.
17:10:37 <tomspur> mbooth: +1
17:11:00 <orionp> If we're completely overhauling the versioning scheme, let's overhaul the organization of the guidelines if it helps
17:11:09 <Pharaoh_Atem> geppetto: I'm not sure where to move the epoch statement
17:11:14 <Pharaoh_Atem> I'd like to move it, I just don't know where
17:11:19 * geppetto nods
17:11:25 <tibbs> Yes, but let's do do the organization after we're done with the basic concept.
17:11:33 <tibbs> Cart and horse and all that.
17:11:54 <geppetto> Yeh, although some simplification of the page would probably help it to pass
17:12:09 <geppetto> It does look more complicated now, even though I think it's easier/better.
17:12:17 <tibbs> Sure, but I don't even know if we can pass a straw poll on the basic concept.
17:12:37 <tibbs> Concept first, then details, or else we'll be here all year.
17:12:41 <Pharaoh_Atem> the biggest explosion of this document is that now all the version comparison rules are explained
17:12:53 <Pharaoh_Atem> which I don't think we've ever had documented anywhere
17:13:03 <tibbs> We can make collapsed sections or move things to an appendix.
17:13:17 <geppetto> Yeh, collapsed sections seem perfect for those
17:13:17 <tibbs> That's no problem and keeps the thing from overwhelming packagers.
17:13:28 <Pharaoh_Atem> sounds excellent
17:13:31 <Pharaoh_Atem> sadly, don't know how to do those
17:13:39 <Pharaoh_Atem> I'm new to this Fedora Wiki page stuff
17:14:09 <tibbs> Don't worry about it.
17:14:15 <tibbs> Like I said, I can make a pass over it.
17:14:23 <Pharaoh_Atem> cool
17:14:31 <tibbs> I know barely enough to make that work, but it's enough.
17:14:52 <geppetto> Ok, so do we want to let tibbs and Pharaoh_Atem take another pass over it ... but no big design changes ... and we'll all have a look at it and discuss next week?
17:15:05 <tibbs> That's fine with me.
17:15:11 <Pharaoh_Atem> I'm alright with that
17:15:16 <tibbs> But I think that someone needs to make a list of
17:15:23 <Pharaoh_Atem> I think the document is solid, but needs some organizational love
17:15:31 <tibbs> the actual positive points and reasons we would want to do this.
17:15:37 * geppetto nods
17:15:59 <geppetto> Do we want that in the document somehow?
17:15:59 <tibbs> Because we are really going to have to sell this, not just to get enough votes here, but probably to get through FESCo and avoid a flamewar on devel@
17:16:01 <mbooth> Yeah, I would appreciate a summary of the rationale
17:16:13 <tibbs> I don't think it should be in the document.
17:16:16 <mbooth> Not in the document
17:16:20 <tibbs> But it should be in the ticket.
17:16:21 <Pharaoh_Atem> I really don't want this document to get bigger
17:16:23 <geppetto> Ok, just making sure
17:16:32 <mbooth> In the ticket
17:16:36 <geppetto> I'm fine with that, yeh.
17:16:44 <tibbs> We don't need to justify the reasons for each guideline; most packagers won't care.
17:16:58 <tibbs> And if they do care, they can ask.  The ticket numbers are all in the wiki changelog.
17:17:07 * geppetto nods
17:18:23 <geppetto> Ok, #topic Open Floor
17:18:28 <geppetto> #topic Open Floor
17:18:34 <geppetto> tibbs: You had something?
17:18:34 <tibbs> So....
17:18:42 * Pharaoh_Atem exhales
17:18:50 <tibbs> 1) I want to start doing package cleanup.
17:18:56 <Pharaoh_Atem> O.O
17:19:05 <tibbs> Wherever it can be automated.  Just go through and clean shit up.
17:19:21 <tibbs> I had a false start with the defattr thing, which I will get back to eventually.
17:19:41 <tibbs> After that, there is other stuff.  But really, this should be backed up by guidelines.
17:20:05 <tibbs> And that's the problem: if I want to clean some things up,  they'd actually have to be disallowed by the guidelines.
17:20:15 <tibbs> Not just confusing, cargo-culted and completely pointless.
17:20:39 <tibbs> (i.e. the 4000 packages that use defattr because nobody knows what it does any more)
17:21:23 <tibbs> So, does that mean that I need to make a bunch of small proposals for say, banning %clean (or %defattr where it's useless) before I can actually do cleanup?
17:21:55 <tibbs> I basically want to start with all of my bugbears:
17:22:16 <tibbs> Buildroot is not needed; most people don't understand why we have the weird mktemp call and whatnot.
17:22:24 <tibbs> You con't need to clean buildroot in install.
17:22:37 <tibbs> You know, the things I complained about on 80% of my reviews.
17:22:59 <Pharaoh_Atem> does that mean you're going to mass delete the Group tag, too?
17:23:04 <Pharaoh_Atem> :/
17:23:15 <tibbs> I spent months making sure that even RHEL5 could handle all of those changes.  There should be no reason not to do them now.
17:23:25 <mbooth> tibbs: There is a list "should not"s and "it's not necessary"s here: https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections
17:23:36 <mbooth> You could expand on that for the things you want to put right
17:23:55 <tibbs> Group is still user visible, so that would be something I'd wade into well after I've done with the other things.
17:24:04 <tibbs> mbooth: Yeah, that's a good point.
17:24:16 <geppetto> tibbs: If you flag things in package reviews you can probably just do changes to change them in packages
17:24:17 <tibbs> Just change some "is unnecessary" to "SHOULD NOT be used".
17:24:25 <tibbs> I'll propose that.
17:24:57 <tibbs> Response to my "useless %defattr" thread was wholly positive.
17:25:05 <geppetto> But I'm guessing I'll +1 all your minor changes to policy ... so feel free to update policy too :)
17:25:14 <tibbs> The only dissent I got was that I was not just doing it with no discussion.
17:25:21 <geppetto> ha
17:25:28 <tibbs> Someone actually asked me why I was bothering to tell anyone.
17:26:11 <tibbs> I have been thinking about this in the context of having FPC take a more active role in keeping packages conforming where it's completely obvious.
17:26:36 <tibbs> I mean, why don't we say we'll fix up packages that don't follow some guideline change?
17:26:51 <geppetto> time?
17:26:58 <tibbs> Obviously sometimes that's too damn difficult, or identifying the packages which would need to change isn't easy.
17:27:07 <tibbs> But... if you have a script and a process....
17:27:39 <tibbs> I wrote stuff to find packages that have cruft in them, make lists and include package owners.
17:28:03 <tibbs> I haven't yet gotten the bump and rebuild thing done yet.
17:28:19 <tibbs> I keep waiting for a rawhide branch, and then run out of time when it happens.
17:29:05 <tibbs> Anyway, that's #1.  I'll make my proposal for the changes to that one guideline page.  If FESCo sees this and decides I shouldn't be doing it, then I'm sure I'll hear about it.
17:29:11 <tibbs> So, #2.
17:29:42 <tibbs> Suggest that maintainers check in a file "rpmlint.cf" to the package git tree.
17:30:13 <tibbs> _suggest_ editor configurations which enable automated rpmlint checking.  (in vim, you use syntastic and it's trivial).
17:30:31 <tibbs> Eventually figure out how to get taskotron to pay attention to these.
17:30:58 <tibbs> And of course add default filters to our rpmlint package so people don't have to do this for things which really aren't problematic.  But that's a separate topic.
17:31:01 <Pharaoh_Atem> is rpmlint.cf the same as the per-package rpmlintrc files?
17:31:18 <tibbs> Well, those don't exist in Fedora currently.
17:31:41 <tibbs> I don't care what the file is named; rpmlint.cf is the name of the rpmlint config file.
17:31:59 <Pharaoh_Atem> well, I'd suggest using <specname>.rpmlintrc
17:32:08 <Pharaoh_Atem> but whatever
17:32:10 <Pharaoh_Atem> it's a good idea
17:32:22 <geppetto> seems fine to me ... if the config. is there then fail builds?
17:32:27 <tibbs> That's less easy to do, actually.
17:32:42 <tibbs> geppetto: I don't think we're to the point of failing builds.
17:33:01 <geppetto> Pharaoh_Atem: specname isn't guaranteed in the way you'd think
17:33:16 <Pharaoh_Atem> or source package name
17:33:19 <Pharaoh_Atem> the name of the thing with git
17:33:24 <tibbs> But if rpmlint wasn't so crap, _and_ people had a way to override it when it's not being crap but is still tossing out a false positive, then...
17:33:24 <Pharaoh_Atem> err dist-git
17:33:37 <tibbs> Pharaoh_Atem: The thing is, you want to be able to tell rpmlint what file to look at.
17:33:46 <tibbs> "rpmlint.cf in current directory" makes sense.
17:34:14 <tibbs> "Some file name which depends on things in current directory" is less easy.
17:34:32 <tibbs> Note that rpmlint doesn't look at any of this by default; you have to pass it an option.
17:34:56 <Pharaoh_Atem> well, for example, if a repo is named "texlive", and you know this name, you could look for "texlive.rpmlintrc"
17:35:18 <tibbs> We could try to get rpmlint changed, of course.  But if you're checking a binary package (that I just built from git), how do you get back the name of the spec file used?
17:35:23 <Pharaoh_Atem> ugh, I'm doing a terrible job explaining this
17:35:50 <tibbs> If you have a repo, really, we shouldn't care about keeping the filenames unique.
17:36:04 <tibbs> Honestly I wish we could just call the specfile "spec" and be done with it.
17:36:05 <geppetto> I'm happy with rpmlint.cf
17:36:52 <tibbs> Some people even prefix their patches with the package name.
17:37:20 <tibbs> Which.... might have sort of made sense for some configurations a very long time ago.  But is just excessively verbose now.
17:37:36 <tibbs> In any case, this was just an idea I was tossing out to see if anyone would laugh.
17:37:51 <geppetto> no laughing ... seems fine to me
17:37:53 <Pharaoh_Atem> I mean, I define my rpmlintrc files with <srcname>.rpmlintrc because enough systems I work with expect that
17:38:04 <tibbs> I have never seen rpmlintrc at all.
17:38:19 <geppetto> And prefixing of patches was needed when all patches ended up dumped in the rpmbuild SOURCES dir.
17:38:19 <Pharaoh_Atem> Mandriva's ABF and SUSE's OBS use it
17:38:51 <Pharaoh_Atem> and a couple of other systems I've worked with do as well
17:38:58 * geppetto remembers hating non-prefixed patches ... when working with .src.rpm files
17:38:58 <tibbs> The only existence of rpmlintrc is ~/.rpmlintrc.
17:39:19 <Pharaoh_Atem> geppetto: sadly, I still do that enough too :(
17:39:27 <tibbs> Anyway, within a repo I see no need to perpetuate the repeating of the package name when you already know it because it's in the repo.
17:39:39 * Pharaoh_Atem shrugs
17:39:53 * geppetto nods ... I'm 100% fine with it for rpmlint files
17:40:22 <Pharaoh_Atem> tibbs: example: https://abf.io/ngompa/libcomps
17:40:39 <tibbs> So that's all I had.
17:40:54 <geppetto> Ok, so one quick thing I had:
17:40:57 <geppetto> https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
17:41:15 <geppetto> It's not being proposed today ... and probalby anytime soon
17:41:17 <tomspur> There is also <srcname>-rpmlintrc: https://github.com/openSUSE/kiwi/tree/master/rpm
17:41:48 <tibbs> We really don't have to slavishly follow what mageia and opensuse do.
17:41:57 <tibbs> Especially when there's no good reason for that behavior.
17:42:16 <geppetto> But it's worth looking at, as it will eventually ... the idea is groups of packages, and hopefully the main points are mostly solid now.
17:42:18 <Pharaoh_Atem> well, at least in OBS's case, the reason for it is because you can build multiple spec files from a single "package" space
17:42:21 <tibbs> What is a module in this context?
17:42:39 <geppetto> tibbs: Basically a group of rpm packages
17:42:48 <tibbs> So... a comps group?
17:42:49 <geppetto> That can exist as a single unit
17:42:58 <Pharaoh_Atem> what's the point of modules?
17:43:03 <Pharaoh_Atem> it seems like you're just reinventing comps
17:43:14 <geppetto> Similar to one ... but with deps. and ABI etc.
17:43:18 <Pharaoh_Atem> why not just make a new way to more easily create/edit comps
17:43:27 <Pharaoh_Atem> and extend the comps format to add the missing bits
17:43:47 <Pharaoh_Atem> modulemd's biggest problem is that now we need to have TWO different parsers for it
17:43:58 <geppetto> two?
17:44:02 <Pharaoh_Atem> modulemd is in YAML
17:44:09 <Pharaoh_Atem> whereas ALL the other rpmmd data is in XML
17:44:16 <Pharaoh_Atem> so now tools like DNF need two parsers
17:44:26 <tibbs> Well, anything that's not XML is good.
17:44:35 <geppetto> :)
17:44:39 <Pharaoh_Atem> not to mention, since libsolv has no idea about modulemd, dnf must now implement its own solver logic
17:44:43 <Pharaoh_Atem> which is what we're trying to get away from
17:44:45 <tibbs> Sadly XML is already baked in from decades ago.
17:45:08 <tibbs> I don't think we should remotely try to get into why modules are useful.
17:45:12 <Pharaoh_Atem> if someone wants to propose a yaml based rpmmd, I'll certainly look at it
17:45:22 <tibbs> Or argue with them about their config language.
17:45:40 <tibbs> That should be a discussion which happens elsewhere.
17:45:40 <Pharaoh_Atem> anyway, my biggest issue is I see no point to the modules' existence
17:45:47 <Pharaoh_Atem> they duplicate what we do in comps
17:45:57 <Pharaoh_Atem> and the facilities are already in place to handle comps from multiple repos
17:46:01 <tibbs> Which, again, is... a discussion for you to have with someone else.
17:46:20 <tibbs> But I've been hearing about this for years.
17:46:33 <geppetto> You can't version a comps. group, or have N providers of it and choose between them
17:46:42 <tibbs> I've never had any understanding of why I should even care.
17:46:42 <geppetto> etc. etc.
17:47:00 <Pharaoh_Atem> geppetto: you *could*, you just don't want to
17:47:00 <tibbs> But if someone wants to propose packaging guidelines, I'll deal with them just like I do with any other language.
17:47:25 <geppetto> There are documents about why you should care, and what it helps with ... this isn't it though ... it's just the policy side of "how do I create one"
17:47:42 * geppetto nods
17:47:47 <Pharaoh_Atem> insofar as how to create one, it looks fine
17:47:51 <Pharaoh_Atem> the guidelines are pretty sane
17:48:12 * mbooth leaves, it's getting late in the day
17:48:16 <Pharaoh_Atem> though please tell me that we don't have to write timestamps that verbose
17:48:23 <geppetto> As I said, it's not up for proposal next week or anything, but if you could have a look at it and mention if anything seems more insane than you were expecting ... that'd be cool :)
17:48:50 <geppetto> Pharaoh_Atem: No, creating tools to do the version/release timestamp+hashes
17:48:56 <Pharaoh_Atem> good
17:48:58 <tibbs> Not knowing anything about the subject matter gives me a useful perspective, so I'll have a look.
17:49:02 <Pharaoh_Atem> my fingers ache at the idea
17:49:06 <geppetto> :)
17:49:17 <Pharaoh_Atem> I do like the references section
17:49:25 <Pharaoh_Atem> quite useful to have pointers to documentation relevant to the module
17:49:26 <tibbs> Fortunately we still have middle button paste if we need it.
17:50:04 <Pharaoh_Atem> geppetto: can a module pull in multiple content types, say for example rpms, flatpaks, snaps, and docker images?
17:50:30 <geppetto> Pharaoh_Atem: that's a plan some people have ... there's no prototype for that though, yet
17:50:56 <Pharaoh_Atem> geppetto: why use the word "rationale" down in packages in components section?
17:51:45 <geppetto> Pharaoh_Atem: The idea there is you should describe _why_ the package is being included in the module
17:52:14 <geppetto> Pharaoh_Atem: One problem people have with comps. and deps. is that there's no way to see why a package was added N months later, and know if it's still needed
17:52:22 <Pharaoh_Atem> that's not really clear in the document, then
17:52:30 <Pharaoh_Atem> (in re the why)
17:52:39 <geppetto> Ok, cool ... makes note
17:53:44 <geppetto> Ok ... that's it from me. Anyone else have anything to discuss in the last 7 minutes?
17:54:35 <Pharaoh_Atem> nope, all gravy
17:55:13 <geppetto> ok :)
17:55:17 <geppetto> #endmeeting