Displaying #traffic-server/2015-12-02.log:

Wed Dec 2 00:19:20 2015  ibrezac:Joined the channel
Wed Dec 2 00:25:46 2015  maskit:Joined the channel
Wed Dec 2 00:59:14 2015  psp:Joined the channel
Wed Dec 2 01:33:30 2015  swoc:Joined the channel
Wed Dec 2 01:35:37 2015  yamc:Joined the channel
Wed Dec 2 02:25:10 2015  psp:Joined the channel
Wed Dec 2 02:36:43 2015  psp:Joined the channel
Wed Dec 2 03:03:59 2015  ibrezac:Joined the channel
Wed Dec 2 04:36:41 2015  reveller:Joined the channel
Wed Dec 2 05:02:31 2015  _klk_:Joined the channel
Wed Dec 2 05:07:20 2015  jpeach:hey zwoop
Wed Dec 2 05:07:26 2015  jpeach:briang
Wed Dec 2 05:08:45 2015  jpeach:Humbedooh?
Wed Dec 2 05:20:09 2015  briang:hi jpeach
Wed Dec 2 05:20:12 2015  briang:want me to land 324?
Wed Dec 2 05:23:01 2015  jpeach:no, it needs some edits
Wed Dec 2 05:24:06 2015  jpeach:I'm having second thoughts as well because the libtool manual claims this is handled
Wed Dec 2 05:25:16 2015  jpeach:though maybe it means that it handles it if you use .la files
Wed Dec 2 05:39:21 2015  masaori:Joined the channel
Wed Dec 2 05:40:16 2015  briang:@jpeach okay please comment on the ticket.
Wed Dec 2 05:50:54 2015  jpeach:briang: ok thank
Wed Dec 2 06:06:44 2015  masaori:Joined the channel
Wed Dec 2 06:33:43 2015  psp:Joined the channel
Wed Dec 2 06:35:33 2015  psp1:Joined the channel
Wed Dec 2 06:38:24 2015  _klk_:Joined the channel
Wed Dec 2 06:53:50 2015  psp:Joined the channel
Wed Dec 2 06:57:08 2015  psp1:Joined the channel
Wed Dec 2 07:06:56 2015  psp:Joined the channel
Wed Dec 2 08:05:14 2015  lrea:Joined the channel
Wed Dec 2 09:03:58 2015  Lethalman:Joined the channel
Wed Dec 2 09:30:35 2015  akotani:Joined the channel
Wed Dec 2 09:32:05 2015  shinya:Joined the channel
Wed Dec 2 09:33:05 2015  rokubo:Joined the channel
Wed Dec 2 09:40:38 2015  oag:Joined the channel
Wed Dec 2 12:01:32 2015  felicity:is it possible to return an HTTP status (say, 404) in a remap rule?
Wed Dec 2 12:01:39 2015  felicity:something like 'map http://example.com/admin 404'
Wed Dec 2 12:41:32 2015  jrickman:Joined the channel
Wed Dec 2 13:27:23 2015  niq:Joined the channel
Wed Dec 2 13:31:37 2015  mturk:Joined the channel
Wed Dec 2 13:31:38 2015  mturk:Joined the channel
Wed Dec 2 13:38:44 2015  ibrezac:Joined the channel
Wed Dec 2 13:39:37 2015  JSeymour:Joined the channel
Wed Dec 2 13:58:05 2015  jrickman:Joined the channel
Wed Dec 2 14:08:26 2015  shinrich1:Joined the channel
Wed Dec 2 14:41:02 2015  esproul:Joined the channel
Wed Dec 2 15:02:24 2015  davet:Joined the channel
Wed Dec 2 15:09:57 2015  ibrezac:Joined the channel
Wed Dec 2 15:19:27 2015  niq:Joined the channel
Wed Dec 2 15:28:49 2015  sudheerv:felicity: you can have a header_rewrite plugin for the remap rule that returns 404
Wed Dec 2 15:29:24 2015  sudheerv:felicity: i was thinking about the SIE, and an option is to simply not cache the error (set the CC headers to not allow caching)
Wed Dec 2 15:29:39 2015  sudheerv:you can do that with a header_rewrite (or even lua) rule
Wed Dec 2 15:29:49 2015  sudheerv:that'd give you the SIE with open_write_fail_action
Wed Dec 2 15:30:31 2015  sudheerv:of course, it still needs some further work to check the headers etc
Wed Dec 2 15:39:06 2015  ggherdov:Joined the channel
Wed Dec 2 15:39:06 2015  BlackCobra:Joined the channel
Wed Dec 2 15:39:06 2015  skaji:Joined the channel
Wed Dec 2 15:39:06 2015  phibs:Joined the channel
Wed Dec 2 15:39:06 2015  Shireikan:Joined the channel
Wed Dec 2 15:39:06 2015  jacksontj:Joined the channel
Wed Dec 2 15:39:06 2015  lrea:Joined the channel
Wed Dec 2 15:39:06 2015  jrickman:Joined the channel
Wed Dec 2 15:39:06 2015  esproul:Joined the channel
Wed Dec 2 15:39:06 2015  davet:Joined the channel
Wed Dec 2 15:39:06 2015  niq:Joined the channel
Wed Dec 2 15:39:06 2015  msekimura:Joined the channel
Wed Dec 2 15:39:06 2015  dustywusty:Joined the channel
Wed Dec 2 15:39:06 2015  pquerna:Joined the channel
Wed Dec 2 15:39:06 2015  ke4qqq:Joined the channel
Wed Dec 2 15:39:27 2015  oag:Joined the channel
Wed Dec 2 15:39:28 2015  psp:Joined the channel
Wed Dec 2 15:39:28 2015  maskit:Joined the channel
Wed Dec 2 15:39:28 2015  perry:Joined the channel
Wed Dec 2 15:39:28 2015  kichan:Joined the channel
Wed Dec 2 15:39:28 2015  dcarlin:Joined the channel
Wed Dec 2 15:39:28 2015  briang:Joined the channel
Wed Dec 2 15:39:28 2015  jpeach:Joined the channel
Wed Dec 2 15:39:28 2015  sudheerv:Joined the channel
Wed Dec 2 15:39:28 2015  bcall:Joined the channel
Wed Dec 2 15:39:28 2015  zwoop:Joined the channel
Wed Dec 2 15:40:38 2015  rokubo:Joined the channel
Wed Dec 2 15:40:38 2015  shinya:Joined the channel
Wed Dec 2 15:40:38 2015  akotani:Joined the channel
Wed Dec 2 15:40:50 2015  RamJett:Joined the channel
Wed Dec 2 15:40:50 2015  mercutio:Joined the channel
Wed Dec 2 15:40:50 2015  _iwc:Joined the channel
Wed Dec 2 15:40:50 2015  jsime:Joined the channel
Wed Dec 2 15:40:50 2015  Zerpex:Joined the channel
Wed Dec 2 15:40:50 2015  [Jok]:Joined the channel
Wed Dec 2 15:42:49 2015  ihabunek:Joined the channel
Wed Dec 2 15:44:17 2015  felicity:Joined the channel
Wed Dec 2 15:44:17 2015  Humbedooh:Joined the channel
Wed Dec 2 15:44:17 2015  higgins:Joined the channel
Wed Dec 2 15:46:09 2015  swoc:Joined the channel
Wed Dec 2 15:50:58 2015  felicity:sudheerv: won't not caching the error just return the error to every client?
Wed Dec 2 15:51:38 2015  sudheerv:no, with open_write_fail_action
Wed Dec 2 15:51:51 2015  sudheerv:you are serving the stale copy until the new object is written to cache
Wed Dec 2 15:52:00 2015  sudheerv:if you don't cache the error, then, you will continue to serve the stale copy
Wed Dec 2 15:52:04 2015  felicity:but doesn't that only take effect for >2 clients trying to load the same resource at once?
Wed Dec 2 15:52:13 2015  sudheerv:yeah, > 1
Wed Dec 2 15:52:22 2015  sudheerv:every other client, will go to the origin though
Wed Dec 2 15:52:28 2015  felicity:so the 2nd simultaneous client will get the cached copy, but the original client will get the error
Wed Dec 2 15:52:40 2015  felicity:usually we don't have >1 simultaneous request for one page
Wed Dec 2 15:52:41 2015  sudheerv:umm…that's true
Wed Dec 2 15:52:50 2015  sudheerv:the 1st client will still get the error
Wed Dec 2 15:53:18 2015  sudheerv:yeah, i think once we implement the background refresh
Wed Dec 2 15:53:30 2015  sudheerv:that will address the problem for both SWR and SIE for the 1st client
Wed Dec 2 15:55:46 2015  sudheerv:i hope work on that part soon..but, yeah ,if you don't have a lot of concurrent requests, then it may not be ideal for you at the moemnt
Wed Dec 2 15:59:33 2015  mturk:Joined the channel
Wed Dec 2 15:59:33 2015  thumbs:Joined the channel
Wed Dec 2 15:59:33 2015  ibrezac:Joined the channel
Wed Dec 2 15:59:33 2015  rhand:Joined the channel
Wed Dec 2 15:59:33 2015  PSUdaemon:Joined the channel
Wed Dec 2 15:59:33 2015  daemonkeeper:Joined the channel
Wed Dec 2 15:59:33 2015  pyry:Joined the channel
Wed Dec 2 15:59:33 2015  \ask:Joined the channel
Wed Dec 2 15:59:33 2015  frantzipan:Joined the channel
Wed Dec 2 15:59:33 2015  igalic:Joined the channel
Wed Dec 2 16:19:55 2015  es:Joined the channel
Wed Dec 2 16:23:09 2015  es1:Joined the channel
Wed Dec 2 16:27:11 2015  lrea:Left the channel
Wed Dec 2 16:34:48 2015  luc:Joined the channel
Wed Dec 2 16:34:48 2015  gotadachi:Joined the channel
Wed Dec 2 16:34:48 2015  pdm:Joined the channel
Wed Dec 2 16:34:48 2015  adedommelin:Joined the channel
Wed Dec 2 16:34:48 2015  dstates:Joined the channel
Wed Dec 2 16:34:48 2015  sbeards:Joined the channel
Wed Dec 2 16:34:48 2015  sGoico:Joined the channel
Wed Dec 2 16:34:48 2015  Lethalman:Joined the channel
Wed Dec 2 16:34:48 2015  JSeymour:Joined the channel
Wed Dec 2 16:34:48 2015  shinrich1:Joined the channel
Wed Dec 2 16:34:48 2015  mturk:Joined the channel
Wed Dec 2 16:34:48 2015  thumbs:Joined the channel
Wed Dec 2 16:34:48 2015  rhand:Joined the channel
Wed Dec 2 16:34:48 2015  PSUdaemon:Joined the channel
Wed Dec 2 16:34:48 2015  daemonkeeper:Joined the channel
Wed Dec 2 16:34:48 2015  pyry:Joined the channel
Wed Dec 2 16:34:48 2015  \ask:Joined the channel
Wed Dec 2 16:34:48 2015  frantzipan:Joined the channel
Wed Dec 2 16:34:48 2015  igalic:Joined the channel
Wed Dec 2 16:46:23 2015  jrushford:Joined the channel
Wed Dec 2 16:46:23 2015  reveller:Joined the channel
Wed Dec 2 16:46:23 2015  igalic:Joined the channel
Wed Dec 2 16:46:23 2015  frantzipan:Joined the channel
Wed Dec 2 16:46:23 2015  \ask:Joined the channel
Wed Dec 2 16:46:23 2015  pyry:Joined the channel
Wed Dec 2 16:46:23 2015  daemonkeeper:Joined the channel
Wed Dec 2 16:46:23 2015  PSUdaemon:Joined the channel
Wed Dec 2 16:46:23 2015  rhand:Joined the channel
Wed Dec 2 16:46:23 2015  thumbs:Joined the channel
Wed Dec 2 16:46:23 2015  mturk:Joined the channel
Wed Dec 2 16:46:23 2015  shinrich1:Joined the channel
Wed Dec 2 16:46:23 2015  JSeymour:Joined the channel
Wed Dec 2 16:46:23 2015  Lethalman:Joined the channel
Wed Dec 2 16:46:23 2015  sGoico:Joined the channel
Wed Dec 2 16:46:23 2015  sbeards:Joined the channel
Wed Dec 2 16:46:23 2015  dstates:Joined the channel
Wed Dec 2 16:46:23 2015  adedommelin:Joined the channel
Wed Dec 2 16:46:23 2015  pdm:Joined the channel
Wed Dec 2 16:46:23 2015  gotadachi:Joined the channel
Wed Dec 2 16:46:23 2015  luc:Joined the channel
Wed Dec 2 16:46:45 2015  ggherdov:Joined the channel
Wed Dec 2 16:48:52 2015  swoc:Joined the channel
Wed Dec 2 16:48:52 2015  es1:Joined the channel
Wed Dec 2 16:55:58 2015  biilmann:Joined the channel
Wed Dec 2 17:00:57 2015  biilmann:Joined the channel
Wed Dec 2 17:19:18 2015  thumbs:Joined the channel
Wed Dec 2 17:39:03 2015  _klk_:Joined the channel
Wed Dec 2 17:52:56 2015  mturk_:Joined the channel
Wed Dec 2 17:52:57 2015  mturk_:Joined the channel
Wed Dec 2 18:10:28 2015  biilmann:Joined the channel
Wed Dec 2 18:21:47 2015  biilmann:Joined the channel
Wed Dec 2 19:08:56 2015  jrushford:Joined the channel
Wed Dec 2 19:54:26 2015  _klk_:Joined the channel
Wed Dec 2 20:04:03 2015  zwoop:where's Sorber this week ?
Wed Dec 2 20:04:54 2015  ihabunek:Joined the channel
Wed Dec 2 20:05:18 2015  swoc:Joined the channel
Wed Dec 2 20:05:34 2015  ibrezac:Joined the channel
Wed Dec 2 20:11:00 2015  ggherdov:Joined the channel
Wed Dec 2 20:35:26 2015  biilmann:Joined the channel
Wed Dec 2 20:43:30 2015  Sandman_:Joined the channel
Wed Dec 2 20:44:28 2015  Sandman_:hey...question
Wed Dec 2 20:44:57 2015  Sandman_:i'm running ATS on a server with many many drives that come up as sd* in /dev
Wed Dec 2 20:45:07 2015  Sandman_:the OS drives come up last
Wed Dec 2 20:45:36 2015  Sandman_:all the other drives (other than the OS drives) are cache drives, and are in storage.config
Wed Dec 2 20:46:14 2015  Sandman_:if i lose a drive and the server reboots, the OS drive comes up with the designation previously assigned to a cache drive
Wed Dec 2 20:46:27 2015  Sandman_:and ATS seems to corrupt the OS drive by writing to the raw block
Wed Dec 2 20:46:39 2015  Sandman_:...is there a way around this? am i doing something wrong?
Wed Dec 2 20:52:35 2015  jpeach:you need to configure ATS to use the stable device identifiers that udev provides
Wed Dec 2 20:52:43 2015  jpeach:iirc there's something in the docs about it
Wed Dec 2 20:52:54 2015  zwoop:it's in the FAQ on the wiki too
Wed Dec 2 20:53:51 2015  zwoop:or maybe not ... :)
Wed Dec 2 20:54:38 2015  zwoop:Sandman_ there are two options: use the /dev/disk/by-<...> or, explicitly give the disks a hash "seed" in storage.config
Wed Dec 2 20:55:05 2015  zwoop:so
Wed Dec 2 20:55:17 2015  zwoop: /dev/sdb id=foo
Wed Dec 2 20:55:54 2015  zwoop:although, this wouldn't prevent it from trying to use the system device if the system device rolls into your range :/
Wed Dec 2 20:57:26 2015  Sandman_:would it be possible to patch ATS to not open a raw device if there's a partition on it? just something i thought of
Wed Dec 2 20:57:59 2015  jpeach:yes it would be possible to use libblk to do that
Wed Dec 2 20:58:40 2015  zwoop:there is / was a Jira on that as well, not sure if we closed it as won't fix :)
Wed Dec 2 20:59:04 2015  Sandman_:ah okay
Wed Dec 2 20:59:26 2015  Sandman_:figured someone must have thought of that
Wed Dec 2 20:59:30 2015  Sandman_:thanks!!
Wed Dec 2 20:59:32 2015  Sandman_::)
Wed Dec 2 20:59:46 2015  zwoop:jpeach I think the discussion we had was to not let ATS reinitialize a disk unless explicitly asked to do so. So, when it tries to open /dev/sdb, and there's no proper cache header on that block, we simply ignore it (today it reinitializes it)
Wed Dec 2 21:00:44 2015  jpeach:how do you ask explicitly?
Wed Dec 2 21:01:18 2015  Sandman_:yeah the issue is that configuring with the /dev/disk/by-* is clunky using Traffic Control
Wed Dec 2 21:02:56 2015  zwoop:TS-667
Wed Dec 2 21:03:00 2015  zwoop:jpeach traffic_server -Cclear
Wed Dec 2 21:03:34 2015  zwoop:jpeach but, it's likely we'd need to add support to just initialize a single disk if we did something like this
Wed Dec 2 21:04:20 2015  jpeach:PSUdaemon: ^^^
Wed Dec 2 21:07:45 2015  dxu:Joined the channel
Wed Dec 2 21:15:48 2015  blattj:Joined the channel
Wed Dec 2 21:17:57 2015  dxu:Joined the channel
Wed Dec 2 21:25:05 2015  PSUdaemon:jpeach: ?
Wed Dec 2 21:25:05 2015  dxu:Joined the channel
Wed Dec 2 21:25:22 2015  jpeach:"configuring with the /dev/disk/by-* is clunky using Traffic Control" ...
Wed Dec 2 21:30:35 2015  PSUdaemon:yeah, i could see that
Wed Dec 2 21:32:38 2015  Sandman_:@PSUdaemon the configuration would have to be unique per-cache i think...
Wed Dec 2 21:32:59 2015  PSUdaemon:well, we wanted to have the idea of overlayed profiles
Wed Dec 2 21:33:12 2015  PSUdaemon:where you could combined mutliple profiles together
Wed Dec 2 21:33:22 2015  PSUdaemon:like ones that vary by hardware
Wed Dec 2 21:33:30 2015  PSUdaemon:ones that vary by purpose (mid vs edge)
Wed Dec 2 21:33:32 2015  PSUdaemon:etc
Wed Dec 2 21:33:41 2015  Sandman_:it's more than by hardware though, the WWN is unique i think
Wed Dec 2 21:33:44 2015  Sandman_:it's by server
Wed Dec 2 21:33:54 2015  PSUdaemon:yeah, so that would just be another layer
Wed Dec 2 21:34:25 2015  PSUdaemon:but, it'd probably be better to not use uuid then
Wed Dec 2 21:34:28 2015  Sandman_:i'd still call that "clunky" i think...
Wed Dec 2 21:34:44 2015  PSUdaemon:on the same hardware you'd have the same paths
Wed Dec 2 21:34:45 2015  PSUdaemon:for example
Wed Dec 2 21:35:03 2015  _klk_:Joined the channel
Wed Dec 2 21:35:51 2015  PSUdaemon:also, isn't there a way to alias them?
Wed Dec 2 21:36:07 2015  PSUdaemon:so at the system level you say that /dev/sdc is always a specific uuid
Wed Dec 2 21:36:09 2015  Sandman_:even the by-path on my hardware seems to have some unique UUID-like thing in it for content drives
Wed Dec 2 21:36:15 2015  PSUdaemon:but then just tell ATS /dev/sdc
Wed Dec 2 21:36:27 2015  Sandman_:there is, you can put that in the udev
Wed Dec 2 21:37:06 2015  Sandman_:you can basically say to call the thing at a certain PCI bus location "sdc"
Wed Dec 2 21:39:15 2015  PSUdaemon:i'm not sure how we can bolt a solution like that on easily
Wed Dec 2 21:39:28 2015  PSUdaemon:but i think that is something that we can look at supporting with a refactor
Wed Dec 2 21:42:37 2015  Sandman_:i had no good ideas for TC either...best idea i came up with was something like TS-667 above
Wed Dec 2 21:42:53 2015  Sandman_:i have a suitable workaround for now
Wed Dec 2 21:43:16 2015  Sandman_:(something in rc.d that chkconfigs trafficserver off if the OS drives aren't where they're supposed to be)
Wed Dec 2 21:44:21 2015  zwoop:PSUdaemon Sandman_ I always felt that the new id=<bob> feature to storage.config was rather "bandaid" like. It feels that the disk / cache header should contain everything you need, right ?
Wed Dec 2 21:44:31 2015  zwoop:so, you'd just in storage.config say /dev/sd*
Wed Dec 2 21:44:49 2015  zwoop:and it pickes all the /dev/sd<n> devices that are appropraiately initialized to be a cache
Wed Dec 2 21:45:14 2015  zwoop:if we do that, we'd need some tools to actually create the cache devices :)
Wed Dec 2 21:45:14 2015  PSUdaemon:sure
Wed Dec 2 21:45:18 2015  PSUdaemon:i could be on board with that
Wed Dec 2 21:46:56 2015  zwoop:amc said it was "complicated" though :)
Wed Dec 2 21:47:16 2015  zwoop:the reason for the id=<bob> thing is that when the devices gets renamed, the hash changes :-/
Wed Dec 2 21:47:54 2015  zwoop:what used to hash to /dev/sdc now sits on /dev/sdb (etc.)
Wed Dec 2 21:50:15 2015  shinrich1:Joined the channel
Wed Dec 2 21:56:15 2015  PSUdaemon:where is amc, btw?
Wed Dec 2 21:56:58 2015  zwoop:swoc
Wed Dec 2 21:57:26 2015  swoc:Hold on, reading now. ZNC is broken for me and I haven't gotten around to fixing it.
Wed Dec 2 21:57:41 2015  Humbedooh:..but the scanpans are okay, right?
Wed Dec 2 21:58:46 2015  swoc:Yes. I just popped out to check and they're doing well.
Wed Dec 2 21:58:55 2015  zwoop:swoc try changing that hostname in the ZNC server config (change it to chat.freenode.net)
Wed Dec 2 21:59:01 2015  zwoop:that fixed it to me
Wed Dec 2 22:00:11 2015  swoc:Dr. H said PSUdaemon was looking for me...
Wed Dec 2 22:00:59 2015  _klk_:Joined the channel
Wed Dec 2 22:01:00 2015  swoc:Pre-initializing drives is hard because of the way volumes interact with devices.
Wed Dec 2 22:01:43 2015  bcall:PSUdaemon: do you think you can do a patch for TS-3883 for 6.0.x?
Wed Dec 2 22:02:18 2015  bcall:PSUdaemon: I don't know all the details - and ink_queue.cc doesn't merge in cleanly
Wed Dec 2 22:05:14 2015  PSUdaemon:bcall: yeah
Wed Dec 2 22:10:54 2015  shinrich1:Joined the channel
Wed Dec 2 22:41:00 2015  bcall:zwoop: for a 6.0.1 release - should the bugs have a fixed version of 6.0.1 or 6.1.0 or both?
Wed Dec 2 22:41:25 2015  bcall:zwoop: my thought is 6.0.1 - and the release notes should only be in that version for the jira ticket
Wed Dec 2 22:41:35 2015  zwoop:both
Wed Dec 2 22:41:49 2015  zwoop:at least that's what we've done in the past
Wed Dec 2 22:42:08 2015  zwoop:it gets particularly important to do that when you backport to an LTS, so I figured consistency was good ?
Wed Dec 2 22:43:01 2015  bcall:I was thinking when moving forwarded it would only be in the release notes of the first release it was in
Wed Dec 2 22:43:45 2015  bcall:if it is a backport to an older release then you would want both
Wed Dec 2 22:44:14 2015  bcall:doesn't really matter that much
Wed Dec 2 22:44:21 2015  bcall:I can add it to both
Wed Dec 2 22:45:22 2015  PSUdaemon:to me the distinction here is that 6.1.0 is not downstream of 6.0.1
Wed Dec 2 22:46:15 2015  PSUdaemon:so anything that is cherry picked back should be listed in the version it was originally committed to and the place it was cherry picked to
Wed Dec 2 22:47:00 2015  bcall:yeah, but if you look at other project I don't think they dup the changes
Wed Dec 2 22:47:09 2015  bcall:in the release notes
Wed Dec 2 22:49:23 2015  zwoop:that seems really confusing in the case of e.g. 5.3.2 to 6.1.0. I'm upgrading from 6.0.0 to 6.1.0, and some changes that are in 6.1.0 don't show up in the release notes because they were backported to 5.3.2 ?
Wed Dec 2 22:49:53 2015  PSUdaemon:i think he means in the case where there is no newer version yet
Wed Dec 2 22:49:59 2015  PSUdaemon:like there is no 6.1.0
Wed Dec 2 22:50:08 2015  bcall:zwoop: you are changing the scenario
Wed Dec 2 22:50:26 2015  PSUdaemon:but you could upgrade from 6.0.0 to 6.1.0
Wed Dec 2 22:50:30 2015  PSUdaemon:once 6.1.0 comes out
Wed Dec 2 22:50:42 2015  zwoop:well, I said "it's important for backporting to LTS releases, and that it'd make sense to keep consistency even within the 6.0 / 6.1"
Wed Dec 2 22:50:59 2015  zwoop:@zwoop: it gets particularly important to do that when you backport to an LTS, so I figured consistency was good ?
Wed Dec 2 22:51:08 2015  bcall:that seems really confusing in the case of e.g. 6.0.0 to 6.1.0. I'm upgrading from 6.0.0 to 6.1.0, and some changes that are in 6.1.0 don't show up in the release notes because they were backported to 6.0.1 - that is what it would be like
Wed Dec 2 22:51:36 2015  zwoop:you are saying we do it different depending on if it's backported to an LTS or not ?
Wed Dec 2 22:51:44 2015  bcall:yes
Wed Dec 2 22:51:52 2015  zwoop:that seems more confusing to me
Wed Dec 2 22:52:00 2015  zwoop:but I have no strong opinion here
Wed Dec 2 22:52:11 2015  zwoop:consistency seems easier
Wed Dec 2 22:52:17 2015  PSUdaemon:i think we shouldn't distinguish the two
Wed Dec 2 22:52:33 2015  zwoop:I agree with PSUdaemon :)
Wed Dec 2 22:52:34 2015  PSUdaemon:i think it's more important that it's a different path in the git tree
Wed Dec 2 22:52:56 2015  PSUdaemon:and if the change isn't "upstream" from your release, then you need to note it
Wed Dec 2 22:54:16 2015  zwoop:taht'd imply all cherry-picks / backports, no ?
Wed Dec 2 22:55:57 2015  bcall:it is different then what other people, do but it is not a big deal to me what we do
Wed Dec 2 22:56:31 2015  bcall:there wouldn't be that much duplication
Wed Dec 2 22:56:53 2015  bcall:e.g. openssl: Changes between 1.0.1l and 1.0.2 [22 Jan 2015]
Wed Dec 2 22:57:35 2015  zwoop:openssl is probably the worst possible project to compare with, since they have the stupidest versioning ever :-)
Wed Dec 2 22:57:38 2015  zwoop:but yes, I hear ya
Wed Dec 2 22:58:04 2015  zwoop:they only backport security fixes though I assume ?
Wed Dec 2 23:00:28 2015  bcall:also with httpd: http://ftp.wayne.edu/apache//httpd/CHANGES_2.4.17
Wed Dec 2 23:00:53 2015  PSUdaemon:zwoop: yes, all cherry picks
Wed Dec 2 23:00:56 2015  bcall:I added 6.1.0 and 6.0.1 as the fixed versions for the bugs
Wed Dec 2 23:01:35 2015  PSUdaemon:which that CHANGES had a proper mime type :)
Wed Dec 2 23:02:13 2015  bcall:lol
Wed Dec 2 23:03:29 2015  _klk_:Joined the channel
Wed Dec 2 23:18:02 2015  masaori_:Joined the channel
Wed Dec 2 23:29:35 2015  zwoop:bcall but does backported 2.4.x changes to 2.2 not show up in the 2.2. release notes?
Wed Dec 2 23:30:13 2015  bcall:I would think it would
Wed Dec 2 23:30:26 2015  bcall:didn't look at that case
Wed Dec 2 23:51:40 2015  masaori_:Joined the channel

Comments