17:00:27 <geppetto> #startmeeting fpc
17:00:27 <zodbot> Meeting started Thu Nov 15 17:00:27 2018 UTC.
17:00:27 <zodbot> This meeting is logged and archived in a public location.
17:00:27 <zodbot> The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:27 <zodbot> The meeting name has been set to 'fpc'
17:00:27 <geppetto> #meetingname fpc
17:00:27 <zodbot> The meeting name has been set to 'fpc'
17:00:27 <geppetto> #topic Roll Call
17:00:36 <ignatenkobrain> .hello2
17:00:37 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
17:00:51 <geppetto> #chair ignatenkobrain
17:00:51 <zodbot> Current chairs: geppetto ignatenkobrain
17:01:13 <redi> hi
17:01:20 <geppetto> #chair redi
17:01:20 <zodbot> Current chairs: geppetto ignatenkobrain redi
17:01:23 <tibbs> Hey.
17:01:32 <geppetto> #chair tibbs
17:01:32 <zodbot> Current chairs: geppetto ignatenkobrain redi tibbs
17:01:32 <decathorpe> hi guys
17:01:32 <tibbs> Sorry, busy morning for me.
17:01:35 <geppetto> #chair decathorpe
17:01:35 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain redi tibbs
17:01:43 * decathorpe online on phone only
17:01:52 <mhroncok> hi
17:01:59 <geppetto> #chair mhroncok
17:01:59 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok redi tibbs
17:05:17 <geppetto> #topic Schedule
17:05:26 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/YFLCBJS74CBQJXQQONDXNRHEVUHBZ6VP/
17:05:38 <geppetto> #topic #806 Procedure should be updated for Pull Requests
17:05:38 <geppetto> .fpc 806
17:05:39 <zodbot> geppetto: Issue #806: Guideline Change Procedure should be updated for Pull Requests - packaging-committee - Pagure.io - https://pagure.io/packaging-committee/issue/806
17:06:31 <mhroncok> should we dicsuss the issue vs PR thing?
17:06:53 <mhroncok> I think that it always depends on the nature of the problem
17:07:04 <redi> I was about to say I don't see a benefit to separating them, but tibbs's point about discussion vs concrete changes makes sense too
17:07:21 <tibbs> Some things are trivial and we'll just merge them.
17:07:25 <ignatenkobrain> I think if we need some conversation without any specific proposal I would use issues, but discussing some specific proposal makes sense in PR IMO
17:07:26 <tibbs> Some things require discussion.
17:07:26 <mhroncok> e.g. if something is just cosmetic change, fesco approved change, etc. it can go as PR only
17:07:42 <redi> yeah it's pointless having an issue which is empty, and just points to a pull req
17:07:45 <mhroncok> but if peeople  actually request a chenage of púolicy, they should open an issue IMHO
17:07:49 <tibbs> Sadly pagure, like github, separates PRs and tickets in ways that shouldn't really be separate.
17:08:14 <tibbs> If all else fails, one of us can just open an issue but it's one more thing that could be missed.
17:08:51 <tibbs> We can tag PRs like we can tag tickets, so I guess looking at those could also be made part of the agenda generation process.
17:09:17 <ignatenkobrain> I tagged one PR for meeting today actually
17:09:22 <geppetto> Yeh, I feel like PRs should be used when we know (or mostly know) what the change should be and need to do it. Anything less than that should be hashed out in an issue first
17:09:48 <geppetto> Yeh, another problem is that only issues come up on the report.
17:09:59 <tibbs> You have to make another report.
17:10:06 <mhroncok> another problem is that PR is closed when it's merged
17:10:06 <tibbs> I still don't get why they are shown separately.
17:10:20 <tibbs> And yes, merging auto-closes which is annoying as well.
17:10:33 <mhroncok> we usually kept the issue open until announced
17:10:34 <tibbs> So things miss the announcement phase.
17:10:43 <mhroncok> and that happens after the wiki change (or commit) is made
17:10:44 <geppetto> tibbs: You know of a way to tagPRs?
17:10:45 <ignatenkobrain> we can disable this
17:10:47 <tibbs> So definitely we need an issue for any change that will be announced.
17:10:55 <tibbs> You can tag PRs exactly like tickets.
17:11:10 <geppetto> Hmm, ok
17:11:19 <tibbs> Because they are tickets, but not shown in the same place for reasons.
17:11:37 <ignatenkobrain> another option which we could go might be to tag commit so basically what was after latest tagged commit -- was not announced
17:11:42 <ignatenkobrain> when we announce, we push new tag
17:11:58 <tibbs> That's.... overcomplicating things.
17:12:25 <mhroncok> ignatenkobrain: let not
17:12:31 <tibbs> I mean, sure, I don't object to tagging things but it would just result in yet another place we'd have to look for things to announce.
17:13:02 <ignatenkobrain> actually if you write in commit message "Relates", "References", then issue is not getting closed
17:13:10 <ignatenkobrain> but if you write "Fixes", "Closes", then it does
17:13:31 <tibbs> The issue doesn't close, but the PR does close.
17:13:53 <redi> which imho makes sense if it's merged
17:14:05 <mhroncok> yes but that a reson we need an extra issue
17:14:09 <redi> yeah agreed
17:14:20 <tibbs> It's just one more thing we need to worry about.
17:14:36 <mhroncok> conclusion: whatever needs announcement needs an issue
17:14:38 <mhroncok> right?
17:14:41 <tibbs> For me the biggest issue is that there won't necessarily be one PR per change.
17:15:08 <tibbs> mhroncok: Yes, certainly everything that will need an announcement needs an issue.
17:15:17 <tibbs> I would say that everything which needs committee discussion needs an issue.
17:15:29 <ignatenkobrain> how is it better than having tags? tag message can be exactly announcement?
17:15:41 <tibbs> The worst thing that would happen is someone opens an issue they don't need to open.
17:16:25 <tibbs> ignatenkobrain: I know you love this process but it's just more complexity that's not needed right now.
17:16:45 <ignatenkobrain> I'm fine with either way
17:16:46 <tibbs> Plus, you know, in an issue we could discuss something like the announcement message if we need to.
17:17:07 <mhroncok> that's important
17:17:26 <ignatenkobrain> github actually recently made feature to propose a tag as pull request so that you can discuss it there ;)
17:17:39 <tibbs> And getting lost in pushing revisions to tags and fast forwards and more git nonsense is just not where I want to be.
17:17:51 <ignatenkobrain> but let's not rathole on this, I think conclusion is that if we need announcement or decision, we need an issue
17:18:10 <tibbs> I know some people love git and its random bizarre features but endless git reset --hard invocations is not how I want to spend my life.
17:18:18 <mhroncok> OT: I search wehere would I update the issue templates but fail to find it
17:18:38 <tibbs> They are in the ticket repo.
17:18:55 <tibbs> Click "clone" and you should see how to clone "Issues".
17:19:01 <tibbs> ssh://git@pagure.io/tickets/packaging-committee.git
17:19:16 <mhroncok> tibbs: thanks
17:19:27 <mhroncok> I'll update the draft part to have a link to PR instead
17:19:38 <tibbs> Under there should be a "templates" directory.
17:20:18 <tibbs> I'm also unclear on what we should do with a PR that can't now be merged.
17:20:32 <tibbs> It seems really poor form to keep asking people to rebase.
17:20:48 <tibbs> And I personally don't even know how to rebase.
17:21:24 <ignatenkobrain> I think it's pretty standard practice to ask people to rebase
17:21:41 <ignatenkobrain> if PR can't be merged because of conflicts it's only author knows best how to resolve conflicts
17:21:49 <mhroncok> tibbs: how would you do it with wiki
17:21:49 <mhroncok> you take their chanegs
17:21:49 <mhroncok> and apply them
17:21:49 <mhroncok> so you take their commit
17:21:49 <mhroncok> and apply it
17:21:50 <mhroncok> tibbs: if it's too much git nonsense, just ping me with a PR link and I'll do that
17:22:10 <tibbs> Well, sure, I can just apply their changes manually.
17:22:16 <ignatenkobrain> or like mhroncok says
17:22:18 <mhroncok> you just apply the commit manually
17:22:25 <mhroncok> cherry-pick
17:22:36 <tibbs> ignatenkobrain: But what you say is right for code but wrong for packaging guidelines or most documentation.
17:22:41 <mhroncok> or you git pull origin refs/pull/<pr number here>/head
17:22:51 <tibbs> They aren't best placed to resolve conflicts, we are.
17:22:58 <tibbs> PR is really the wrong workflow here.
17:23:14 <mhroncok> why?
17:23:19 <redi> you mean we don't just keep editing the guidelines until they compile?  ;)
17:23:31 <tibbs> Exactly because we're not dealing with code.
17:23:47 <tibbs> This is a situation where git is the hammer, and we're pretending the guidelines are a nail.
17:24:21 <geppetto> redi: that's what I do :)
17:24:23 <tibbs> Maybe pagure is the hammer instead of git.
17:24:44 <geppetto> I'm not sure it'll be much different/worse with docs. than code.
17:24:50 <tibbs> After all, there are plenty of other completely valid git workflows besides the PR model.  It's just the only one we're offered because github popularized it.
17:25:15 <tibbs> The difference here is that the usual case was always for me to do some level of rewriting for every single guidelines change applied.
17:25:38 <redi> we use github for the C++ standard, that's documentation. 1500 pages of it. it works ok
17:25:50 <tibbs> I really don't expect everyone to have complete mastery of the terrible English grammar before submitting guideline changes.
17:25:51 <mhroncok> Pr model works for the docs just fine
17:26:09 <mhroncok> tibbs: that's fine, if you want to rewrite, you have basically 2 main options
17:26:27 <mhroncok> tibbs: 1) you look at their diff/tezt and you write (copypaste) your own
17:26:37 <tibbs> I mean, I just gave you quite reasonable examples of why it _doesn't_ work fine, and you ignore them and say it does.
17:26:40 <mhroncok> tibbs: 2) you apply their commit adn put an extra commit of yours on top of it
17:26:56 <tibbs> Obviously folks love git so much they don't care, but that doesn't change the reality.
17:27:20 <mhroncok> tibbs: I donẗ see any example why is this any worse than a link to wiki page and a wiki diff
17:27:27 <mhroncok> it has all the features of such + more
17:27:52 <tibbs> It has most of the features of such plus more.
17:28:10 <tibbs> I'm not arguing that it doesn't have advantages.  You just conveniently ignore the disadvantages.
17:28:12 <tibbs> That's fine.
17:28:26 <mhroncok> whta fature it doesn't have?
17:28:32 <mhroncok> the disadvantage I see is in how we convert the docs to html
17:28:42 <mhroncok> i.e. in the wiki, you just click preview and it works
17:29:00 <mhroncok> now you need container with random stuff to build it
17:29:09 <mhroncok> and that's bad, but it not a git disadvantage
17:29:20 <tibbs> Well, and wait a day before your changes are live, but that's not what I'm talking about either.
17:29:35 <tibbs> It means I have to merge and then pull and then edit and then commit and push.
17:29:43 <mhroncok> tibbs: now you don't
17:29:50 <mhroncok> you can pull, edit and push
17:29:59 <tibbs> And the PR closes automatically?
17:30:14 <ignatenkobrain> put Merges in commit msg
17:30:26 <mhroncok> tibbs: no idea, a wiki draft page also doesn't delete itself automatically
17:30:36 <mhroncok> but as ignatenkobrain says
17:30:43 <mhroncok> (not sure if it works in Pagure)
17:30:45 <ignatenkobrain> Merges: #123
17:30:52 <ignatenkobrain> this will close PR as merged
17:31:24 <pingou> ignatenkobrain++
17:31:25 <zodbot> pingou: Karma for ignatenkobrain changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:31:43 <tibbs> It's both more work and less work depending on the situation.
17:31:57 <tibbs> I certainly love it for quick fixes.  I don't like it nearly as much for big changes.
17:32:00 <mhroncok> TBH the main disadvantage of the PR workflow is that one needs to get used to it and learn the git stuff
17:32:14 <ignatenkobrain> anyway, I think we have more important stuff to discuss
17:32:16 <mhroncok> but i guess that is true for any change
17:32:18 <ignatenkobrain> geppetto: don't we?
17:32:57 <tibbs> You folks who live in git all day have internalized all of the absolutely bizarre bits about it.  I can just barely manage a merge with conflicts.
17:33:09 <geppetto> I mean … tibbs does most of the editing/pushing … so if people can give him pointers to how to work with git easie, I think it's worth a few minutes
17:33:11 <mhroncok> tibbs: and I take that
17:33:19 <mhroncok> tibbs: that's fine.
17:33:34 <tibbs> Anyway, we don't have to do this now.
17:33:43 <mhroncok> tibbs: but really to do this kind of work you don't need to know "all the bizzare stuff"
17:33:46 <tibbs> And I can certainly get any human who understands git to assist.
17:33:56 <geppetto> Ok
17:34:04 <ignatenkobrain> tibbs: just ask anytime if you are struggling with git and we will help
17:34:13 <mhroncok> tibbs: also ping me any time with a specific how to question
17:34:20 <mhroncok> ignatenkobrain++
17:34:20 <zodbot> mhroncok: Karma for ignatenkobrain changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:34:32 <tibbs> We really should move on, though.
17:34:39 <mhroncok> yes
17:34:44 <geppetto> #topic https://pagure.io/packaging-committee/pull-request/821
17:34:49 <geppetto> Talking of PRs :)
17:35:03 <geppetto> ignatenkobrain: Want to talk about it?
17:35:05 <ignatenkobrain> ;)
17:35:19 <ignatenkobrain> basically we need to do something with this PR
17:35:32 <ignatenkobrain> because author is asking for action and we do not do anything
17:35:48 <tibbs> Is there a good way to see more context in the diff view?
17:36:23 <mhroncok> tibbs: not trough pagure - you can see the diff you see or the entire new file
17:36:41 <ignatenkobrain> tibbs: I guess not with pagure, but there  is no more context, it's complete rewrite of file
17:37:14 <tibbs> It's slightly tough to see that from what pagure provides.
17:37:31 <tibbs> Obviously there are a lot of deletes but it's not clear if there's more that's not deleted.
17:37:54 <mhroncok> for that, I'd use the compelte file view
17:38:15 <tibbs> Yes, but then you have to switch back and forth between the master and branch views.
17:38:28 <tibbs> To see what it looked like before and what it looks like after.
17:38:47 <tibbs> It's merely a mild annoyance.
17:39:09 <mhroncok> a side by side entire file view wqould indeed be nice (cc pingou)
17:39:28 <tibbs> Very much yes.  I'm sure it's already a feature request.
17:39:29 <pingou> mhroncok: exists for commit not for pr atm
17:39:29 <mhroncok> (and here we are again talking about git and pagure)
17:40:05 <tibbs> As for the draft... I'm quote fine with it though those are some looooong lines.
17:40:11 <pingou> (so if there is only one commit in the PR I can should you the side by side)
17:40:30 <pingou> s/should/show/
17:40:37 <mhroncok> pingou: there is
17:40:46 <tibbs> Semantic line breaks would certainly be great but I can add them as part of the writeup.
17:40:48 <mhroncok> pingou: and even if I click the commit, I have no idea how to show that
17:41:03 <pingou> mhroncok: link?
17:41:07 <tibbs> https://pagure.io/fork/nmav/packaging-committee/c/5532e4aaae14c5785435b7c2ff9b2da37cbe1b87
17:41:21 <mhroncok> and https://pagure.io/packaging-committee/pull-request/821#commit_list
17:41:40 <mhroncok> tibbs: so do we vote on the content change?
17:41:49 <tibbs> I think so.
17:41:50 <pingou> mhroncok: https://pagure.io/fork/nmav/packaging-committee/c/5532e4aaae14c5785435b7c2ff9b2da37cbe1b87?splitview=True
17:42:08 <pingou> (yes it's a little bit of a hidden feature for now, until we can make it work better)
17:42:23 <tibbs> I am so happy I have 21:9 monitors.
17:42:47 <pingou> long-line--
17:42:48 <mhroncok> pingou++
17:42:48 <zodbot> mhroncok: Karma for pingou changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:42:57 <pingou> mkonecny: all ryanlerch :)
17:43:19 <mhroncok> +1 BTW
17:44:01 <geppetto> sure +1
17:45:25 <tibbs> +1
17:45:38 <tibbs> (to the draft, that is)
17:46:21 <ignatenkobrain> I would remove Guidelines from links and also add "SSL" into the page title
17:46:26 <ignatenkobrain> and use sembr
17:46:34 <ignatenkobrain> but apart from that I am voting +1
17:47:09 <decathorpe> I haven't read the draft, and I'm only on my phone. if you need my vote, I'll vote on the ticket when I'm at my PC - is that alright?
17:47:21 <tibbs> Certainly that's fine.
17:47:44 <tibbs> ignatenkobrain: What "Guidelines" would you remove?  I'm not seeing it.
17:47:58 <tibbs> Oh, you mean in the navbar.
17:48:09 <ignatenkobrain> yep
17:48:29 <tibbs> Yes, those I would ceratinly take out.  nav.adoc is why it doesn't merge anyway.
17:50:20 <tibbs> And I would obviously add some line breaks.
17:50:41 <mhroncok> +4, 0, -0 ?
17:50:41 <tibbs> I've started writing asciidoc stuff here at work so I'm much more familiar with it now.
17:50:53 <geppetto> I think it's fair to say people can add line breaks without more voting ;)
17:51:02 <geppetto> mhroncok: I think so
17:51:13 <mhroncok> at this smestr we went form wiki to asciidoc based materials by chance so I get more and more familiar with it as well
17:51:24 <mhroncok> *semester
17:52:03 <mhroncok> # info 821 is +4, 0, 0, decathorpe tio vote in the ticket
17:52:13 <mhroncok> #info 821 is +4, 0, 0, decathorpe to vote in the ticket
17:52:15 <geppetto> #chair
17:52:15 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mhroncok redi tibbs
17:52:30 <geppetto> mhroncok: redi can vote too
17:52:34 * mhroncok doesn't remember the line
17:52:43 <mhroncok> oh, sorry redi
17:53:37 <geppetto> #info PR/821 is +4, 0, 0, decathorpe/redi can vote in the ticket
17:53:52 <geppetto> maybe the bot died ?:-o
17:54:00 <geppetto> #topic Open Floor
17:54:04 <geppetto> I guess not
17:54:35 <geppetto> Oh, I don't think it responds to #info commands, just does them
17:54:40 <mhroncok> oh
17:54:54 <geppetto> Anyway … anything to discuss in the last few minutes?
17:54:58 <ignatenkobrain> I would like to ask you to look at other PRs, one is from nim and one from mhroncok
17:55:05 <ignatenkobrain> I meant not now but when you will have time
17:55:05 <ignatenkobrain> ;)
17:55:14 <nim> ignatenkobrain++
17:55:14 <zodbot> nim: Karma for ignatenkobrain changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:55:20 <tibbs> Well, an update on the tilde versioning thing.
17:55:35 <ignatenkobrain> oh yeah, tilde!
17:55:37 <mhroncok> ~~~~~~~
17:55:49 <tibbs> I put in more work but I still have another draft to write.
17:55:55 <tibbs> https://fedoraproject.org/wiki/User:Tibbs/TildeVersioning has explanation and notes.
17:56:02 <ignatenkobrain> tibbs > tibbs~tibbs
17:56:11 <tibbs> Just two important cases to consider.
17:56:21 <tibbs> One draft pretty much done unless I screwed it up.
17:56:26 <tibbs> Another draft still to write.
17:56:48 <tibbs> Basically everything I do uncovers some difficult case.
17:57:31 <tibbs> I have listed two cases which are not at all uncommon and tried to simply not worry about everything else.
17:57:59 <tibbs> Since people were complaining that I was throwing completely contrived cases up as something that a policy has to handle.
17:58:15 <tibbs> (Somehow releasing version "0.1" is contrived by some metrics, but...)
18:00:04 <mhroncok> Double tildes, oh
18:00:12 <tibbs> It was just a comment that it works.
18:00:18 <tibbs> Actually using it doesn't help.
18:00:28 <geppetto> ¯\_(ツ)_/¯
18:00:56 * geppetto nods
18:01:05 * ignatenkobrain nods too
18:01:06 <tibbs> Note that there are two primary issues here:  I'm trained as a mathematician and I have been doing this long enough to see all of these weird versioning cases.
18:01:35 <mhroncok> Allow tilde. Keep post-release snapshot information in Release:. Keep prerelease snapshot information in Version.
18:01:41 <mhroncok> this seems most reasonable
18:01:51 <tibbs> Yes, that is the first draft.
18:03:58 <tibbs> I can see that tilde is one of pair of "operators" you need to properly implement snapshots.  But we don't have its counterpart and I doubt we would ever get it.  (I haven't asked.)
18:04:29 <mhroncok> let's ask maybe?
18:04:30 <tibbs> We can live with it by continuing to cram stuff into Release: when necessary.
18:04:35 <ignatenkobrain> actually one day I proposed caret
18:04:45 <ignatenkobrain> 1.2^2018 < 1.2.1
18:04:59 <tibbs> Yes, that's the analog of what a complete implementation would need.
18:05:02 <ignatenkobrain> but I wasn't pushing very hard for it so it didn't made upstream
18:05:08 <tibbs> In the notes I called it '?'.
18:05:12 <ignatenkobrain> if you feel it's needed, I have branch with test cases
18:05:36 <mhroncok> §&[]{}!~@%...
18:05:37 <tibbs> Well it's needed for a scheme which keeps Release: pristine in all cases.
18:05:52 <tibbs> It's not needed in general, but then neither was tilde.
18:05:54 <ignatenkobrain> caret was only thin which wasn't looking that awful
18:06:03 <ignatenkobrain> and we discussed it with ffesti for long
18:06:23 <ignatenkobrain> then I will ask RPM upstream again about caret
18:06:48 <ignatenkobrain> https://github.com/rpm-software-management/rpm/pull/88
18:06:51 <tibbs> Yes, caret is perfectly fine.  It would take the place of the '+' in some of random exposition that exists in the ticket.
18:06:52 <ignatenkobrain> Sep 10 2016 ;)
18:06:56 <mhroncok> we can do draf1 one and maybe one day add caret or another whatnot
18:07:01 <mhroncok> but let's not block i on that
18:07:03 <tibbs> Obviously '+' isn't something we could use.
18:07:05 <ignatenkobrain> > OK, looks like Fedora is going for a policy that works with the current version compare. If version and release strings are chosen with some care (which they have to be anyway) I do not really see an immediate need for this. Closing for now.
18:07:27 <tibbs> Interesting.
18:07:31 <ignatenkobrain> I implemented the code and also put test-cases
18:07:33 <ignatenkobrain> Please comment on that PR
18:07:44 <tibbs> I don't think we were "going for" anything in particular.
18:08:04 <ignatenkobrain> if it's matter of getting this to simplify things, I'm ready to work on it in upstream
18:08:23 <ignatenkobrain> but the patch exists and it's not very hard to get it into upstream
18:08:27 <tibbs> Well, sure but as usual the problem is EPEL.
18:08:30 <ignatenkobrain> it just needs rationale from Fedora
18:08:36 <mhroncok> EPEL is always the problem
18:08:40 <ignatenkobrain> tibbs: ffesti backported tilde to RHEL6 at some point
18:08:41 <tibbs> That said, tilde was backported.
18:08:53 <ignatenkobrain> if we make it work and used in Fedora, we can ask him to backport caret
18:08:55 <tibbs> it was backported specifically so that Fedora could start using tilde.
18:09:14 <tibbs> I recall a statement to that effect, and that our refusal to take up tilde meant that the work was wasted.
18:09:24 <tibbs> But again, this is not really needed.
18:09:33 <mhroncok> but it would be nice
18:09:33 <tibbs> It would just make things simpler.
18:09:43 <mhroncok> and a nice explanation why might help us get it
18:09:57 <ignatenkobrain> then please, put your opinion in that PR to upstream RPM
18:09:58 <ignatenkobrain> and I will revamp it
18:10:11 <tibbs> I will proceed to fine tune the existing draft and implement the second one.  And if this caret thing happens then we can be prepared for it.
18:10:38 <ignatenkobrain> to caret to happen I need your words to be heard by RPM folks ;)
18:10:43 <ignatenkobrain> not the other way around
18:10:54 <tibbs> I'm typing.
18:11:02 <ignatenkobrain> cool =)
18:11:07 <tibbs> In that PR.  So I'll add as much info as I can.
18:11:28 <mhroncok> tibbs: thanks
18:11:44 <ignatenkobrain> tibbs++
18:11:44 <zodbot> ignatenkobrain: Karma for tibbs changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:11:55 <tibbs> If I had that, the guidelines would be much simpler.
18:12:24 <tibbs> Another question related to tilde
18:12:31 <mhroncok> and we would ahve both: tilde + simpler guidelines
18:13:30 <tibbs> What do people think of this sequence: (1.2~beta1-1, 1.2~20180101.abcde-1, 1.2~3.beta2-1 ???, 1.2~4.20180102.fghij-1, 1.2-1)
18:13:49 <tibbs> Or basically even ignore the first element there.
18:14:25 <mhroncok> data, beta, date, beta
18:14:27 <tibbs> Basically if you're doing prerelease snapshots and upstream never tags a beta or anything, you just have 1.2~date.whatever, 1.2~nextdate.whatever.  It looks nice.
18:14:32 <mhroncok> well, double tildes? :D
18:14:46 <tibbs> But if they tag a beta, then you have to have 1.2~3.beta (for at least the next 982 years).
18:15:05 <tibbs> It just seems hard to describe why you have to put a 3 there.
18:15:23 <tibbs> But in the case where you never package a beta, it looks quite nice.
18:15:40 <ignatenkobrain> tbh what I would do is
18:15:41 <tibbs> Alternately, if we drop the date then there's never any confusion because you always have to have a digit.
18:15:42 <mhroncok> wait, the thing after tilde sort lexicographically?
18:15:51 <tibbs> mhroncok: Yes.
18:15:52 <ignatenkobrain> 1.2~beta1+20180101.abcde
18:16:02 <tibbs> mhroncok: And evem multiple tildes.
18:16:03 <ignatenkobrain> or directly go to 1.2~beta2~20180101.abcde
18:16:13 <tibbs> ignatenkobrain: That's the post-prerelease thing, which is even harder to explain.
18:16:16 <ignatenkobrain> because you are NOT swapping beta to git snapshot
18:16:29 <ignatenkobrain> you are basically getting commit on top of beta
18:16:36 <ignatenkobrain> or before next beta
18:16:39 <tibbs> ignatenkobrain: And you can't know that the next prerelease will be called beta2 unless upstream has told you so.
18:16:45 <ignatenkobrain> it's not something that you take random commit and insert after beta release
18:16:47 <mhroncok> why should just allow anyhting in there and bump epoch with every rebuild :D
18:16:56 <ignatenkobrain> then you use ~beta1+20180101
18:17:04 <ignatenkobrain> because you don't know what next release will be
18:17:13 <ignatenkobrain> but you know that you are basing it on beta1 + some commits
18:17:53 <tibbs> I have intentionally tried to avoid post-prerelease and pre-prerelease snapshots.
18:18:09 <tibbs> Because actually describing those seems more confusing than useful.
18:18:30 <tibbs> Now, if we used the git describe method, it would sort of fall out.
18:18:46 <ignatenkobrain> tbh, I would go with git describe method
18:18:49 <tibbs> That's what Suse does and it makes sense if you understand what git describe does.
18:19:30 <tibbs> Of course, it's dependent on git.
18:20:01 <tibbs> And it requires that upstream actually tags their prereleases, and uses the same naming for the tag as what they actually call the release.
18:20:17 <tibbs> Which seems too much to assume.
18:20:22 <tibbs> Anyway, we're way over here.
18:20:33 * geppetto nods
18:20:53 <tibbs> The problem is that so many of these things weren't really all tied together and could be considered separately.
18:21:00 <geppetto> Anyway … we are 20 minutes over … should we end now or need to talk about tilda more?
18:21:00 * geppetto nods
18:21:05 <tibbs> But by introducing tilde they all some in together.
18:21:08 <nim> tibbs, it's much too much to assume I confirm
18:21:11 <tibbs> I will keep writing drafts.
18:21:36 <tibbs> Every scheme that someone wants or suggests seems to work great with one set of upstreams.
18:21:55 <tibbs> And just fails badly with the poorly behaved ones.
18:22:08 <tibbs> But there are so many of the latter category.
18:22:15 <geppetto> :(
18:22:18 <nim> tibbs, you want something everyone will accept you need git upstream to implement it
18:22:32 <nim> tibbs, good luck with that
18:22:33 <geppetto> Anyway …
18:22:34 <geppetto> #endmeeting