16:00:25 <geppetto> #startmeeting fpc
16:00:25 <zodbot> Meeting started Thu Sep  8 16:00:25 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:25 <zodbot> The meeting name has been set to 'fpc'
16:00:26 <geppetto> #meetingname fpc
16:00:26 <geppetto> #topic Roll Call
16:00:26 <zodbot> The meeting name has been set to 'fpc'
16:00:35 <orionp> hello
16:00:42 <geppetto> #chair orionp
16:00:42 <zodbot> Current chairs: geppetto orionp
16:04:40 <geppetto> Well this might be a quick meeting
16:04:42 <tibbs> Howdy.
16:04:47 <geppetto> #chair tibbs
16:04:47 <zodbot> Current chairs: geppetto orionp tibbs
16:04:49 <geppetto> Hey
16:05:17 <tibbs> Had a lot of typing to do.
16:05:43 * Rathann is here
16:05:53 <geppetto> #chair Rathann
16:05:53 <zodbot> Current chairs: Rathann geppetto orionp tibbs
16:06:29 <geppetto> tibbs: n/p ... need still one more for quorum anyway, and no new tickets
16:08:13 <Pharaoh_Atem> tibbs: I don't know if you saw, but I posted a comment in ticket 398 in response to your message
16:08:17 <Pharaoh_Atem> brb
16:09:43 <tibbs> Well, the last section in the draft definitely forbids the minor release bump.
16:10:08 * limburgher here
16:10:09 <tibbs> The "Release Tag" section.  I don't know how you could read it any other way.
16:12:01 <ignatenkobrain> hi everyone
16:12:16 <geppetto> yeh
16:12:33 <Sir_Gallantmon> 👋
16:12:40 <geppetto> We dont' have 5 members atm. ... but we can talk about 398, if you want
16:12:46 <geppetto> #chair racor
16:12:46 <zodbot> Current chairs: Rathann geppetto orionp racor tibbs
16:12:51 <geppetto> And that makes 5 :)
16:12:58 <tibbs> 6.
16:13:09 <geppetto> #topic Schedule
16:13:09 <tibbs> #chair limburgher
16:13:09 <zodbot> Current chairs: Rathann geppetto limburgher orionp racor tibbs
16:13:10 <racor> sorry for being late ;)
16:13:20 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/XKRYWFJ3HGNMTMLZYXH2JPKFX4NF5NU6/
16:13:52 <geppetto> #topic #398 	Tilde in version
16:13:57 <geppetto> .fpc 398
16:13:59 <zodbot> geppetto: #398 (Tilde in version) – fpc - https://fedorahosted.org/fpc/ticket/398
16:14:31 <geppetto> Ok, big update here ... from comment #42 onwards
16:14:59 <tibbs> I'm actually not far from +1 but I still have concerns.
16:15:00 * ignatenkobrain and Pharaoh_Atem made Draft for Guidelines
16:15:07 <geppetto> AIUI the main push here is to have upstream versions just be in the version field, and not bleed over into release
16:15:25 <ignatenkobrain> tibbs: can you write more about concers?
16:15:28 <ignatenkobrain> concerns*
16:15:36 <tibbs> I don't think I can write much more than I already have.
16:16:16 <ignatenkobrain> oh, sorry. I didn't see comments on ticket
16:16:18 * ignatenkobrain reads
16:16:30 <racor> I am still at -1 ... because I do not see any merits from this.
16:16:55 <tibbs> Basically, I'm not willing to accept an argument that "even though it's not complete, it's prettier than what we have now".
16:17:02 <racor> To me this all appears to be a Debian imitation cult, without actual use
16:17:06 <tibbs> I can see the merits.
16:17:20 <tibbs> I explained how I see the merits in the ticket.
16:17:28 <ignatenkobrain> main advantage is that version part goes to Version tag
16:17:37 <racor> which? more confusion with the current rules
16:17:53 <ignatenkobrain> tibbs: actually I noted how to avoid something what is not sortable
16:18:18 <tibbs> Use of epoch is not acceptable.
16:18:18 <geppetto> where?
16:18:41 <Pharaoh_Atem> tibbs: we currently permit it now
16:18:42 <ignatenkobrain> tibbs: why not?
16:18:50 <Pharaoh_Atem> it's mentioned in the current guidelines
16:18:50 <tibbs> It is not acceptable in this case.
16:19:09 <geppetto> epoch is used when there is no other way, and you couldn't see a problem before it happened
16:19:21 <tibbs> geppetto: They say that if your alphatag is not sorted, just bump epoch.
16:19:25 <Rathann> yeah, it's a last-resort option
16:19:25 <tibbs> And... hell no.
16:19:33 <geppetto> tibbs: Yeh, I was agreeing with you
16:19:37 <tibbs> Epoch must stick around forever.
16:19:41 <ignatenkobrain> why?
16:19:47 <Pharaoh_Atem> there's literally no reason for that anymore
16:19:47 <ignatenkobrain> I don't see point
16:19:55 <ignatenkobrain> upgradepath works
16:20:00 <tibbs> No, it doesn't.
16:20:02 <ignatenkobrain> distro-sync/fedup to new release works
16:20:04 <ignatenkobrain> it does
16:20:11 <Rathann> and it forces every package depending on a particular version of the one with epoch include it in its own spec
16:20:16 <tibbs> There are other ways to upgrade.
16:20:23 <Rathann> so it spills over
16:20:30 <Rathann> hence: last resort
16:20:37 <tibbs> I build the rawhide version of packages into current releases all the time.
16:20:47 <tibbs> You simply cannot remove epochs.
16:20:56 <tibbs> So, it's going to be a non-starter.
16:20:59 <geppetto> If you know there are going to be problems, you can fix it some other way (Eg. the current guidelines with N. prefixing
16:21:01 <Pharaoh_Atem> so then we're back to a leading integer
16:21:05 <ignatenkobrain> tibbs: actually I don't see problem with removing Epochs
16:21:06 <tibbs> Please present a better solution.
16:21:27 <tibbs> I mean, even prepending 'Z' is a better solution.
16:21:29 <Pharaoh_Atem> tibbs: would putting a leading integer work?
16:21:35 <geppetto> Yes
16:21:44 <Pharaoh_Atem> then we'll revert to that
16:21:46 <tibbs> Sure, except that now you gain very little over the current scheme.
16:21:47 <Rathann> also, what do you do if kismet upstream releases 1.0.2 after you packaged kismet-1.0+20050515cvs-1%{?dist} ?
16:21:58 <ignatenkobrain> geppetto: tibbs: it's not better because it will confuse dependency generator
16:21:58 <Rathann> introduce epoch here?
16:22:00 <Rathann> madness
16:22:01 <geppetto> Although you might want to just heavily recommend people not use "versions" which are random words/tlas
16:22:17 <Pharaoh_Atem> kismet-1.0.2 is greater than kismet-1.0+20050515cvs
16:22:32 <Rathann> Pharaoh_Atem: then 1.0.1
16:22:33 <ignatenkobrain> if you want in depgen to generate real version dependency (including alpha/beta/etc.) it's only one way
16:22:59 <tibbs> The problem here is that you cannot necessarily know in advance that your upstream is going to do something stupid.
16:23:02 <geppetto> Pharaoh_Atem: % rpmdev-vercmp kismet-1.0.2 kismet-1.0+20050515cvs
16:23:02 <geppetto> kismet-1.0.2 < kismet-1.0+20050515cvs
16:23:09 <tibbs> Our current guidelines handle that.  These don't.
16:23:12 <Pharaoh_Atem> rpmdev-vercmp is wrong
16:23:32 <geppetto> AFAIK it just calls the rpm version comparison tool
16:23:38 <tibbs> Uh, if that's wrong then the rest of the world is wrong.
16:23:38 <Pharaoh_Atem> it doesn't actually match the version comparison algorithm in rpm now
16:23:52 * ignatenkobrain notes to send patch for RPM
16:23:56 <Rathann> it uses python-rpm
16:24:19 <Pharaoh_Atem> I think mls was telling ignatenkobrain and I yesterday about it
16:24:27 <tibbs> Hell, that vercmp thing alone is enough to say we're too deep into untested and potentially busted territory to go for this now.
16:24:28 <Rathann> or rpm-python, actually
16:24:37 <geppetto> Pharaoh_Atem: it calls the rpm API via. python
16:25:11 <Pharaoh_Atem> tibbs: and I disagree with the idea that it's untested and busted territory
16:25:16 <geppetto> Pharaoh_Atem: It's possible for libsolv to act differently, as that has it's own thing ... but if they've diverged that needs to be fixed pretty quickly
16:25:25 <Pharaoh_Atem> SUSE has been using this scheme for several years
16:25:26 <Rathann> I do buy the argument that it would be beneficial to use upstream versions in the Version: field
16:25:32 <tibbs> That's great.
16:26:13 <Rathann> but this one small benefit doesn't justify the downsides
16:26:13 <Pharaoh_Atem> and I have built Fedora packages with this scheme myself to be sure things actually work
16:26:34 <tibbs> So fix the bugs and issues and.. come back when that's done?
16:26:43 * limburgher exhales
16:26:46 <ignatenkobrain> tibbs: can you write down what's the bugs and issues?
16:26:56 <tibbs> I can't write down more than I've already done in the ticket.
16:27:06 <tibbs> Except for the vercmp thing, which I think has been covered.
16:27:11 <tibbs> What else do you believe you need?
16:27:17 <Rathann> also we're not supposed to package alpha/beta/rc/testing/unstable/whatever versions in general
16:27:23 <tibbs> I've typed like 2000 words about this already.
16:27:28 <Rathann> so these cases are an exception
16:27:40 <ignatenkobrain> Rathann: should I run repoquery and grep for alpha/beta/git/etc.? ;)
16:27:47 <Pharaoh_Atem> Rathann: we do it in rawhide a lot at the minimum
16:27:47 <ignatenkobrain> I don't see why it's not allowed
16:27:54 <Pharaoh_Atem> and rpm has been an "RC" for three releases
16:28:17 <Rathann> so you want to justify bad behaviour with "everyone is doing it"?
16:28:22 <geppetto> yeh, different upstreams use those descriptors differently
16:28:27 <Pharaoh_Atem> Rathann: if I must, then I will
16:28:28 <racor> ignatenkobrain: I has never been allowed. Should packages use this, these need to be fixed.
16:28:32 <Rathann> that's childish
16:28:36 <limburgher> It *is* done a lot, which is an excellent reason to get this right.
16:28:39 <tibbs> We're not getting anywhere.
16:28:46 <Rathann> true
16:28:53 <Rathann> I'm -1 to the current proposal
16:29:01 <racor> limburgher: Only debian is doing it
16:29:05 <Rathann> for the reasons stated already many times
16:29:15 <Rathann> I don't see any new convincing arguments
16:29:21 <Pharaoh_Atem> racor: did you miss the fact that openSUSE does it too?
16:29:28 <Pharaoh_Atem> hell, I'm seeing it used in Mageia nowadays too
16:29:29 <limburgher> I'm -1 as well, especially because of Epoch.
16:29:41 <Pharaoh_Atem> we can take Epoch usage out
16:29:44 <tibbs> Debian doesn't even use RPM.  I mean, how is that an argument?
16:29:52 * Rathann mumbles something about millions of flies that can't be wrong
16:29:53 * Pharaoh_Atem sighs
16:29:54 <limburgher> And the current scheme for vcs snapshots works.
16:30:01 <Pharaoh_Atem> except... it doesn't
16:30:15 <limburgher> Why is that?
16:30:22 <tibbs> Here we go again.  This is getting old.
16:30:24 <Pharaoh_Atem> the whole reason ignatenkobrain and I even brought this up again is because packagers get confused and break everything
16:30:32 <tibbs> It works when followed.
16:30:42 <tibbs> Your stuff doesn't work in all cases when followed.
16:30:43 <racor> Pharaoh_Atem: I don't care about this dying distro.
16:30:43 <limburgher> tibbs: +1
16:30:50 <tibbs> _And_...
16:31:05 <tibbs> It's not really that much less confusing.
16:31:17 <tibbs> You really think that users won't get your scheme wrong, too?
16:31:18 <ignatenkobrain> hyperv-daemons-license-0-0.15.20160728git.fc26.noarch
16:31:18 <ignatenkobrain> kernel-modules-4.8.0-0.rc4.git3.1.fc26.x86_64
16:31:18 <ignatenkobrain> arpack-3.3.0-2.b0f7a60git.fc24.x86_64
16:31:18 <ignatenkobrain> python3-iscsi-initiator-utils-6.2.0.873-34.git4c1f2d9.fc25.x86_64
16:31:18 <ignatenkobrain> ...
16:31:21 <tibbs> That's just not an argument.
16:31:26 <limburgher> I've had to package lots of snapshots, often for FTBFS, and managed to avoid magic smoke.
16:31:31 <racor> Pharaoh_Atem:  People cannot expect Fedora to be Debian and have to adopt to Fedora/RH conventions.
16:31:45 <limburgher> tibbs: Indeed.  I do it, and I'm -1.
16:31:46 <ignatenkobrain> it's jsut 4 packages out of thousands which are packaged wrongly because packagers do not understand what they should do
16:32:08 <Pharaoh_Atem> ffs, even our golang packages don't follow our snapshot guidelines
16:32:14 <Pharaoh_Atem> that's dozens of packages
16:32:22 <tibbs> Again, that is not an argument.
16:32:32 <geppetto> #info Take epoch bumping out; resolve the rpm-vercmp problem; post some before/after examples in a comment
16:32:41 <tibbs> geppetto: +1.
16:32:42 <limburgher> Right.  Just because the rules aren't being followed doesn't mean that changing them will increase compliance.
16:32:58 <Pharaoh_Atem> limburgher: it's a symptom that there's a problem with the current rules
16:33:01 <tibbs> Actually I can pretty much guarantee that it will decrease compliance.
16:33:20 <limburgher> A problem with the rules, or a problem with packager compliance?
16:33:26 <racor> Pharaoh_Atem: Then file bugs against them and have them fixed.
16:33:36 <geppetto> tibbs: in the long term?
16:33:36 <ignatenkobrain> problem is in too weird and unclear rules
16:33:38 <limburgher> People commit murder.  Doesn't mean that shouldn't be illegal.
16:33:39 <tibbs> Pharaoh_Atem: You jsut aren't getting it.  Your new rules are still confusing.  They may be less confusing.
16:34:01 <tibbs> But you can't really use either as a valid and convincing argument, sorry.  (At least to me.)
16:34:03 <ignatenkobrain> tibbs: thing is to make rules less confusing as well
16:34:16 <ignatenkobrain> it's not main point, but one of
16:34:18 <limburgher> I think the existing rules could be simplified somewhat without Epochs or tildes.
16:34:24 <racor> Pharaoh_Atem: I do not agree. I think this a symptom of the fedora packaging review process having disrailed
16:34:25 <tibbs> But _you haven't done that_.
16:34:33 <tibbs> That's my whole point.
16:35:01 <tibbs> Your draft isn't really any shorter than the existing guideline.
16:35:21 <tibbs> I said positive comments in the ticket; it's not as if I don't see the point.
16:35:45 <Pharaoh_Atem> I could have shortened it, but I didn't want to take the examples out
16:35:53 <Pharaoh_Atem> there's a lot of redundancy in there I could have removed
16:36:00 <limburgher> short!=simple
16:36:05 <limburgher> long!=complex
16:36:20 <Pharaoh_Atem> tibbs specifically mentioned it wasn't any shorter
16:36:23 <tibbs> Arguing that you could have met some sort of simplicity requirement by removing the examples isn't really a reasonable argument.
16:36:42 <limburgher> Removing the examples would be a major step backward.
16:36:48 <Pharaoh_Atem> which is why I didn't
16:36:50 <tibbs> So, look.
16:37:06 <tibbs> Please fix the issues that have been pointed out.
16:37:26 <tibbs> If you do that, I will be positive towards the concept.
16:37:33 <ignatenkobrain> I see issues and I definitely will be ready to fix that
16:37:43 <Pharaoh_Atem> certainly, we'll adjust them accordingly
16:37:49 <ignatenkobrain> only one problem which I don't see, why Epochs is prohibited in that case
16:37:50 <tibbs> I will still not be sure it's actually worth the effort to change all of this.
16:38:01 <tibbs> I've given an example in this discussion.
16:38:09 <Pharaoh_Atem> it's not worth arguing over Epochs
16:38:21 <limburgher> Epochs are a tool of last resort.
16:38:29 <ignatenkobrain> it's not arguing, it was question (because I really don't understand)
16:38:33 <tibbs> I'm willing to entertain arguments that is actually worth the effort to change all of this.
16:38:40 <limburgher> Like airbags.  There if you need them, but for safety, not comfort.
16:38:57 <tibbs> And if we do have a thing which at least some of us would find acceptable, I would like to involve FESCo.
16:39:37 <geppetto> What for?
16:39:51 <tibbs> It impacts every single packager.
16:40:09 <tibbs> Not currently every single package (because most just package release versions).
16:40:16 <tibbs> But potentially every one.
16:40:21 <geppetto> That feels like it'd be pretty arbitrary ... there are some people on FESCo who understand the pros/cons here, but I'm not sure all do
16:40:38 <tibbs> I just want buy in.
16:41:04 <tibbs> Give them a summary of what would be changing and the merits of it.
16:41:24 <orionp> One thing this brought up for me, is the current misuse of git snaphot release tags not containing a date prefix - which would be exacerbated with this versioning scheme.  But I think we need to fix https://fedoraproject.org/wiki/Packaging:SourceURL#Commit_Revision
16:41:34 <tibbs> This is just too huge a thing for us (as basically a fesco subsidiary) to change.
16:41:36 <geppetto> Eh, that could be said about a lot of stuff ... I guess it can't hurt, if we want to approve something, to have a general "just to make sure, this is kind of a big change, so speak now if you really object for some reason"
16:42:14 <tibbs> Yes, that's basically it.  And why we have that clause about involving fesco in any decision if any committee member wants to do so.
16:42:19 <geppetto> orionp: The problem there is that the date of the commit isn't that useful
16:42:29 <tibbs> It sort of is and sort of isn't.
16:42:40 <limburgher> True, but dates sort better than SHA.
16:42:41 <tibbs> It depends on what you think the version-release is there for.
16:42:51 <racor> tibbs: I am not sure if your intention is nice or an act to circumvent FPC.
16:42:52 <geppetto> orionp: I guess it is more if it's just snapshots from master, but I don't think that covers all usage
16:43:17 <geppetto> racor: Can probably assume the best from tibbs
16:43:25 <tibbs> racor: It's basically to make sure we don't have a huge outrage again.
16:43:31 <ignatenkobrain> limburgher: dates are useless, interesting thing is count (git rev-list --count) and hash. but this topic is not about this
16:43:57 <ignatenkobrain> tibbs: Version is for Version and Release is for dist-branch specific things
16:44:02 <ignatenkobrain> like rebuilds/etc.
16:44:04 <orionp> the proposed scheme move the scm tag into the version field, and it's critical that it sorts
16:44:05 <Rathann> ignatenkobrain: dates are not useless if you want to know how old a source snapshot is
16:44:12 <tibbs> ignatenkobrain: I believe you miss the point.
16:44:21 <ignatenkobrain> tibbs: possible
16:44:28 <racor> geppetto: I am not sure, anymore. Delegating a problem we are supposed to solve to a group of people of whom I expect the majority not even to comprehend it, is at least "questionable".
16:44:29 <tibbs> version-release has meanings for both RPM and for humans looking at them.
16:44:54 <ignatenkobrain> Version is interesting for humans, Release is interesting for developers/bugreporters
16:45:01 <orionp> the current guidelines technically require the date prefix too
16:45:01 <limburgher> racor: I think by the time we run this by FESCO, we'll all have contributed our understanding.
16:45:15 <tibbs> ignatenkobrain: That does not describe the current state of affairs.
16:45:32 <racor> ignatenkobrain: No, not true.
16:45:38 <geppetto> racor: As I said, if we did send it to them I think we'd want to heavily mark out what we wanted ... but allow someone to say "this is bad because..." ... which is probably what tibbs meant anyway
16:45:41 <tibbs> Nor how Fedora has interpreted it since Fedora's inception.
16:46:07 <tibbs> I understand that your proposal changes that.  Which is fine; it's one of the merits I see in it.
16:46:27 <tibbs> But you can't just state that the way you want it to be is the way it currently is, and that Fedora is just wrong.
16:46:45 <tibbs> I hope you can see my point.
16:46:48 <geppetto> ignatenkobrain: I'm not sure I'd agree with that interpretation of version/release
16:47:02 <ignatenkobrain> geppetto: what's your interpretation?
16:47:24 <racor> tibbs: Exactly. One can also turn this argument around: ignatenkobrain has not yet understood rpm's versioning.
16:47:30 <limburgher> I don't think you can make a case that any field is of primary interest to a particular party.
16:47:38 <ignatenkobrain> racor: I do
16:47:39 <geppetto> Well a lot of "humans" care about certain bugfixes ... eg security ones. Not all of those are rebases, even in Fedora
16:47:52 <geppetto> So users (aka. humans) care about release too
16:48:12 <Pharaoh_Atem> strictly speaking,  what most people consider the "canonical" reference on what things "are" says that the version field indicates the version of the packaged software: http://www.rpm.org/max-rpm/ch-rpm-file-format.html
16:48:22 <Pharaoh_Atem> whereas the release is the number of times the software has been packaged
16:48:24 <ignatenkobrain> geppetto: hm, yes. security fixes. okay, bugreporters/developers/security people are interested in release
16:48:27 <limburgher> Right.  There's nothing in 1.4.0-6 that indicates that it includes a backported security patch from 1.5.3.
16:48:41 <geppetto> And you could easily argue that upstream pre-release versions are something "humans" don't care about, so putting that data in the version field goes against your definition
16:48:53 <Rathann> so, developers and bugreporters are not humans?
16:48:59 <Pharaoh_Atem> geppetto: I would find that argument hard to believe
16:49:04 <racor> ignatenkobrain: then why are you proposing the Debian versioning scheme. What actual technical advantage does it have over what we have been using for years.
16:49:19 <ignatenkobrain> racor: I'm not proposing Debian versioning scheme
16:49:31 <ignatenkobrain> it has nothing to do what Debian does
16:49:55 <ignatenkobrain> I even never see it.
16:50:11 <geppetto> Pharaoh_Atem: I would say that most people when they see "2.1.0~foo-5" ... the main thing they care about is that it's really close to upstream 2.1.0
16:50:36 <ignatenkobrain> geppetto: foo usually will be alpha/beta/rc. sometimes git
16:50:44 <geppetto> ignatenkobrain: sure
16:50:47 <ignatenkobrain> in case of git we can't say how close it to upstream 2.1.0
16:50:51 <ignatenkobrain> but for others we can
16:50:54 <racor> ignatenkobrain: then which technical advantages does your versioning scheme have over what we have been using for years? I don't see any.
16:51:30 <geppetto> racor: The main one is that upstream versions will always go into the version field, and distro. versions into the release field
16:51:59 <Pharaoh_Atem> racor: it's a clear separation of the versioning between upstream and downstream
16:52:05 <ignatenkobrain> geppetto: +1
16:53:16 <racor> geppetto: Eye-candy, featuritis.
16:54:12 <geppetto> racor: There is some eye-candy aspect to it ... but if it does look nicer that isn't nothing. I can also see arguments that tools can/will be happier with a harder split
16:54:22 <limburgher> For me, the benefits of a change like this need to outweigh the risks.  And as it stands, I'm not sold on the downsides of the current arrangement, when complied with.
16:55:12 <geppetto> Right, if ignatenkobrain can take the comments from this meeting and remove a lot of the downsides I think that will help evaluate the pros vs. cons better
16:55:29 * ignatenkobrain will do this
16:55:38 <limburgher> Agreed.
16:55:41 <geppetto> So unless anyone wants to shout at anyone else a bit more ... I say we leave this now for another meeting?
16:56:21 <geppetto> Ok 👍
16:56:31 <Pharaoh_Atem> okay
16:56:34 <limburgher> geppetto:  Wrong for versioning, wrong for America (Paid for by citizens for better bikesheds)
16:56:35 <limburgher> ;)
16:56:44 <geppetto> #topic Open Floor
16:56:45 * Pharaoh_Atem splutters
16:57:01 <geppetto> Ok, I don't think there's much to talk about on 558 or 610
16:57:08 <limburgher> I concur.
16:57:12 <geppetto> But if there is, shout now ... or about anything else
16:57:35 <orionp> Can we follow up with my concern about dates in git snapshots?
16:58:00 <Pharaoh_Atem> fwiw, I usually use both a date and the git hash
16:58:06 <racor> orionp: Could you repeat them?
16:58:06 <limburgher> Is this vis-a-vis 398>
16:58:07 <geppetto> orionp: You want to talk about it now, or open a ticket or somment in 398?
16:58:14 <Pharaoh_Atem> the date for sorting, and the git hash for information
16:58:17 <geppetto> s/somment/comment/
16:58:41 <geppetto> orionp: The main problem I can think of is that I don't think all git snapshots come from master
16:58:46 <orionp> https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages requires a date in the snapshot release
16:59:20 <orionp> geppetto: I don't think the branch is relevant - every commit has a date
16:59:21 <geppetto> orionp: So the date doesn't really give the right information (and even on master you can rebase/merge older commits)
16:59:40 <geppetto> orionp: Right, but when you put a date in people assume newer == better ... and tha'ts the bit that's not true
17:00:20 <ignatenkobrain> I would prefer to have number of commits since tag
17:00:25 <ignatenkobrain> as this is more useful
17:00:31 <orionp> I'm just looking at what our guidelines say and trying to be consistent
17:00:38 <ignatenkobrain> you can see if there were 3-5 commits or 1k commits since tag
17:00:39 <tibbs> We've already had a big argument about using tags at all.
17:00:45 <tibbs> Since tags can move.
17:00:50 <geppetto> it's probably more than 50% of the time, but not 100% ... and I'm not sure where on the spectrum it falls.
17:01:10 <geppetto> tibbs: I think he means release tags
17:01:27 <limburgher> Not all vcs users use tags in their repos.
17:01:30 <tibbs> I'm not sure how that differs.
17:01:46 <geppetto> So if you have 1.0.1~N ... the N would be commits on master since 1.0.1
17:01:48 <tibbs> The git hash is pretty much the only universal thing we have.
17:01:49 <ignatenkobrain> basically there is no guarantee that release tarball will not be swapped
17:02:04 <tibbs> Fortunately we can detect that.
17:02:18 <limburgher> I'd rather have hash, commit #, because if N is large I have to git clone, git log, and count. . .
17:02:18 <ignatenkobrain> tibbs: I would prefer num of commits AND hash
17:02:48 <tibbs> ignatenkobrain: Sure, but at some point there's only so much you can actually encode into version-release before you lose utility to humans.
17:02:49 <geppetto> Yeh, I'm pretty sure orionp wants date and hash too ... I can see the desire for both
17:02:53 <racor> ignatenobrain: That's non workable.
17:03:05 <geppetto> And if they are useful are large percentage of the time, I'm happy to require them
17:03:06 <limburgher> date and hash are both good.
17:03:20 <racor> geppetto: I am in favor of date and hash, also
17:03:23 <limburgher> date guarantees sorting, hash guarantees reproducibility.
17:03:25 <tibbs> Plus.... the current guidelines don't forbid what you want to do.
17:03:31 <geppetto> Anyone want to volunteer to get some stats.?
17:03:36 <ignatenkobrain> limburgher: date doesnt guarantee sorting
17:03:43 <tibbs> ignatenkobrain: Note that everything after "git" is entirely up to the packager.
17:03:57 <orionp> ignatenkobrain: you're counting on it in your proposal
17:03:58 <ignatenkobrain> limburgher: for mesa I was doing 2-3 snapshots per day
17:03:59 <Pharaoh_Atem> ignatenkobrain: number of commits after release is also non-obvious
17:04:00 <limburgher> Now so?  In my experience, dates have been going inexorably up.
17:04:04 <tibbs> Hell, you don't even have to use "git" if you don't want to.
17:04:13 <Pharaoh_Atem> it took me forever to figure out that's what the 522 was on the apt package in Fedora
17:04:18 <ignatenkobrain> orionp: I didn't want to touch that topic because not everyone will like it
17:04:29 <ignatenkobrain> orionp: I wanted to touch "+" and "~" in topic
17:04:35 <racor> One problem however, due to "git merge" etc. commit dates aren't necessary ordered
17:04:45 <limburgher> racor: ^THIS
17:04:56 <Pharaoh_Atem> racor: so why not use the date you make the snapshot?
17:04:58 <tibbs> The date is the date when you made the snapshot.  Nothing more.
17:05:05 <limburgher> Yes.
17:05:18 <racor> Pharaoh_Atem: That's what I actually do!
17:05:25 <Pharaoh_Atem> it's what I do too
17:05:29 <ignatenkobrain> in guidelines it's written differently AFAIK
17:05:35 <ignatenkobrain> that it should be date of commit
17:05:37 <Rathann> ugh, apt package versioning is horrible
17:05:39 <tibbs> I think everyone should make sure they've read https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages pretty well.
17:06:09 <limburgher> "%{checkout} consists of the date that the snapshot is made in YYYYMMDD format, a short (2-5 characters) string identifying the type of revision control system or that this is a snapshot, and optionally, up to 13 characters (ASCII) alphanumeric characters that could be useful in finding the revision in the revision control system. "
17:06:13 <tibbs> The only thing we require is the date you took the snapshot and a short identifying string.
17:06:20 <ignatenkobrain> my bad. though I'm not fan of dates
17:06:26 <ignatenkobrain> and as I said I had problems with date
17:06:28 <Pharaoh_Atem> Rathann: I finally figured it out when I saw one of the apt devs actually merge the apt-rpm code against the debian apt 0.5.15 release
17:06:30 <limburgher> I'm more of a prune person myself.
17:06:30 <ignatenkobrain> as I did 2-3 snapshots per day
17:06:35 <Pharaoh_Atem> and it said 522 commits ahead
17:06:37 <tibbs> You have 13 characters to do whatever you want.
17:06:48 <limburgher> Just like D&D.
17:07:00 <tibbs> And the leading integer makes everything sort, so it doesn't matter if you take more than one snapshot.
17:07:18 <orionp> So if we're all on board with the current date requirement, I think we need to fix the last sentence of https://fedoraproject.org/wiki/Packaging:SourceURL#Commit_Revision
17:07:50 <tibbs> That was probably just an oversight.
17:07:59 <orionp> " You can substitute %{shortcommit0} for %{checkout} in that section."  to "You can substitute %{shortcommit0} for the git hash in %{checkout} in that section.
17:08:24 <tibbs> Fixing now.
17:08:26 <limburgher> I imagined that the author's mind was addled from trying to grok github's URL system.
17:08:40 <Rathann> orionp, tibbs: +1
17:08:45 <tibbs> Done.
17:09:03 <orionp> great, thanks.
17:09:07 <limburgher> tibbs++
17:09:07 <zodbot> limburgher: Karma for tibbs changed to 5 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:09:13 <Rathann> orionp++
17:09:13 <zodbot> Rathann: Karma for orion changed to 4 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:09:18 <geppetto> Ok, anyone want to check how many packages are now non-compliant ?;)
17:09:26 <orionp> lots
17:09:30 <limburgher> N
17:09:31 <tibbs> I would be open to revising the date requirement if there's a useful alternative which still communicates something to the end user.
17:09:32 <Pharaoh_Atem> nearly all, probably
17:09:36 <orionp> including mine
17:09:36 <tibbs> But certainly not now.
17:10:08 <orionp> My concern is that the proposed +/~ scheme with git checkouts requires the date to sort
17:10:11 <tibbs> The other fun thing is that these guidelines are mostly to keep people from screwing up and getting the ordering wrong.
17:10:27 <tibbs> Our tools actually make this pretty obvious now; back in the old days that wasn't the case.
17:10:38 <orionp> so I tend to think the leading integer in the current scheme helps out a lot
17:10:47 <limburgher> It does.
17:10:55 <tibbs> So people have gotten by with bad versioning and not noticed.
17:11:18 <tibbs> I wish it were possible to automatically check that the versions match some criteria.
17:11:19 <orionp> one last thing - there's a link to jpackage guidelines - jpackage is long dead
17:11:27 <tibbs> Ugh, where is that?
17:11:30 <limburgher> Which, one could argue, isn't that huge a deal, if no kittens are harmed.
17:11:35 <Pharaoh_Atem> right on the snapshot versioning page
17:11:46 <Pharaoh_Atem> I wasn't sure what to do with that either
17:11:50 <Pharaoh_Atem> I left it alone in my draft
17:11:59 <orionp> last bullet in "Version Tag"
17:12:06 <geppetto> yeh, it's probably fine to just delete it all
17:12:06 <tibbs> Should we just remove the whole JpackagePolicy document?
17:12:15 <geppetto> +1
17:12:15 <orionp> tibbs: +1
17:12:17 <Rathann> +1
17:12:18 <Pharaoh_Atem> please do so
17:12:39 <Pharaoh_Atem> JPackage is long-gone, and every distro has absorbed their packages and changed it since
17:13:10 <limburgher> +1
17:13:13 <tibbs> The page is gone.
17:13:17 <Pharaoh_Atem> :D
17:13:48 <tibbs> And the bullet point is gone now as well.
17:14:04 <tibbs> Anything else I should tweak?
17:14:27 <orionp> I think that was all I saw when reviewing this
17:14:32 <Pharaoh_Atem> I'm god
17:14:33 <Pharaoh_Atem> *good
17:14:39 <limburgher> Modest, as well.
17:14:42 <Pharaoh_Atem> haha
17:14:43 <geppetto> :)
17:15:11 <tibbs> BTW, I patched it in the existing guideline, not in the draft for 398.
17:15:28 <Pharaoh_Atem> ignatenkobrain and I will kill it when we make the other mods
17:15:30 <geppetto> Ok, I'm going to close the meeting in a minute or so. Unless anyone has anything else for today.
17:15:31 <limburgher> Cool.  I assumed as much.
17:15:36 <geppetto> tibbs: Yeh, that's what I assumed
17:15:37 <limburgher> Not I.
17:15:49 <racor> I have something
17:15:50 <Pharaoh_Atem> it's all gravy
17:15:57 <geppetto> racor: Yeh?
17:16:05 <tibbs> Do note that I did throw out a draft for....
17:16:14 <tibbs> https://fedorahosted.org/fpc/ticket/558
17:16:18 <tibbs> But racor first.
17:16:25 <racor> we have packages entering fedora which do not support -msse2
17:16:45 <limburgher> We have packages already in as well.
17:16:52 <racor> e.g. require to be compiled with -mssse3
17:17:00 <geppetto> ok
17:17:04 <Rathann> racor: make them x86_64 only?
17:17:16 <tibbs> Aren't there x86_64 that don't have that, too?
17:17:23 <tibbs> I don't recall the details.
17:17:26 <Rathann> ah right
17:17:37 <geppetto> Is that right?
17:17:42 <Rathann> it is
17:17:47 <racor> Rathann: -mssse3 is not in fedoras CFLAGS
17:17:57 <Rathann> x86_64 ABI includes SSE2 only
17:18:16 <racor> Rathann: exactly.
17:18:20 <Rathann> racor: can you provide an example of a package that uses SSSE3 unconditionally?
17:18:39 <tibbs> So the issue is that we have packages compiled in such a way that they cannot run on some subset of our supported architectures?
17:18:47 <racor> https://bugzilla.redhat.com/show_bug.cgi?id=1372866
17:19:12 <tibbs> I'm not sure we have any packaging guidelines on this besides not screwing with the provided cflags.
17:19:33 <tibbs> Also, glibc supports a way around this now.
17:19:54 <tibbs> We might want to consider guidelines for that, but I don't know enough to write them.
17:19:57 <racor> tibbs: If you want to put it this way, yes. To put converse: We have packages in x86_64, which do not comply to the minmal instruction set fedora is supposed to support.
17:21:00 <limburgher> Eew.
17:22:01 <tibbs> Anyway, these packages do need to be fixed if possible.
17:22:05 <geppetto> Yeh, as tibbs said I'm not sure what to do. I know we've had CPU features requirments before
17:22:09 <geppetto> Esp. for the kernel package
17:22:24 <tibbs> But do note that we also say you need some amount of RAM to run Fedora.
17:22:36 <tibbs> That doesn't mean that everything in the repo will actually run on said minimal system.
17:22:41 <geppetto> But there's always been a backup ... unless rel-eng signed off on it
17:22:58 <geppetto> But not shipping the package doesn't seem like a good solution either ... so *shrugs*
17:23:19 <tibbs> So it is sort of a grey area.  I mean, if the upstream software doesn't support ancient x86_64 cpus, I don't see the benefit in kicking it out.
17:23:26 <geppetto> I assume hyperscan builds everywhere?
17:23:43 <geppetto> It just doesn't work on some CPUs that are x86_64?
17:23:47 <tibbs> To go from "most people can use the package" to "nobody can use the package" doesn't seem productive.
17:24:09 <Rathann> it won't build on i686 without -mssse3 if I understand correctly
17:24:15 <racor> geppetto: No, it doesn't. I only supports mssse3 supported x86_64's and nothing else.
17:24:32 * geppetto nods ... and those are really common?
17:24:43 <tibbs> Not particularly, but they do exist.
17:24:46 <Rathann> geppetto: it depends
17:25:02 <Rathann> they might be more common in poorer countries
17:25:29 <geppetto> I wonder if we can get someone to get a CPU feature test for msse3 and then exit with an error message if it fails?
17:25:56 <racor> geppetto: I don't know. But we require all packages to honor "our CFLAGS", reason being a "common instruction set"
17:25:57 <geppetto> Rathann: I meant msse3 supporting cpus are really common
17:26:11 <Rathann> ah
17:26:14 <Rathann> let me look it up
17:26:29 <tibbs> Where is the actual guideline that says that you can't mess with cflags?
17:26:50 <geppetto> I'm pretty sure the guidline just says that you have to use RPM_OPT_FLAGS
17:27:04 <geppetto> not that you can't add stuff which changes that
17:27:06 <tibbs> Ah, there it is.
17:27:07 <Rathann> geppetto: SSSE3 is 10 years old
17:27:11 <tibbs> Was searching for the wrong thing.
17:27:14 <orionp> https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
17:27:24 <Rathann> https://en.wikipedia.org/wiki/SSSE3
17:27:28 <tibbs> "generally discouraged" and "revisited on a case-by-case basis".
17:27:32 <geppetto> Rathann: Ok, not new then
17:27:34 <tibbs> So....
17:27:44 <tibbs> Needs updating to MUST and SHOULD, definitely.
17:27:55 <geppetto> Yeh, I'm fine with letting it go ... although it'd be nice to not just crash on bad instruction or whatever
17:28:09 <tibbs> Not crashing is indeed generally preferable.
17:28:14 <geppetto> :)
17:28:22 * Rathann notes that not crashing is only a SHOULD
17:28:34 <tibbs> But I can see upstreams not caring about old CPU support.
17:28:59 <tibbs> The issue is when that gets into a dependency tree, so you start losing larger blocks of packages.
17:29:10 <Rathann> tibbs: I have a couple of packages where upstreams don't test on non-SSE2 CPUs at all
17:29:12 <tibbs> hyperscan is a library, isn't it?
17:29:30 <racor> I just checked my machines, and I have one without ssse3
17:29:33 <geppetto> Is this ssse3 in cpuflags?
17:29:34 <Rathann> if it's a library then it shouldn't crash on Fedora-supported hardware
17:29:54 <orionp> yes, being a library is a concern
17:29:58 <racor> model name	: AMD Turion(tm) II Neo N40L Dual-Core Processor
17:30:14 <Rathann> nice
17:30:21 <tibbs> I do think there are CPUs made within the last five years that don't support sse3.
17:30:33 <racor> It's an hp n40l microserver
17:30:36 <geppetto> Also not sure what it should do if one of the CPUs in a machine doesn't support ssse3 and one does ... hope the scheduler gets lucky?:)
17:31:01 <Rathann> geppetto: I don't think that's possible in practice
17:32:27 <tibbs> So the topic I take from this is: how should we reword the compiler_flags guideline?
17:32:36 <geppetto> ¯\_(ツ)_/¯
17:32:41 <tibbs> And let fesco handle arch support in general.
17:33:12 <tibbs> It's not as if they haven't talked about it recently.  But I don't think they specifically covered the case of packages which simply don't support sse2-only CPUs.
17:33:51 <tibbs> "Packagers MUST not override these flags for performance optimizations"?
17:33:57 <tibbs> Or "SHOULD NOT"?
17:34:23 <tibbs> Remember that MUST means you have to ask us.  SHOULD means you have to document your reasons in the spec.
17:34:45 <tibbs> Not that most folks will do that anyway, but still....
17:35:03 <geppetto> so ... what kind of unicorn do we want to wish for?
17:35:04 <limburgher> Took the words right out of my fingers.
17:35:13 <tibbs> Well, one thing at a time.
17:35:16 <tibbs> Start with ponies.
17:35:21 <limburgher> OMG
17:35:37 <geppetto> I'm mostly happy with SHOULD, I think
17:36:00 <geppetto> But I won't argue strongly against MUST
17:36:05 <tibbs> I think SHOULD keeps the existing spirit of the guidelines.
17:36:14 * geppetto nods
17:36:32 <tibbs> The whole point of that was to get away from people building with -O9 because fastererer.
17:36:48 <tibbs> That was a fun discussion way back in the before time.
17:37:08 <Rathann> +1
17:37:43 <Rathann> shall I file a ticket with FESCo what to do (if anything) about software that doesn't run on all Fedora supported hardware?
17:37:54 <tibbs> I think that would be a good idea.
17:38:10 <tibbs> Though if we want to propose something, we should do that.
17:38:26 <tibbs> I just don't know what to propose besides somehow noting that fact in the package %description.
17:38:51 <tibbs> Maybe using a wrapper that greps /proc/cpuflags so that the package doesn't crash?
17:39:09 <orionp> get fesco to set a policy, we'll get that into the guidelines somehow
17:39:09 <tibbs> Assuming the package would crash and not handle the problem.
17:39:29 <racor> I am for "MUST" because otherwise our rules on CFLAGS and architecture are not worth the bits used for them.
17:39:30 <limburgher> It would be fun if the software itself checked for it's own requirements. . .
17:39:32 <tibbs> Right, but sometimes fesco likes having proposals.  Sort of like we have drafts.
17:39:37 <Rathann> well with i686 SSE2 vs non-SSE2 it's easy, you just put sse2 libs in /usr/lib/sse2 and ld will automatically load those on sse2-capable CPU
17:40:07 <Rathann> how about MUST for libraries and SHOULD for applications?
17:40:12 <ignatenkobrain> -Ofast ;)
17:41:03 <racor> I regret, but it's late for me, I need to quit now.
17:41:22 <tibbs> racor: Perhaps.
17:41:34 <tibbs> racor: Oops, sorry, that was supposed to be Rathann.
17:41:41 <tibbs> racor: But do take care.
17:41:41 <orionp> I really don't have a proposal - seems like it's a shame to forbid software completely, but we don't want a lousy user experience either
17:41:54 <orionp> I need to leave here too
17:42:01 * geppetto nods
17:42:03 <tibbs> Personally I think a wrapper is pretty reasonable, actually.
17:42:11 <geppetto> I can close, and we'll come back to it
17:42:13 <tibbs> A system-wide one would be trivially.
17:42:13 <limburgher> Yeah, we do it for opengl. . .
17:42:21 <geppetto> The problem with a wrapper is that it only works for apps
17:42:21 <tibbs> trivially doable.
17:42:30 <racor> orionp: I consider compliance to our architecture's a necessary requirement.
17:42:41 <tibbs> Well, you wrap apps that use the library.
17:42:44 <geppetto> and it's much more likely for libs ... and the current problem is a lib
17:42:51 <geppetto> Yeh, I guess
17:42:53 <tibbs> racor: Out of the scope of this committee in any case.
17:43:06 <tibbs> But when Rathann files the fesco ticket, you should definitely comment there.
17:43:09 <orionp> racor: Yes, I'm sympathetic to that view
17:43:30 <orionp> hopefully there's a reasonable technical fix.
17:43:56 <racor> tibbs: No. we mandate compliance to "our architecture". It's the rationale for banning many  CFLAGS.
17:44:10 <tibbs> Fesco decides what that is, not us.
17:44:19 <tibbs> Let them do their job and we can do ours.
17:44:27 <limburgher> They do what, we do how.
17:44:53 <racor> now, I really need to go ....
17:45:06 <geppetto> ok, see you next week
17:45:25 * limburgher waves
17:45:40 <tibbs> So, hopefully folks will look over https://fedorahosted.org/fpc/ticket/558#comment:19 at some point.
17:45:48 <tibbs> I will turn that into a wiki page at some point.
17:45:51 <limburgher> Yes.
17:46:16 <tibbs> Just wanted to get something out there since I'm like a year late in providing that draft.
17:46:23 <geppetto> :)
17:46:28 <tibbs> I don't like it, but it does kind of say what I think needs to be there.
17:46:40 * geppetto nods
17:48:24 <geppetto> Ok, I think that's it
17:48:30 <geppetto> See you next week
17:48:34 <geppetto> #endmeeting