Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:43
    codecov[bot] commented #1672
  • 17:30
    codecov[bot] commented #1678
  • 17:02
    codecov[bot] commented #1672
  • 17:02
    dejanb synchronize #1672
  • 16:39
    codecov[bot] commented #1672
  • 16:39
    dejanb synchronize #1672
  • 15:37

    sophokles73 on master

    Use Always image pull policy fo… (compare)

  • 15:37
    sophokles73 closed #1713
  • 15:35
    codecov[bot] commented #1678
  • 15:34
    kaniyan synchronize #1678
  • 15:24
    codecov[bot] commented #1678
  • 15:24
    kaniyan synchronize #1678
  • 14:01
    wanvidu starred eclipse/hono
  • 12:43

    eclipsewebmaster on 1.1.0-M2

    (compare)

  • 12:43

    eclipsewebmaster on master

    Release 1.1.0-M2 Bump version to 1.1.0-SNAPSHOT (compare)

  • 12:37

    sophokles73 on master

    Publish CoAP adapter to Maven C… (compare)

  • 12:37

    sophokles73 on 1.1.0-M2

    (compare)

  • 12:19
    codecov[bot] commented #1672
  • 12:19
    dejanb synchronize #1672
  • 12:18
    codecov[bot] commented #1672
Kai Hudalla
@sophokles73
I also wonder if it feasible to define the forwarding of client provided headers in commands as a supported concept. Not sure if we could implement this for all protocols ...
BTW we currently use the presence of a correlation-id in a command message as an indicator that this is in fact a request/response command (instead of a one-way command) ...
Thomas Jaeckle
@thjaeckle
hm, for HTTP custom headers would be really cool as default headers like "content-type" or "ETag" or other caching headers might become really useful
ah, I thougt Hono uses the reply-to header as indication that this is a request/response command
Kai Hudalla
@sophokles73
you are right, of course, we use the reply-to header ... it's getting late
Thomas Jaeckle
@thjaeckle
ok, all good then :)
Kai Hudalla
@sophokles73
Can you open an issue for this in Hono? We can then track this better ...
Thomas Jaeckle
@thjaeckle
sure
Kai Hudalla
@sophokles73
@ctron Hi Jens, IIRC you wanted to set up a Doodle poll for finding a date/time for the IoT Packages call/meeting, right?
Jens Reimann
@ctron
Yes, I did that … everyone voted :D
it is today … 16:00 CET
Kai Hudalla
@sophokles73
Except for me, because I didn't follow the issue closely enough?
Jens Reimann
@ctron
sorry, that may be … I only know that Carsten can't join today, he is out of office IIRC
there is also a calendar with the invite
I did however forget to add this to the homepage.
Kai Hudalla
@sophokles73
no worries, found it ...
Kai Hudalla
@sophokles73
@dejanb Hi Dejan, have you been able to take a look at #1647 ?
Dejan Bosanac
@dejanb
@sophokles73 just briefly ... I plan to work on it tomorrow
Kai Hudalla
@sophokles73
cool
Kai Hudalla
@sophokles73
@ctron @dejanb @calohmn It looks like there is only a single place where we still use code from Google Guava: some toString() methods in the Device Registry helper classes. I wonder if we can remove that dependency altogether from Hono ... WDYT?
Jens Reimann
@ctron
hm … while I like the "ToStringHelper" stuff, guava's dependencies are sometimes tricky, so getting rid of it might be a good idea :+1:
that would be a change for 1.1?
Kai Hudalla
@sophokles73
I guess so. Guava is not part of any of our public APIs AFAIK
Dejan Bosanac
@dejanb
+1
Carsten Lohmann
@calohmn
I'm also for removing it then.
Kai Hudalla
@sophokles73
I will create an issue for it then and assign it to @ctron !?
Dejan Bosanac
@dejanb
@sophokles73 how do you wanna proceed with #1647
I have some fixes, but I doubt I can push them to bsinno
Kai Hudalla
@sophokles73
I can push the branch to eclipse/hono as well. We can then work on it together an create a PR from it. Would that work for you?
Dejan Bosanac
@dejanb
yeah ... sounds perfect
Kai Hudalla
@sophokles73
ok, gimme a minute ...
Dejan Bosanac
@dejanb
so basically I have helm chart running (at least getting started looks ok) and systems tests run but I saw a couple of failures
would love to push this to see how it looks in CI and then continue tweaking it
Kai Hudalla
@sophokles73
ok, I have pushed the branch to eclipse/hono ...
Dejan Bosanac
@dejanb
cheers
Dejan Bosanac
@dejanb
new pr is #1651 as I don't think we can edit the old one
I also rebased the branch, so now is mergable
Kai Hudalla
@sophokles73
@ctron would you mind taking a look at #1654 ? It is supposed to be part of 1.0.2 which we want to release this week ...
Jens Reimann
@ctron
done
Kai Hudalla
@sophokles73
@ctron thanks, man :-)
Kai Hudalla
@sophokles73
@ctron @calohmn @dejanb Today is the day we have scheduled 1.1.0-M1 for :-) Anything you got cooking that should be in this milestone in addition to what we have in the "done" column of our 1.1.0 project board?
Carsten Lohmann
@calohmn
From my side that would be #1654. @ctron I've pushed a change to that PR yesterday. Could you have another look?
Jens Reimann
@ctron
@calohmn done … sorry, I assumed you would simply add a comment and merge :grinning:
Dejan Bosanac
@dejanb
@sophokles73 I would like to take a look at the artemis logs
when are you planning to cut it?
Kai Hudalla
@sophokles73
@dejanb No particular plan. What about 5PM?
Dejan Bosanac
@dejanb
@sophokles73 sure ... I'm looking into this now
Kai Hudalla
@sophokles73
I would like to change the way we handled the release notes for milestones in the past. We used to add a heading for the milestone in the release notes, basically treating it as a separate release. However, the Eclipse Foundation doesn't consider a milestone to be a release and neither should we. Base on that, I propose to simply keep on adding text to the release notes for 1.1.0 and include it in the announcement mail I send out for the milestone. This way people still can see what has changed in the milestone but we do not need to create a project board for the milestone(s) which we can reference by URL. WDYT?
Dejan Bosanac
@dejanb
+1
Karthees Kalidass
@kaniyan
+1