Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* amccarty joins04:06
* amccarty leaves04:11
* amccarty joins05:55
* amccarty leaves05:59
* amccarty joins06:55
* amccarty leaves07:00
* manez joins08:31
* dhlamb joins08:47
* whikloj joins09:04
* ajs6f joins09:05
* mjgiarlo joins09:10
<ajs6f>Interesting: https://help.github.com/articles/about-pull-request-reviews/09:13
<ruebot>ajs6f: was just reading that09:16
* acoburn joins09:18
* amccarty joins
<ruebot>ajs6f: GH profiles changed last night too
* mjgiarlo leaves09:19
* apb18 joins09:20
* dchandekstark joins09:21
* mjgiarlo joins09:22
* mikeAtUVa joins
* sosuke01 joins09:26
* coblej joins09:27
* tolloid joins09:36
* peichman joins09:44
* acoburn leaves09:53
* github-ff joins09:55
[fcrepo-camel] awoods pushed 1 new commit to master: https://git.io/viole
fcrepo-camel/master fc4ca74 Aaron Coburn: Remove deprecated options: transform and tombstone (#122)...
* github-ff leaves
* bseeger joins09:57
* amccarty leaves09:59
* sosuke01 leaves10:00
* tolloid leaves10:01
* travis-ci joins10:02
fcrepo4-exts/fcrepo-camel#288 (master - fc4ca74 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/4c90f9915b0e...fc4ca748228e
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/160172156
* travis-ci leaves
* osmandin joins
* coblej leaves10:13
* github-ff joins10:14
[fcrepo-camel] awoods pushed 1 new commit to master: https://git.io/vioBd
fcrepo-camel/master 0a3ce97 Aaron Coburn: decouple testing environment from fedora version (#123)...
* github-ff leaves
* travis-ci joins10:21
fcrepo4-exts/fcrepo-camel#289 (master - 0a3ce97 : Aaron Coburn): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/fc4ca748228e...0a3ce97733db
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/160178290
* travis-ci leaves
* coblej joins10:22
* coblej leaves10:27
* coblej joins10:29
* coblej leaves10:33
* coblej joins10:35
* coblej leaves10:40
* coblej joins10:41
* coblej leaves10:43
* coblej joins
* amccarty joins10:44
* amccarty leaves10:46
* amccarty joins
* jenlindner joins10:50
* jenlindner leaves10:57
* jenlindner joins
* MarcusBarnes joins10:58
<awoods>https://wiki.duraspace.org/display/FF/2016-09-15+-+Fedora+Tech+Meeting11:00
<bseeger>*is here*
* apb18 here
* ruebot is here11:01
* coblej is here
* mikeAtUVa just arrived
* whikloj is also here
* acoburn joins
*is here*11:02
* jackhill is here
* escowles_ is here
* dchandekstark leaves11:03
* ylchen joins
<amccarty>a handfull of us from Cornell are here - audio stinks on our end..
* dchandekstark joins
<mikeAtUVa>brb
<awoods>https://wiki.duraspace.org/display/FF/2016-09-15+-+Fedora+Tech+Meeting11:04
<ruebot>awoods: is awagner here for notes?
* mikeAtUVa is back... did I get drafted to take notes while I was out?
<jenlindner>lol
<ruebot>mikeAtUVa++11:05
* dwilcox joins
<ruebot>mikeAtUVa++11:10
"Support lossless round-tripping. (ie, if you export a resource, delete that resource and import there is no difference from if you had never performed any of those operations)."11:13
* ajs6f just joined11:16
<bseeger>ajs6f: talking about gradle in fcrepo-exts
<ajs6f>That's Grade. I mean great.
<dhlamb>whikloj: good point11:19
<ajs6f>+1 to escowles11:20
* grosscol joins
<whikloj>escowles++11:21
<ajs6f>They've all got their good sides and bad sides.
<grosscol>Okay. I have a kind of peculiar problem I'm trying to sort out what information to collect to get for a bug report.
<escowles>grosscol: the full stack trace and how to reproduce it are the main things11:22
<grosscol>On the problem server, I have some of it: https://gist.github.com/grosscol/48d0aba4dd273b9f2d16a74a7e548950
<ajs6f>grosscol: Are you using Hydra to do this?
<grosscol>I load the same backup fcrepo and deploy the same application to three servers: local, staging, and production.
And it only fails on the production server.11:23
Yeah.
<ajs6f>grosscol: If so, you may wish to start by contacting Hydra.
<ruebot>Like this? https://github.com/Islandora-CLAW/Alpaca/#building
<ajs6f>grosscol; the first thing to do is determine whether the problem is with Hydra or Fedora.
<grosscol>The last comment I have is the one that I led me to come here.
<escowles>ajs6f: i think we can say that if fedora is returning 500 and dumping a stacktrace, there's *some* fedora aspect to this bug11:24
<grosscol>Also, it works in 2/3 of the places I've tried.
<ajs6f>escowles: You can say that. I don't expect much more than that to begin with,
<grosscol>I've gotta run to a meeting. Damn. Be back in a bit.11:25
<ajs6f>gradle on
<grosscol>The last one where the fedora communication shows PATCH call for fcr:metadata comes from the first call to file_set.original_file.save from Hydra-land
<whikloj>ajs6f: rock the gradle of love
<ruebot>whikloj++11:26
whikloj++
whikloj++
<grosscol>The a second call to file_set.original_file.save from hydra-land causes the error. I can only figure that fcr:metadata is getting mangled on this one instance. So I'm betting on config.... somewhere.
<ajs6f>I don't remember why, now.
And it doesn't seem important.
whikloj++11:27
We need a Billy Idol easte egg.
<whikloj>ajs6f++
<ruebot>awoods: pitch for next perf/scale meeting on sept 26? :-)11:32
<ajs6f>Yup. I've put _everything_ on hold until alt impls.11:33
<apb18>acoburn: just out of curiosity, is modeshape5 equally as bad with regard to running in OSGi?
<acoburn>apb18: I haven't tried MODE511:34
apb18: there was a lot of complexity w/ ISPN, so I'd expect MODE5 would be easier
<ajs6f>+1 to channeling our focusing11:35
<ruebot>whikloj++11:36
<whikloj>So it wasn't a dream
<bseeger>whikloj++
<ajs6f>whikloj++ # I'm sniggering like the Joker
They're fine.11:37
<apb18>acoburn: Ah, I see. Not that I have any specific knowledge of mode5 and OSGi...11:38
<ajs6f>It was a nightmare.
<ruebot>whikloj: if i'm not too busy with import/export sprint, i can lend a hand too.11:40
<ajs6f>I will help, but only because I like whikloj and don't want to see him end up like a character in a Lovecraft story who sees the face of Cthlulu.
<ruebot>ajs6f++
<ajs6f>You'll be doing a lot of that.11:41
<dhlamb>lol
<awoods>https://jira.duraspace.org/browse/FCREPO-208611:42
<ajs6f>Get it out a fat as possible.11:43
fast
Also fat. Or at least phat.
<ruebot>whikloj: https://groups.google.com/forum/#!searchin/fedora-tech/code$20freeze%7Csort:relevance/fedora-tech/DQGH2cR5Crc/qxg8H2QmBQAJ11:46
<whikloj>ruebot++
<ajs6f>Hahahhaha
<ruebot>whikloj, ajs6f: just send this out http://i.imgur.com/VioL4ST.png11:48
<ajs6f>I want those slippers.11:49
We just workshoppped the hell out of that assumption.11:53
<apb18>maybe TCK sprint(s) at some point in the future, once individual spec(s) seem finalized enough?11:55
<ajs6f>maybe TCK and impl at the same time.
<jackhill>apb18++11:56
<escowles>gotta head out for another meeting...11:57
<ajs6f>TCKs are definitely not sexy.
* mikeAtUVa agrees that the TCK should come before the changes to our codebase.
<ajs6f>TCK tells us what the changes to code should be.
<mikeAtUVa>the TCK will outlive our use of modeshape and will make the changes to the community implementation easier to validate.11:58
The TCK will also unearth ambiguity in the spec.
<ajs6f>We Are Reasonable People
Doing TCKs also gives us more opportunities to argue about build manager software.11:59
ruebot++12:00
<ruebot>https://wiki.duraspace.org/display/FF/Design+-+Import+-+Export
* dchandekstark leaves12:01
<ajs6f>I'll be there.12:02
* apb18 will be off the line
* acoburn leaves
<MarcusBarnes>Thank you.
* dchandekstark joins
* MarcusBarnes leaves
<mikeAtUVa>awoods: I saved the minutes to the wiki.
<ajs6f>Ah, there's that sweet FreeConfCall hold music again. Love that stuff...12:03
<awoods>thanks, mikeAtUVa
* amccarty leaves
* amccarty joins
* jenlindner leaves12:04
<ylchen>ruebot: will the bagit support export from a fedora and import to LOCKSS? We saw that page, but not sure what is the actual scenario to use this export bagit.12:05
ruebot12:06
* dchandekstark leaves
* amccarty_ joins12:07
* amccarty leaves
* dwilcox leaves12:08
* dwilcox_ joins
* dchandekstark joins
<ruebot>ylchen: yep. we'll be sketching that out in more detail next week with the stakeholders who will be at the penn state sprint. if you want to join remotely, we can try and make that happen.12:09
* coblej leaves12:12
* bseeger leaves
* coblej joins
* dchandekstark leaves12:13
* dchandekstark joins12:15
* coblej leaves12:17
* mjgiarlo leaves12:18
* dchandekstark leaves12:19
* mjgiarlo joins12:34
* mjgiarlo leaves12:38
* manez leaves12:40
* manez joins12:42
<awoods>mikeAtUVa: are you still editing the tech minutes wiki page?12:48
* bseeger joins12:53
* bseeger leaves12:54
<whikloj>ajs6f: Do we still create a DEV branch for releases?13:02
or awoods ^^
<awoods>whikloj: no
whikloj: but we do create an RC branch13:03
<whikloj>awoods: yes, just going over the Release Process...needs editing I am guessing
<ajs6f>whikloj: We create an RC branch and all release activity goes on there. master just keeps rolling.
<whikloj>ajs6f/awoods: So no issue if I remove mentions of development branches from https://wiki.duraspace.org/display/FF/Fedora+Release+Process ??13:04
* ddavis joins
<ajs6f>whikloj: please do.13:05
* dwilcox_ leaves
<awoods>whikloj: go for it
<whikloj>ajs6f/awoods: So do we still push the RC branch to master? Or do we apply patches to both the RC branch and master as they come in?13:06
s/patches/PRs/
<ajs6f>whikloj: the latter.
<awoods>whikloj: no merging back to master.
<ajs6f>whikloj: So post code freeze until the release, you will have to accept two prs for some tix13:07
* bseeger joins
<awoods>whikloj: as a note, master and the rc branches can not have the same maven version13:09
<whikloj>awoods: So I need to increment master after creating my RC branches?13:10
<awoods>whikloj: or before, yes
whikloj: to 4.7.1-SNAPSHOT
<whikloj>awoods: okay the RC remains at the 4.7.0-SNAPSHOT13:11
<awoods>whikloj: yes
<mikeAtUVa>awoods: no, not intentionally.13:12
<awoods>mikeAtUVa: np, I updated the attendee list13:13
<ddavis>They said Pax exam had little gremlins. I wonder if they are the ones hammering on a bomb in Bugs Bunny or the really bad cars built by AMC way back?
* coblej joins13:14
<ylchen>ruebot: that's great. Thank you!
<ruebot>ylchen: cool. just ping me early next week if you want to be apart of those conversations.
<ylchen>ruebot: will do.13:15
<ruebot>ylchen++
* coblej leaves13:20
* coblej joins13:24
* coblej leaves13:28
* coblej joins13:30
* bseeger leaves13:31
<ylchen>Anyone will go to Hydra Connet 16?13:32
* mjgiarlo joins13:34
* dwilcox joins
* coblej leaves13:35
<whikloj>ajs6f: do we have a policy on how the incrementing of version should happen, I see acoburn did a PR for fcrepo4 and you merged. Is a solo process allowed?13:36
* osmandin_afk leaves13:39
<awoods>whikloj: http://www.mojohaus.org/versions-maven-plugin/examples/set.html
<whikloj>awoods: sorry the question was more... is it allowed if I make the changes to my branch and push it to master. Or should there be a PR to make that change?13:40
<awoods>whikloj: a PR, please.13:41
* bseeger joins13:43
<whikloj>awoods/ajs6f: Review when you have time, please. https://wiki.duraspace.org/pages/diffpagesbyversion.action?pageId=41354571&selectedPageVersions=93&selectedPageVersions=9213:49
<ajs6f>whikloj: The general rule is "never merge your own commit:13:53
whikloj: and tho it is sometimes annoying, it is a good thing
whikloj: e.g. in Apache Jena people merge their own stuff and becuse it is a globally distributed team, there isn't much opportunity for low-level code review.13:54
<whikloj>ajs6f: ok, just clarifying the need for a second participant in the release candidate process.
<ajs6f>whikloj: https://duckduckgo.com/?q=hov+dummy&iax=1&ia=images
whikloj: any of those should work13:55
* ylchen leaves
<awoods>whikloj: your wiki updates look good. Could you also include the commands (when you have them) for updating the version number in master?13:56
<whikloj>awoods: using that maven plugin?13:57
<awoods>whikloj: that would be my expectation13:58
* bseeger leaves14:15
* dchandekstark joins14:16
* dchandekstark leaves14:20
* dchandekstark joins14:24
* dchandekstark leaves14:25
* dchandekstark joins
* coblej joins14:32
* coblej leaves14:38
* dwilcox leaves
* bseeger joins14:41
* tolloid joins14:48
* amccarty_ leaves
* amccarty joins14:49
* tolloid leaves14:50
* amccarty leaves
* amccarty joins14:51
<whikloj>Need a little context, we upgraded Jena right? To version 3?
* coblej joins14:57
* coblej leaves14:58
<grosscol>Okay. Back with you all. Still totally stymied by this particular 500 response15:07
I think I've gotten it down to a minimal example.
https://gist.github.com/grosscol/640f84300dadbea59304766c949cd2d2
What other information would be useful to have in order to make this a tractable error or bug?15:08
I'm having a problem that with the exact same fcrepo backup, I can't reproduce this locally. It's only happening on the production machine.
<whikloj>grosscol: I can't speak for anyone else, but knowing what the contents of that PATCH request are would help me.15:10
<grosscol>Okay. I'll see if I can track down how to log that.15:11
<whikloj>grosscol++15:12
* manez leaves15:22
* manez joins15:24
<grosscol>whikloj, I still haven't sorted a decent way to get the contents of that patch request yet, however, I did run the same commands on staging. I updated the gist with a comment.15:28
On the staging machine, the patch request doesn't generate warnings, and nothing explodes. Going to diff the application directories and make sure nothing is different.15:29
Just to be sure.
<bseeger>grosscol: one thing to check on that one server is that the name spaces in the fedora server are setup correctly. It seems like that might be the difference here.
<whikloj>bseeger++15:30
<grosscol>Oooo.... what tips you off to that, and where is that configured?
<bseeger>grosscol: this happens when fedora can't find the namespaces in it's namespace list: https://gist.github.com/grosscol/640f84300dadbea59304766c949cd2d2#file-tomcat-log-L2415:32
grosscol: not sure of how to best configure those -
<grosscol>So in the request head ns01 is not resolving to the expected URI like dublin core or whatever.15:33
Okay. So the ns01 might not be mapped to the expected namespace on the troublesome server.15:34
<whikloj>grosscol: you might want to expand the prefixes to their full urls, or (and I think bseeger has a tool for this) you setup the mapping of prefix to namespace before you start importing15:35
<grosscol>because they're all stored internally like ns01, ns02 ...., yes?15:36
<bseeger>whiklog, grosscol: acoburn wrote a tool - I'll see if I can find it
whikloj, grosscol: https://github.com/fcrepo4-labs/fcrepo-namespace-util15:38
<whikloj>bseeger++
<bseeger>grosscol: you can use that tool to examine the namespaces in fedora - you need to stop the fedora server first though. If you can't do that then I don't recommend using this tool and I don't think you'll even be able to.15:39
grosscol: but you can, as you probably already know, see the namespaces in the fedora http page.15:40
<grosscol>Thanks. I've been banging my head against this for 30 hours now.
I'll see where this new avenue of investigation goes tomorrow.15:41
<bseeger>grosscol: good luck with it
<grosscol>bseeger, whikloj You are... how they say... the best.
<whikloj>grosscol++15:43
bseeger++
* grosscol leaves15:44
* amccarty leaves16:00
* amccarty joins16:11
* amccarty_ joins16:12
* amccarty leaves
* github-ff joins16:22
[fcrepo-import-export] mikedurbin opened pull request #34: Fixed basic import. (master...FCREPO-2215) https://git.io/viK8R
* github-ff leaves
* mjgiarlo leaves16:24
* acoburn joins16:40
whikloj: awoods: after the 4.7.0 RC goes out, wouldn't master be on 4.8.0-SNAPSHOT?
<whikloj>acoburn: not sure16:41
* bseeger leaves16:42
<whikloj>acoburn: what if we decide to do a 4.7.1 patch release? Does the fact that it is being developed as 4.8.0-SNAPSHOT matter?16:43
<ajs6f>whikloj: That would come off of the 4.7-maintainance branch
whikloj: After the release, the RC branch turns into the maintainence branch for that releae.
<whikloj>ajs6f: and we maintain that forever? or until the next major release?
sorry I clearly missed some information16:44
<ajs6f>whikloj: we leave that about forever. It's just a branch.
whikoj: it is what we would use if we ever need to make a special bugfix release for an older release.
<whikloj>ajs6f/acoburn/awoods: ok then I think 4.8.0-SNAPSHOT makes sense16:45
<ajs6f>whikloj: Like when they discover our Billy Idol fixation and we are trying to cover our tracks.
<whikloj>ajs6f: NEVER!!!!
<ajs6f>whikloj: Yes, 4.8 makes sense.
<whikloj>acoburn++
<awoods>acoburn/whikloj: I think our model is slightly different...16:47
acoburn/whikloj: are you suggesting that we continue to post commits to two branches forever?
acoburn/whikloj: I was thinking that each release would have its own maintenance branch... not just each major release.16:48
* dhlamb leaves
<acoburn>awoods: no, only major releases have maintenance branches
<awoods>acoburn/whikloj: therefore, my suggestion to change master to 4.7.1-SNAPSHOT
acoburn: sure...16:49
acoburn: rather release branches.
<whikloj>awoods: only commits to the maintenance branch for bugs fixes we are back-porting
<acoburn>awoods: here's what I've seen w/ other projects:
awoods: we currently have a 4.6-maintenance branch16:50
awoods: a 4.6.1 release would come from that branch
<awoods>acoburn: we talked about this a month ago, no?
<acoburn>awoods: yes
<awoods>acoburn: and went through all of this, and landed on 4.7.1-SNAPSHOT in master
acoburn: in any case...16:51
acoburn: are you suggesting we submit all commits to both the 4.7.0 branch and master?
<acoburn>awoods: my main concern is that if you have breaking changes in master it shouldn't have 4.7.x in the snapshot version
that is, if 4.7.x is the current release, and master has breaking changes, then master should be 4.8.0-SNAPSHOT16:52
but you may not know in advance that you'll have breaking changes
<whikloj>acoburn: So unless we know what the next release will be we opt for a major release number?
<acoburn>so just start with that assumption
<whikloj>got it
<ajs6f>acoburn++16:53
<acoburn>then, if you have a 4.7.1 release, but master has no breaking changes, you just use master
when maven asks you for a version number, you set it to 4.7.1
and the next "dev iteration" is back to 4.8.0-SNAPSHOT
<awoods>acoburn: regardless of whether master is set to 4.7.1-SNAPSHOT, or 4.8.0-SNAPSHOT or 9.9.9-SNAPSHOT, if you have breaking changes, you can release as 4.8.0
<acoburn>awoods: yes
<ajs6f>awoods: You can, but this is about what our assumptions are. What is the pattern?
awoods: The clear pattern is major releases.16:54
<acoburn>awoods: the issue is that a number of people (apb18 was one of them) found it confusing that our current master was on 4.5.2-SNAPSHOT when we were releasing for 4.6.0
<ajs6f>I actually publicly told people that we would fix that.16:55
<acoburn>awoods: I find that (previous) situation confusing, too, which is why I proposed this change
<ajs6f>Surely awoods can't be suggesting that we LET THE CHILDREN DOWN??!?
<awoods>acoburn: It is true that the next release after 4.7.0 may be 4.7.1, correct?16:56
<acoburn>awoods: I would expect that it would be
* manez leaves
<whikloj>So if we have a breaking change, then we have to backport all commits since 4.7.0 to 4.7.1?
that are non-breaking
<awoods>acoburn: and we would release that off of which branch: master or the 4.7.0 branch?
<acoburn>awoods: it depends — if we have breaking (4.8.x) changes in master, then we would need to selectively backport them16:57
awoods: if we don't, then we just release master as 4.7.1
awoods: to tell you the truth, though, until we have a TCK and an independently versioned API (i.e. fcrepo-kernel-api), I don't really care that much about version policies16:58
<awoods>acoburn: If we have breaking changes in master, then the release would be 4.8.0... or are we committing LTS of 4.7.0?
<acoburn>awoods: if there are breaking changes, then the next version would be 4.8.016:59
awoods: we've already discussed that we can't realistically discuss LTS without a formalized specification
awoods: we can only commit to a "review on a case-by-case basis"
<awoods>acoburn: My main concern right now is not having to push commits to two branches post-4.7.0 release.17:00
<ajs6f>acoburn:awoods: Spec or not spec, we aren't staffed or resourced to LTS anything.
* dchandekstark leaves
<acoburn>ajs6f: I completely agree
<ajs6f>acoburn:awoods: Our LTS policy amounts to barmintor's good will.
<barmintor>brb changing my name
* dchandekstark joins17:01
* barmintor enters witness protection
<ajs6f>barmintor => barmonster
* barmintor is a python programmer now, only talk to me about geo-encoding
<awoods>acoburn: as long as we are open to releasing 4.7.1 off of master, even if the dev version of master is 4.8.0-SNAPSHOT, I'm fine with that.
<ajs6f>Or the British version, barminster, broadcast in colour.
* mikeAtUVa leaves
<acoburn>awoods: that's what most other JAVA projects do
* ajs6f leaves17:02
<awoods>acoburn: really?
<acoburn>awoods: i.e. release a 4.7.1 version off of a 4.8.0-SNAPSHOT
<awoods>acoburn: I would expect that most other JAVA projects bump master to the next major version: 5.0.0-SNAPSHOT
<acoburn>https://github.com/apache/marmotta/blob/develop/pom.xml#L24
https://github.com/apache/camel/blob/master/pom.xml#L2917:03
https://github.com/apache/activemq/blob/master/pom.xml#L28
awoods: shall I continue?
awoods: all of these (plus many others) have the current snapshot to be 1 major release ahead of the current released version17:04
<awoods>acoburn: clearly your examples are not the pattern you are proposing...
* peichman leaves
<acoburn>awoods: they are exactly the pattern I am proposing
<awoods>acoburn: major.minor.poing
acoburn: major.minor.point
* dchandekstark leaves
<awoods>acoburn: Fedora is wacky because we have 4.major.minor/point17:05
<acoburn>awoods: I mean 1 minor release ahead of the current snapshot
<awoods>acoburn: exactly
<acoburn>awoods: Fedora terminology confuses me (something.major.point)
<awoods>acoburn: and our minor place is the third value
* apb18 leaves17:06
<acoburn>awoods: how about this: once we actually start using semantic versioning, I'll make this suggestion again. until then, do whatever you'd like
* acoburn leaves17:07
* amccarty_ leaves17:10
<awoods>whikloj: that did not exactly get resolved.17:11
<whikloj>awoods: lol17:14
<awoods>whikloj: I think the point is that we do not want to be having to maintain commits in two branches going forward.17:18
whikloj: whether we name the master version 4.7.1-SNAPSHOT or 4.8.0-SNAPSHOT is immaterial
<whikloj>awoods: well and I think the point is we won't. This really only becomes an issue if we have a breaking change
awoods: true17:19
<awoods>whikloj: the next release will come off of master, and it will be released as 4.7.1 or 4.8.0, as appropriate.
* youn joins17:20
<whikloj>awoods: yes
awoods: that is my understanding, unless we were to add a backwards breaking change
<awoods>whikloj: then what?
<whikloj>awoods: Which we would probably do a point release before anyways
* sosuke01 joins17:21
<awoods>whikloj: or we would just straight to 4.8.0, no?
<whikloj>awoods: that would be a decision for the community.17:22
awoods: I think our distinct semantic versioning makes it harder for people to anticipate what comes next
<awoods>whikloj: likely.
<whikloj>awoods: anyways, I think the issue becomes if we find a bug that we want to backport "after" we merge a breaking change.17:23
<awoods>whikloj: yes, then we backport it to the 4.7.0 branch.17:24
<whikloj>awoods: so would we just cherry pick that single fix, or would we use master _before_ the breaking change + the bug fix?
<awoods>whikloj: either way would work17:25
<whikloj>awoods: So (IMHO) the numbering is less important than the process...to be consistent
<awoods>whikloj: agreed17:26
* nicholas_ leaves17:27
<awoods>whikloj: Since it sounded like more people were wanting 4.8.0-SNAPSHOT in master, that works for me. I think we are straight on the principle.
<whikloj>awoods: sounds like a plan
<awoods>whikloj: thanks for sticking it out ;)17:28
<whikloj>awoods: What I lack in development skill, I make up for with dogged determination
<awoods>whikloj: that is why we love you17:29
<whikloj>lol
* manez joins17:34
* dchandekstark joins17:35
* manez leaves17:39
* dchandekstark leaves
* dchandekstark joins17:40
* youn leaves17:41
* dchandekstark leaves17:42
* chadmills joins17:43
* tpendragon leaves17:45
* cmmills leaves17:47
* tpendragon joins17:58
* dchandekstark joins18:02
* ddavis leaves18:03
* whikloj leaves18:05
* dchandekstark leaves18:07
* youn joins18:46
* youn leaves19:02
* dchandekstark joins19:04
* dchandekstark leaves19:11
* amccarty joins19:33
* youn joins20:01
* sosuke01 leaves20:09
* apb18 joins20:29
* escowles leaves20:41
* escowles_ joins
* apb18 leaves20:43
* escowles_ leaves20:44
* youn leaves20:46
* escowles joins21:04
* escowles leaves21:06
* escowles joins
* dchandekstark joins21:07
* dchandekstark leaves21:12
* apb18 joins
* dchandekstark joins21:25
* dhlamb joins21:35
* apb18 leaves21:39
* dchandekstark leaves22:09
* dchandekstark joins22:12
* dchandekstark leaves22:56
* dchandekstark joins23:01
* dchandekstark leaves23:38
* dchandekstark joins23:40
* dchandekstark leaves
* dhlamb leaves23:55
* amccarty leaves
* escowles leaves00:11
* dchandekstark joins00:40
* dchandekstark leaves00:45
* amccarty joins01:06
* amccarty leaves01:10
* escowles joins01:16
* dchandekstark joins01:42
* dchandekstark leaves01:46
* dchandekstark joins02:43
* dchandekstark leaves02:48