16:00:03 <geppetto> #startmeeting fpc
16:00:03 <zodbot> Meeting started Thu Sep 22 16:00:03 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:03 <zodbot> The meeting name has been set to 'fpc'
16:00:03 <geppetto> #meetingname fpc
16:00:03 <geppetto> #topic Roll Call
16:00:03 <zodbot> The meeting name has been set to 'fpc'
16:00:21 <geppetto> #chair orionp
16:00:21 <zodbot> Current chairs: geppetto orionp
16:00:25 <geppetto> #chair tibbs
16:00:25 <zodbot> Current chairs: geppetto orionp tibbs
16:00:31 <orionp> hello
16:00:47 <tibbs> (I secretly wish for no quorum today)
16:01:19 <mbooth> Hi
16:01:36 <mbooth> tibbs: Oh, I can knock off early if you want ;-)
16:01:40 <geppetto> #chair mbooth
16:01:40 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:03:02 <Rathann> hi
16:03:08 <tibbs> BTW, I think we forgot to talk about the one draft I did do, about the application/library thing.
16:03:09 <geppetto> #chair Rathann
16:03:09 <zodbot> Current chairs: Rathann geppetto mbooth orionp tibbs
16:03:41 <geppetto> tibbs: Ok, we can talk about that first if you want ... no new tickets this week, unless you count the obsoletes thing
16:03:52 <tibbs> Which, last night in a fit of insomnia, I realized is missing the concept of "frameworks", which don't seem to be consistently named in our packaging.
16:04:09 <tibbs> But it's at least something that I managed to actually do.
16:04:45 <tibbs> I will also point out that I got completely distracted trying to make our introductory packaging document not be terrible.
16:04:48 * geppetto nods
16:04:58 <tibbs> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
16:05:17 <tibbs> I started trying to fix "non guideline compliant" things and then realized just how terrible that thing was.
16:05:48 <tibbs> Before I started, it was this: https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package&oldid=457481
16:06:23 <tibbs> Why on earth did we tell people about %_specdir and %_buildrootdir and things that basically nobody doing Fedora packaging even knows about?
16:06:48 <orionp> ah, those where the days...
16:06:56 <geppetto> document from a long time ago?
16:06:59 <tibbs> Anyway, I still have some work to do before the description of how to package GNU Hello is complete, and then I'll have to think about what to do.
16:07:09 <tibbs> geppetto: Well, it's been edited pretty recently.
16:07:14 <tibbs> (besides by me)
16:07:18 <geppetto> #topic Schedule
16:07:21 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/6GBJY2656KIQHWEQHWZ57M7WYNW7E4XY/
16:07:35 <geppetto> #topic #558  Application/Library distinction and package splitting
16:07:39 <tibbs> I just think that nobody who would actually use it would feel themselves up to the task of rewriting it completely.
16:07:42 <geppetto> #topic #558  Application/Library distinction and package splitting
16:07:47 <geppetto> .fpc 558
16:07:48 <zodbot> geppetto: #558 (Application/Library distinction and package splitting) – fpc - https://fedorahosted.org/fpc/ticket/558
16:08:04 <geppetto> tibbs: yeh
16:08:25 <tibbs> So my draft for 558 is at https://fedoraproject.org/wiki/User:Tibbs/AppVsLib
16:08:53 <geppetto> #link https://fedoraproject.org/wiki/User:Tibbs/AppVsLib
16:09:11 <tibbs> The second section needs to be redone.  I had actually typed something in for it but somehow never actually saved it.  Or something like that.
16:09:23 <geppetto> :(
16:09:32 <tibbs> I find that I remember making changes and then don't see them later.
16:09:58 <tibbs> But it could be like when you dream that you got up and went to work, except that you're still asleep.
16:11:05 <tibbs> But now I don't know whether I should include "frameworks" in there somehow.
16:11:26 <tibbs> I think we'd prefer that they be named like modules.
16:11:43 <geppetto> like modules?
16:11:56 <tibbs> At least flask and django and a couple of Perl and PHP ones that I can recall are named as if they were libraries/modules/whatever the specific language calls it.
16:12:06 <geppetto> Ahh
16:12:19 <geppetto> Yeh, I just think of them as giant libraries
16:12:30 * limburgher here, late
16:12:51 <tibbs> I do to, but I don't know all of them.  rails is packaged as a library.  I thought passenger was some sort of framework but it's packaged as an application.
16:13:25 <geppetto> #chair limburgher
16:13:25 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp tibbs
16:13:34 <tibbs> But I'm probably wrong about what passenger is.
16:13:42 * geppetto has never heard of it
16:14:03 <orionp> passenger is in interface between apache and rails apps
16:14:12 <orionp> an
16:14:34 <Rathann> tibbs: the first point under Library or Application? mentions a library but then talks about linking to application-specific naming
16:15:07 <Rathann> also, what's the difference between first and fourth point there?
16:15:08 <tibbs> Yeah, I meant "domain-specific".
16:15:55 <tibbs> And I've probably confused myself at some point.
16:16:22 <tibbs> The first point is supposed to link to the section in the Naming document which tells you how to name python, perl, whatever packages.
16:16:34 <geppetto> In the mixed use section I think we probably want to be tighter ... saying something like "you can ship some small example applications with a library, but as soon as you have extra deps. or a man page or something then you MUST create a sub-package"
16:17:04 <tibbs> The first and fourth differ in that one includes only stuff, the other is about "primary purpose".
16:17:16 <tibbs> Which... is terrible, really.
16:17:29 <tibbs> Like I said, I really struggled to come up with something useful here.
16:17:38 <tibbs> I urge people to edit freely.
16:17:50 <tibbs> s/urge/beg/ ?
16:17:55 <geppetto> ha :)
16:17:58 <tibbs> implore, maybe?
16:19:09 <tibbs> But at least there's a thing now.
16:19:30 <tibbs> And soon we can get that out o the way and move on to why I think that ticket was actually filed.
16:19:55 <geppetto> which is?
16:20:29 <tibbs> It's relating to confusion in the python guidelines, and eventually the terrible nature of the spec example there.
16:20:56 <geppetto> ahh
16:21:45 <tibbs> I think at some point I failed to understand that point, and got stuck on the issue that the draft poorly attempts to address.
16:21:53 <geppetto> it is more likely that python has the problem that the "binary" is a tiny 2 line script which calls some "library/module function"
16:22:46 <tibbs> Right.
16:23:20 <tibbs> Splitting that just isn't worth it, but then the issue of how you package it is still there.
16:23:41 <tibbs> And that sort of depends on "primary purpose", which is in the end up to the packager.
16:23:54 <geppetto> Eh there's still some argument for splitting them, esp. when you get man pages and bash completion etc.
16:24:04 <tibbs> And doing a provide for the module is always an out.
16:24:23 <tibbs> But yes, when you start to do anything which involves additional dependencies, then you reall should split.
16:24:27 <geppetto> I know the last package I got into Fedora has an application with a <10 line binary and a man page
16:24:31 <tibbs> Which I think I tried to address.
16:24:46 * geppetto nods
16:25:07 <tibbs> Note that this isn't a problem with Perl at all.
16:25:17 <tibbs> Because the provides are automatic there.
16:25:25 * geppetto nods
16:25:56 <geppetto> I'm kind of shocked, given how much python we have, that nobody has written the automatic deps. stuff
16:25:59 <tibbs> I do recall that some distros absolutely require that .so.* files be split into *-libs packages.
16:26:08 * geppetto nods
16:26:11 <Rathann> geppetto: that's in progress, isn't it?
16:26:15 <tibbs> I had assumed that autodeps for python was somehow hard.
16:26:22 <Rathann> I mean first there are automatic provides
16:26:30 <tibbs> Rathann: I don't think that full perl-style autodeps is in the works.
16:26:34 <Rathann> huh
16:26:37 <Rathann> too bad
16:26:48 <tibbs> I would love to be proven wrong.
16:27:01 * geppetto nods
16:27:03 <Rathann> I mean, if python can resolve deps then why can't rpm
16:27:19 <geppetto> I'd heard people talk about it over the last N years ... but AFAIK nobody is working on it atm
16:27:38 <tibbs> I usually assume that if it were easy, someone would have done it.
16:27:57 <Rathann> right
16:28:01 <tibbs> Maybe those who would know how to make the dependency trees don't know how to tell RPM to actually generate them.
16:28:07 <tibbs> But I can help with that.
16:29:01 * geppetto nods ... it's very possible the python side just aren't speaking to rpm people
16:29:16 <tibbs> It's just a script you drop in.
16:29:27 <geppetto> Maybe waiting for the glorious future where we all use virtualenv and pypi
16:29:31 <tibbs> And they're already doing that for the one bit of autodeps that are happening, so... I don't know.
16:30:01 <tibbs> I wish python had handled the multiple module situation better than virtualenv.
16:30:22 <orionp> There are lots of corner cases with requires - packages that can try to import several different flavors of a package for example
16:30:26 <tibbs> And instead allow multiple versions of a module to exist in the system location at the same time.
16:30:37 <tibbs> And the packages import by version or version range.
16:30:47 <geppetto> so like perl?
16:30:55 <tibbs> I don't think Perl does that, either.
16:31:16 <tibbs> At least it didn't when I did a lot of Perl.
16:31:27 <geppetto> Ahh, I thought it did ... I know you could say something like "use X 1.2.3"
16:31:29 <orionp> or developers that understand maintaining a stable API
16:31:49 <geppetto> orionp: Now you just wishing for unicorns
16:31:59 <tibbs> But anyway, that all comes back to my big dream where multiple versions of any non-conflicting package can all be installed at once.
16:32:01 <orionp> pink ones even
16:32:28 <Rathann> tibbs: that's actually possible
16:32:40 <tibbs> Sure, rpm allows it.
16:32:45 <Rathann> exactly
16:32:46 <tibbs> dnf just needs a flag somewhere.
16:33:02 <geppetto> There are already a couple of "generic" use flags
16:33:13 <tibbs> But basically the entire rest of the distro needs to accommodate.
16:33:38 <geppetto> I'm kind of working on something for shared libraries that would introduce another too, and have multiple libs. installed in certain conditions
16:33:41 <tibbs> Well, how we compose things and such.  And how a maintainer decides which versions actually get shipped, because we don't want absolutely _everything_ to be included.
16:34:14 <tibbs> It's something I think we should try.  But everyone these days just wants flatpacks and docker and....
16:34:20 <Rathann> tibbs: going back to your draft, I would merge the four cases into just two
16:34:44 <tibbs> Rathann: Please, just edit.
16:34:47 * Rathann goes ahead and starts editing
16:35:09 <tibbs> You're right, if you assume "primary purpose" everywhere then there's no point in saying "includes only library files".
16:38:35 <Rathann> and I'd put the split into libraries and utilities as the first option
16:38:43 <Rathann> for Mixed use packages
16:42:43 <Rathann> tibbs, everyone: https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FAppVsLib&diff=474752&oldid=471242
16:42:52 <Rathann> I'll be back in 5
16:42:56 <Rathann> mins
16:43:14 <tibbs> Much cleaner.  I think we can still redo the final section.
16:43:32 <tibbs> Instead of giving options, just say "If this, do this.  If that, do that."
16:43:47 <tibbs> But maybe it's not that simple.
16:48:59 <geppetto> The change looks fine to me
16:49:26 <geppetto> Half of me wants ot distinguish between utility applications shipped with a library, and examples
16:49:42 <geppetto> But I'm pretty sure that just makes everything more complex for not enough gain
16:50:06 <tibbs> I think if someone had a question about that, you could resolve it by pointing to "primary purpose" again.
16:50:16 * geppetto nods
16:50:17 <tibbs> Plus, examples are usually documentation.
16:50:26 <tibbs> But that depends on upstream.
16:50:36 <geppetto> for the code, yeh ... but sometimes people compoile and ship tem too
16:50:55 <geppetto> primary purpose is probably enough
16:51:03 <tibbs> And also, the dependency thing.
16:51:26 <tibbs> But if we do want to keep multiversioning in mind, then such things would conceivably be "conflicting".
16:58:47 <geppetto> Ok, I think we are done for this ... at least for this week?
16:59:09 <tibbs> Unless we want to approve something.
16:59:19 <Rathann> wait, are we going to vote on the revised tibbs' draft?
16:59:53 <geppetto> We can
17:00:03 <geppetto> I guess I'm happy to +1 it
17:01:00 <geppetto> mbooth: orionp: limburgher: You want to vote on it this week?
17:01:21 <tibbs> I'm writing in my suggestion to clean up the last section.
17:01:36 <tibbs> Also, there's a question of what you name the srpm when you split a package.
17:01:48 <tibbs> Which I'm happy to hang off of "primary purpose" again.
17:02:09 <limburgher> geppetto: SUre.
17:02:30 <limburgher> +1
17:02:32 <orionp> I'm +1 on the current draft
17:03:17 <mbooth> Sure, on which page will this guideline live?
17:03:21 <tibbs> Hmm, never mind; that suggestion doesn't actually clean things up.
17:05:09 <tibbs> Also, in the last paragraph, there's the word "significant".
17:05:23 <tibbs> I'm thinking that it's simpler to just say "any", but I'm not sure.
17:05:39 <geppetto> yeh, use any
17:05:56 <tibbs> Splitting is really not difficult, and it avoids arguments about whether things are "significant".
17:06:02 * geppetto nods
17:06:14 <tibbs> And in the end we do want to keep dependency trees as trim as possible.
17:06:15 <geppetto> I think we should lean heavily towards splitting
17:06:22 <Rathann> me too, actually
17:06:26 <geppetto> Esp. given we have soft deps. now
17:06:42 <orionp> yeah +1 to encourage splitting
17:07:05 <tibbs> Yeah, soft deps do change things a bit.
17:08:14 <tibbs> I made the "any" change plus a slight rewording.
17:08:49 <tibbs> Does anyone think we need to mention how to to name the source package/package repository?
17:09:00 <geppetto> Ok, I'm at +4 for the draft now ... with Rathann and limburgher not having voted
17:09:14 <Rathann> +1
17:09:14 <geppetto> And mbooth
17:09:17 <tibbs> +1 for the record.
17:09:21 <limburgher> I thought I was +1.
17:09:31 <mbooth> Sure, +1
17:09:33 <tibbs> I guess you were counting me already.
17:09:34 <geppetto> limburgher: You were ... my bad
17:09:45 <geppetto> tibbs: yeh, I assumed you were +1 :)
17:10:03 <geppetto> #action Application/Library distinction and package splitting, from tibbs (+1:6, 0:0, -1:0)
17:10:14 <geppetto> Ok, done
17:11:07 <geppetto> Do we want to just do open floor?
17:11:18 <tibbs> Thanks, I'll write that up and then think about how to address whatever is left in that ticket.
17:11:19 <geppetto> Or talk about the tilda version/release thing?
17:11:42 <tibbs> Can we touch on the "master obsoletes package" thing?
17:12:03 <limburgher> tibbs: That.
17:12:29 <geppetto> Sure
17:12:44 <geppetto> #topic Open Floor
17:12:48 <tibbs> Basically, the package exists now.
17:12:52 <geppetto> ok, cool
17:12:55 <tibbs> Some people don't like the idea.
17:13:00 <tibbs> I don't even like the idea.
17:13:13 <geppetto> Why?
17:13:26 <tibbs> But... I see this as something you _can_ install, if you want it, to remove cruft from your install.
17:13:50 <geppetto> obsoletes don't really work like that though
17:13:54 <tibbs> nirik and (as you've seen) kkoffler dislike the idea of forcibly removing anything from people's systems.
17:13:58 <geppetto> There's no soft obsoletes
17:14:11 <Rathann> that's one side of the issue
17:14:18 <Rathann> the other is broken upgrades
17:14:23 <tibbs> Well, you install the fedora-obsolete-packages package and the other stuff goes away.
17:14:35 <tibbs> At least that's now I understand it to work.
17:14:49 <geppetto> tibbs: No, if you have X installed then the obsoletes package will be pulled in
17:14:50 <limburgher> If done properly, yes.
17:15:05 <tibbs> OK, well, crap.
17:15:06 <geppetto> tibbs: if the obsoletes packages obsoletes X
17:15:32 <geppetto> You can exclude it ... but dnf probably doesn't obey those on system-upgrade anyway
17:15:32 * nirik is fine as long as it's versioned so people can just rebuild to avoid it, or remove the package to avoid it or whatever
17:15:57 <geppetto> Yeh, I'm sure tibbs won't be allowing any unversioned obsoletes in there
17:16:27 <tibbs> Yes, unversioned would be horrible.
17:16:43 <tibbs> An obsoleted package may re-enter the distribution at any time.
17:16:50 * geppetto nods
17:17:14 <tibbs> I'd really hoped to get guidance from FESCo about this.
17:17:42 <tibbs> But in lieu of that, the obsoleter package exists.  I just have no idea when to actually add something to it.
17:18:29 <nirik> well, fesco thinks it needs to be case by case.
17:18:37 <geppetto> just put it in policy and have people ask you to add their package?
17:18:39 <tibbs> And also, what happens when you have fedora-obsolete-packages installed as well as "foobar" version 2.
17:19:01 <tibbs> And then fedora-obsolete-packages gets updated with an obsolete on foobar <= 2?
17:19:15 <tibbs> Does foobar go away when you update?
17:19:18 <Rathann> yes
17:19:28 <tibbs> I honestly have never played with this.
17:19:32 <Rathann> ok, I need to drop off, a guest arrived
17:19:39 <Rathann> thanks guys
17:19:42 <tibbs> Take care.
17:20:29 <geppetto> tibbs: yes
17:21:03 <tibbs> OK, so basically it is kind of a hammer.  Even if you don't have it installed, dnf will suck it in as long as it does obsolete something you have installed.
17:21:24 <orionp> right
17:21:31 <limburgher> It's a bit like releasing a singularity in a crowded room.
17:21:40 <tibbs> My assumption is that we will never add something to this in an existing release.
17:21:51 <tibbs> Because that would be aweful.
17:21:54 <orionp> right - only modify it in pre-release
17:22:05 <limburgher> So it should never have a bodhi update.
17:22:10 <tibbs> Yes.
17:22:24 <limburgher> Maybe blacklisting it there could prevent catastrophe.
17:22:28 <tibbs> Well, unless we add something after branching but before release.
17:22:44 <geppetto> tibbs: Probably, it's possible you'll want to add a package that got removed the previous release but was missed?
17:23:06 <tibbs> Well, if the package needs to go, it would have dep issues already.
17:23:12 <geppetto> True
17:23:15 <tibbs> So you couldn't have upgraded if indeed it was missed.
17:23:38 <tibbs> My intention is to use this only for things which would actually stop you from running dnf distro-update or whatever it's called.
17:23:44 <tibbs> (fedup was easier to remember).
17:23:48 <geppetto> But adding it would maybe fix those issues if people hadn't upgraded because of it?
17:26:09 <tibbs> True.
17:26:44 <tibbs> Basically, I don't know, and I think that the ultimate decision there would really need to be made on a case by case basis, and perhaps not even by us.
17:27:15 <tibbs> We do need a policy.
17:28:00 <geppetto> I'm happy if you have a policy, to make your life easier
17:28:14 <geppetto> But I'm also mostly happy for you to just decide what to add to the package
17:28:29 <geppetto> Also ... do you want co-maintainers?
17:29:44 <tibbs> Yeah, we just need a sentence in the guidelines: If there's no obvious package which will obsolete the one you wish to remove, and the package will cause dependency issues which prevent users from updating their systems, then file a bugzilla ticket against fedora-obsolete-packages and request that....
17:30:15 <tibbs> I figure any provenpackager would just do what was needed if the need arose, but if anyone in FPC or FESCo requests privs then of course I'll add them.
17:30:52 * geppetto nods
17:31:21 <geppetto> Ok, that's 1.5 hours ... anything else we want to talk about today?
17:31:37 <limburgher> I have nothing.
17:31:45 <tibbs> Nah.  I still need to re-read last week's minutes to figure out what I said I'd do.
17:32:06 <tibbs> I'm also not sure if there was anything on the big versioning overhaul.
17:32:48 <tibbs> I have to say I am really starting to lean towards +1, but someone (i.e. probably me) needs to make a list of every package this impacts.
17:33:03 <geppetto> cleanup the versioning document, and provide a summary for people as to why we want to change
17:33:22 <tibbs> Well, I wasn't going to do the summary.
17:33:29 <geppetto> ok
17:33:33 <tibbs> I'd hope one of the proponents of it would do it.
17:33:37 * geppetto nods
17:33:56 <tibbs> Asking someone who is still on the fence to make the arguments pro is... not a good strategy.
17:34:07 <tibbs> I can certainly make some arguments con, however.
17:34:33 * geppetto nods
17:34:45 <geppetto> I'm probably more pro than con at this pointr
17:35:25 <tibbs> One thing: can we just agree right now to exempt the kernel?
17:35:39 <mbooth> I still don't know what we gain, so I'm still con
17:36:02 <tibbs> mbooth: I'd hoped that one of the proponents would have provided a good answer to that question.
17:36:17 <geppetto> tibbs: isn't the kernel pretty much a perfect version/release user in Fedora?
17:36:20 <tibbs> I'm certainly not going to try to convince you, although the gains do seem apparrent to me.
17:36:25 <tibbs> geppetto: Not entirely.
17:36:38 <tibbs> It never uses releases < 100, for example.
17:37:07 <tibbs> They have distro releases sort of encoded in Release:
17:37:08 <geppetto> ahh
17:37:35 <geppetto> I see they sometimes go up by 100 and sometimes by 1
17:37:44 <tibbs> And, basically, they do enough already and don't deserve someone driving by and telling them they're doing it wrong.
17:38:02 <tibbs> Each active Fedora release gets a different hundreds digit.
17:38:11 <geppetto> ahh
17:38:22 <tibbs> Minor updates within that which keep the same kernel version get bumped by one.
17:38:51 <geppetto> does that change on when the releases go in and out of support?
17:39:19 <tibbs> Yes, they rejigger everything so that the oldest supported release is 100.
17:39:28 * geppetto nods
17:39:42 <tibbs> So right now F24 kernels are 200, F23 is 100.  F25 is 300 I think.
17:39:51 <tibbs> F26/rawhide is versioned differently.
17:40:11 <tibbs> But note that even now, their rawhide/prerelease kernel versioning doesn't follow our current guidelines.
17:40:17 <tibbs> kernel-4.8.0-0.rc0.git5.1.fc26.x86_64.rpm
17:40:26 <tibbs> And you know what?  I really don't care.
17:40:36 <geppetto> :)
17:40:49 <tibbs> But that would be something that would also be different under the proposed scheme.
17:41:10 <tibbs> And I would be completely happy to let them change or not as it suits them.
17:41:52 <tibbs> I will say that their use of "git" is not one of our snapshot tags, but is the actual upstream name.
17:42:14 * geppetto nods
17:42:16 <tibbs> After realizing that, they might actually be following current practice for the rawhide kernels.
17:42:48 <tibbs> But the new proposal would involve changes to the way they do things, were they not given an exception.
17:42:55 <geppetto> I don't think they are not following for release ones ... just an extra release numbering scheme
17:43:15 <tibbs> Basically I just wanted to state it plainly that the kernel gets a pass.
17:43:15 <geppetto> Which is fine, in general, I think
17:43:50 <tibbs> "Exemptions from this scheme can be granted by FPC.  The following packages currently have active exceptions: kernel"
17:44:01 <tibbs> And stick that in versioning somewhere.
17:44:21 <geppetto> I'd rather have it be more general I think ... Like explicitly saying what we want to accomplish, and giving a bunch of rules which accomplish that ... but if packages want to use a non-tilda scheme I'd be fine with it
17:44:57 <tibbs> But then, well, do we still keep the old scheme?
17:45:00 <geppetto> I don't mind having it be tighter and excepting the kernel ... if we know they'd really like one
17:45:32 <tibbs> If it looks like this has even a hope of passing (which currently it doesn't) then I will ask them.
17:45:37 <geppetto> I was thinking ... we could keep the old scheme around ... it solves the migration problem too
17:45:47 * geppetto nods
17:45:49 <tibbs> But, damn, talk about increasing complexity.
17:46:04 <geppetto> I think some of tht is just more words
17:46:16 <tibbs> I'd really rather that we had at least an end goal of having just one recommended way to do it.
17:46:18 <geppetto> And it could/should bbe simpler to explain and use
17:48:33 <tibbs> I don't harbor any ideas that this would be something which would be completely implemented in even two years.
17:48:41 <geppetto> :)
17:49:05 <tibbs> But I did promise the proponents of this that I'd try to lint it for grammar and comprehensibility.
17:49:09 <limburgher> Anything we adopt needs to be compatible with the current state, unless we want to draft a multi-release mass renumbering plan.
17:49:42 <tibbs> limburgher: As far as I can tell, it is compatible in that it doesn't make things go backwards if you simply switch a package without updating it.
17:50:04 <tibbs> I put that as one of my personal preconditions.
17:50:24 <limburgher> That was my feeling as well, mostly.
17:50:49 <tibbs> Though I was rather dismayed that one of the proponents argued that you don't need to keep release ordering between Fedora releases.
17:50:57 <limburgher> If not. . .well shit, we could take the opportunity to drop the 'c' from the disttag. :)
17:51:14 <tibbs> Yeah, I would super love to be able to do that.
17:51:34 <limburgher> Just bump epoch on everything and mass rebuild.
17:51:36 * limburgher ducks
17:51:44 * limburgher dons fireproof suit
17:51:51 * limburgher climbs into fridge
17:53:27 <tibbs> limburgher: BTW, do you have any idea which way you're leaning on this?
17:53:43 <tibbs> geppetto and I are leaning pro.
17:53:54 <tibbs> racor is a hard -1.
17:54:20 <limburgher> I've flip-flopped a few times, honestly.
17:54:35 <tibbs> mbooth was -1 but I don't know if he just wants more info before considering anything.
17:55:01 <tibbs> I don't recall what the other folks have said.
17:55:17 <limburgher> Did they get the draft tidied as requested?
17:55:33 <geppetto> I think mbooth was more "change without reason is bad, and I don't see the reason"
17:55:43 <mbooth> What geppetto said.
17:55:53 <mbooth> Last thing I want is unnecessary churn
17:56:19 <limburgher> Yeah.  That's sort of my default position.  I'm good with change if it provides a benefit or fixes a problem.
17:56:23 <tibbs> I just wasn't sure if it was more "and they haven't actually given reasons".
17:56:26 <limburgher> I'm not 100% that's the case.
17:56:29 <tibbs> Which is what I'd hoped they would do.
17:57:08 <limburgher> "Because pretty" and "Because Debian" aren't good reasons.
17:57:17 <geppetto> :)
17:57:31 <limburgher> Except in choosing curtains.
17:57:37 <tibbs> I personally do see that it has the potential to be simpler and puts the upstream versioning information all into Version:, leaving Release: for distro "versioning" information.
17:57:41 <geppetto> Debian curtains?
17:57:48 <mbooth> limburgher: I want these curtains because debian? :-p
17:58:10 <limburgher> I like my curtains like I like my SOs. . .pretty and stable.
17:58:27 <limburgher> Now, for slipcovers. . .rawhide all the way.
17:58:37 <tibbs> It's always bugged me that we override Release: with basically overflow from Version:, but, well, I guess I'm used to it.
17:58:54 * geppetto nods
17:58:55 <limburgher> That's the thing, it's odd, but it works.
17:59:09 <tibbs> But I do think it's telling that so many packages don't get the current rules correct.
17:59:24 <tibbs> I can't say if that would be any different under the proposed rules.
17:59:32 <limburgher> I'm not sure compliance would be better with new rules.
17:59:35 <limburgher> Jinx.
18:00:12 <tibbs> I think if it comes out simpler and makes more sense to more people, then it has the capacity to be easier to follow.
18:00:23 <limburgher> In reality, whatever we do has to allow us the flexibility to deal with upstream weirdness, which the current system generally does.
18:00:24 <tibbs> But that's not something we can know now either.
18:00:36 <tibbs> I'm pretty sure both do at this point.
18:00:37 <limburgher> And simpler doesn't necessarily lead to compliance.
18:00:48 <limburgher> Yeah.
18:01:18 <tibbs> I can say that there's plenty of room to clean up the current rules in a way that makes them simpler to follow.
18:01:56 <tibbs> I don't know if it's significant that nobody has opted to do that but someone has opted to go all out with this new proposal.
18:02:02 <limburgher> That will probably always be true. ;)
18:02:37 <limburgher> Sometimes people get fed up with patching and just fork.
18:04:08 <tibbs> Sure.  When the "upstream" is really bad, or nonresponsive.
18:04:16 <tibbs> And I think we're relatively responsive.
18:04:26 <limburgher> Yeah.
18:04:47 <tibbs> Anyway, for some reason some people really like this tilde thing.
18:05:05 * geppetto nods
18:05:08 <tibbs> For me it's just a balance against the churn.
18:05:10 <mbooth> Okay my time is up, there's only so much bikeshedding I can do in an evening :-)
18:05:25 <geppetto> Yeh, it's over 2 hours now
18:05:28 <tibbs> Yeah, I should probably try to actually do work today.
18:05:41 <limburgher> Ditto.
18:05:47 <geppetto> Unless anyone shouts quickly I'll close
18:06:12 <tibbs> Please.
18:06:51 <geppetto> #endmeeting