@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+lbt
+postman
+radakayot
+segfault
+wodencafe
Arch
Danny
DeltaOreo
FreefallHeavens_
Irc2PGuest10722
Irc2PGuest12249
Irc2PGuest18129
Irc2PGuest27222
Irc2PGuest54664
Irc2PGuest59134
Irc2PGuest86934
Irc2PGuest90091
Irc2PGuest92478
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Sleepy
Soni
T3s|4_
Teeed
aeiou
aisle1
ardu
b3t4f4c3___
bak83
boonst
bpb
defaultnick
dickless
dr4wd3_
enoxa
eyedeekay_bnc
orignal_
poriori_
profetikla
qend-irc2p
rapidash
shiver_
snow
solidx66
u5657
uop23ip
w8rabbit
x74a6
orignal
maybe you should ask that guy who maintains i2pd there?
zzz
stats.i2p services are back to life, postmortem posted on zzz.i2p, apologies for the downtime
zzz
eyedeekay, I encourage you to push to the finish line and get the Android release out this week, even with 2.8.1 coming next week
eyedeekay
Ack, even if it doesn't get used much there will be an i2p-android-2.8.0 tag and binaries
zzz
does the 'organization' change mean that ppl will have to uninstall and reinstall?
zzz
please also update CHANGELOG that you've stopped doing, and add it to your checklist
eyedeekay
It should be transparent, same keys, nobody should have to uninstall or reinstall
eyedeekay
Ack re: changelog
zzz
are you not checking in changes as you've been working the last 4 months, or are you just not pushing them?
eyedeekay
For Android everything is on a the branch i2p-android-2.8.0-androidx
zzz
good to know, but why not do dev in the main branch?
zzz
why not merge today?
eyedeekay
Re: merge today yeah probably will, re: not dev on main TBH I wasn't sure which solution I would have to use, there was a version where we kept using android.support.v* libraries and I got com.inkapplications.viewpageindicator:2.4.4 to compile again, and a version where we migrated from android.support.v* to androidx.* libraries and switched to a different(maintained) pager-indicator library
eyedeekay
So I tried both, one on each branch
zzz
ok
zzz
but for transparency, reviews, and assistance, we didn't know any of that, and I didn't see the branch
zzz
please don't squash when you merge so the history isn't lost
eyedeekay
OK
zzz
for the most part we should be doing incremental dev in the master branch, unless it's some big project
zzz
and as soon as you decided which branch was the winner, you should have merged it in and kept going in master
zzz
I think your go-i2p dev process may have similar issues, you're promising some huge merge coming soon, but in the main branch it's crickets
eyedeekay
Well I've got a clear winner now so it will go into master in the next hour
eyedeekay
and yeah you're right on both counts, I need to get things merged faster so people can see what's going on
zzz
Yeah. Activity breeds interest and contributors and reviewers and testers. You lose a lot when you're off in a branch nobody knows about.
zzz
eyedeekay, I think we should make a policy decision on whether/when to do WIP branches on the main i2p.hackers account, for any project
zzz
I'm not a fan
zzz
they end up as mysterious undocumented clutter on github
zzz
WIP should be under your own account; reserve i2p.hackers branches for true forks like for point releases if necessary
zzz
most serious projects only have multiple branches on github if they're maintaining them, they aren't WIP
eyedeekay
OK, I will try and make sure I don't push WIP branches to repos on the project namespace, we have a few in i2p.android.base, I'll take a few min and clean them up today, I might have pushed a WIP python3 branch in i2p.www too, will check
zzz
not so worried about www
zzz
ok, it's agreed, except (maybe) www, no WIP branches in the main account. I'll update the dev guidelines
zzz
please delete WIP branches across all projects in i2p-hackers gitlab and on github
eyedeekay
Will do
zzz
thanks
aisle
Are I2P datagrams reliable? The documentation states that reliability is provided by the transport layer, and the protocol at the application layer plays no role in the decision of transports used for tunnel creation.
zzz
no
zzz
not end-to-end
zzz
the quote is true but you're inferring too much from it
aisle
I should clarify, I'm not asking in terms of total reliability but rather if that I2P datagrams aren't totally unreliable like UDP is.
zzz
they are totally unreliable, just like UDP is
zzz
even though some portions of their journey are more reliable than others