Monero Dev Meeting Note Highlights – 2017-08-20
Logs
351 lines
fluffypony1. Greetings
fluffypony2. Brief review of what's been completed since the previous meeting
fluffypony3. Code + ticket discussion / Q & A
fluffypony4. Any additional meeting items
fluffypony5. Confirm next meeting date/time
fluffyponyrehrar can do it next time :)
rehrarI can, sorry for the confusion
fluffypony1. Greetings
fluffyponycan all the people who aren't here just say nay
fluffypony:-P
hycneigh
suraewe never get past this part :
fluffyponyit's a fun part
fluffyponywe can move on to 2
fluffypony2. Brief review of what's been completed since the previous meeting
fluffyponyI guess the big thing is that we've branched
suraewell
suraefrom MRL
suraewe got contacted by RingCT2.0 people, and we got contacted by a rsearcher named Tim Ruffing, each of them presenting improved set-ups for our current implementations
suraenot sure if I should just jump in or what..
dEBRUYNEYeah go ahead
hycsure, go
suraeok so
suraeI have a .txt file describing the pseudocode of Ruffing's sublinear ring sig + CT set-up
suraeknaccc has been going through it and implementing it in Java
suraewe have a surprising amount of it debugged
hyc\^ note, we're walking away from the RingCT2.0 stuff because it requires a trusted setup
suraeAh, I didn't look into it because Ruffing's doesn't have a trusted set-up or any "new" crytpo. it just doubles all our key lengths
iDunksurae: fpaste.org or pastebin.mozilla.org
sn0wmonsterhas the meeting started?
endogenicyes
sn0wmonsterwhere does it say it started? jesus
suraeiDunk is 0bin not good enough? :P
iDunkIt requires java.
iDunkjs actually
moneromoooI think it needs to be encrypted due to agreement with Tim Ruffing.
suraeoh i didn't realize that
DaveyJonessurae … the mooo wants javaless paste
suraemoneromooo no, just habit
suraeok one sec
moneromoooOh, ok. I'm dying to see it then :D
moneromoooty
suraewe are in the midst of debugging knaccc's java code
dEBRUYNEsurae: Could you perhaps give an ELI5 (for anyone that reads the logs later) how RuffCT will improve our protocol?
suraewell, roughly, (ruffly)
knaccclol
suraesignature sizes are O(N) right now. So signature sizes take up "as much space" as the number of public keys implicated in the signature
suraeRuffing's set-up, for N=n\^m, has signature sizes O(n*m). Verification and computation it appears to be on the same order. so, for example, to sign a ring signature with N=10\^17 signers, which is freaking absurd, you would need "as much space" as 1017 = 170 public keys
suraethere are constants and stuff, so it's not exact, but at the very least, Ruffing's set-up is looking at really absurdly large ring signatures
hyc… without taking absurdly large amount of space
suraewith a set-up like this, there should be no good reason to not simply sign every transaction with the top half of the blockchain every time
suraeor taking absurdly large amounts of time to verify or compute
dEBRUYNESo we can easily use ring size 100k for instance?
dEBRUYNEOr even higher
hyceven higher
fluffyponyEVEN HIGHER
suraeassuming his set-up actually works (the math seems tight) and assuming his security proofs hold up (I am going to try to make independent security proofs and then later compare them), and after six months to a year of testing, etc etc
suraei mean
JollyMort[m]UNLIMITED RINGSIZE
endogenicfluffypony: what does the scouter say about monero's ringsize level?
moneromooolog(infinity) is infinity…
suraein a certain sense, this is like an alien came down and gifted us faster than light travel. yeah, we can go out there and start traveling around, but we have to consider consequences for the timeline. :P haha
fluffyponyendogenic: I give up?
endogenicit's over 9000
fluffyponylol
DaveyJonesthe puns are ruff today
fluffyponyalso to add to what surae's said
moneromoooWould be need (pretty much) all pubkeys/commitments in RAM all the time, in order to verify such sigs ?
moneromoooOr can some precomp be done ?
fluffyponymultisig isn't baked in right now, it would need to be re-done from scratch
rehrarthe room fell silent
hycI'll precompute it all for ya. trust me.
dEBRUYNEfluffypony: Are we certain it has to be re-done from scratch or would it possible to just tweak the current implementation?
suraemoneromooo the signature itself only uses the commitments from the column of the signer
fluffyponydEBRUYNE: we're certain
dEBRUYNEk
DaveyJonesfluffypony - can it be dual run like pre-ct and ring-ct till the fork?
dEBRUYNEI think we shouldn't forego the current implementation, because we're already quite far in
suraedebruyne the shen-luigi multisig set-up which is a version of the schnorr multisig, might lead us to a similar set-up for RuffCT, but it's not a simple gluing like one would hope
dEBRUYNEIn addition, it may take a year before RuffCT is actually implemented
DaveyJonesso that we could keep luigi ms till ruff ms is done ?
dEBRUYNEAnd even longer before we have a multisig that is compatible with ruffct
JollyMort[m]you can always convert later
fluffyponyDaveyJones: I don't think so, at least not trivially
JollyMort[m]i mean if we have to do RCT->RuffCT
suraedEBRUYNE I'm actually with you on that. chances are good RuffCT is about 1 year out from being live, and I wouldn't be *shocked if we could make a threshold scheme out of it before that year is up
JollyMort[m]same can be done for wallets
JollyMort[m]RCT multisig -> RuffCT multisig
fluffyponywell, basically this isn't going in to a hardfork until we have multisig
msvb-labJollyMort[m]: hardware or software wallets?
tyrionmcmmasteri agree with the majority, that multisig pre-ruffct should be implemented for the time being
JollyMort[m]and shen/luigi multisig can work regardless of consensus rules
dEBRUYNE<msvb-lab> JollyMort[m]: hardware or software wallets? <= Doesn't matter
JollyMort[m]by means of one-time multisig wallets
suraeso i'm happy finsihing up the shen-luigi multisig scheme, letting wallets use it until RuffCT goes live, they'll still be able to use it for whatever RCT outputs are still floating around if they like… and maybe users may miss out on threshold signatures for one hardfork, but probably not two.
hycthat sounds decent
fluffyponyok
DaveyJones\^+1
fluffyponyguys let's move on
suraeexcellente
fluffypony3. Code + ticket discussion / Q & A
DaveyJonescan i chime in for the AFK devs?
fluffyponybefore we discuss any specific PRs / issues
fluffyponyI wanted to get a feel as to how we should handle the branch wrt PRs
fluffyponyie. do we want people to push PRs to both branches where relevant
fluffyponyor must I just cherry-pick commits?
moneromoooPush to both, or the GPG signature drops.
fluffyponymoneromooo: I meant cherry-pick to my fork and then PR it
hycok. but tat this pre-release time, how are we deciding which PRs are eligible for the release branch?
moneromooofluffypony: I don't understand that.
moneromoooIf someone wants a patch to the release branch, they PR it to that branch too.
vtnerdbug fixes should automatically be considered … everything else is subjective
fluffyponyvtnerd: it's bug fixes only
moneromoooI guess you can cherry-pick if the commit isn't signed in the first place.
fluffyponynothing else goes in, we're in code freeze on the branch
fluffyponymoneromooo: if I cherry-pick and I sign it then it's still signed?
vtnerdok good, at least we are in agreement on that
moneromoooWell, it's signed by you, yes…
moneromoooBut you're kinda not the author ? :)
fluffyponymoneromooo: with cherry-pick it lists both myself and the aithor iirc
fluffypony*author
moneromoooI guess nobody really cares anyway.
moneromoooYes, but the author's signature drops AFAIK.
moneromoooSo you could modify a large patch, sign it, and nobody would notice.
iDunkI agree with moneromooo, that's not the way to do it.
hycok, so PR directly to release branch
fluffyponymoneromooo: https://i.imgur.com/PG0YmsF.png <- like that
hycthere's 22 open PRs at the moment. only a few seem to be current bugfixes
moneromoooMost people will just PR to master anyway, so not much trouble.
moneromoooI'm not sure I get the point.
fluffyponyok this is more about the fallback if the contributor doesn't PR to the branch in a timeous fashion
moneromoooIn that case, if it's really needed for the branch, cherry-pick is OK I suppose.
fluffyponyok cool
hycbut re: the branch, I'd like #2313 and #2314 to go into the release. should help further reduce chance of corruption on powerfail.
moneromoooAgreed.
moneromoooI'll just fixup the target thing too.
hyccool
moneromoooI think just removing the state check will be fine.
fluffyponyyes
fluffyponyif those can be PRd to the branch that would be great
hycwilldo
fluffyponyok - anything else?
JollyMort[m]about GUI cold signing
JollyMort[m]any plans to add import/export outputs&keyimage stuffs
msvb-labfluffypony: Not sure when it's appropriate to ask for consensus on (yes) increase efforts towards a hardware wallet or (no) maintain status quo.
fluffyponywhat's everyone's feelings on merging 0MQ into master?
DaveyJonesso tewinget only said that he just wants further feedback
dEBRUYNEJollyMort[m]: Jaquee isn't here afaik
DaveyJonesand jaquee asked this
Jaqueei'm here now
hycI thought merging 0MQ is slated for after the release
DaveyJones<Jaquee> not sure if i can make it to the meeting. have two questions. 1. updates on disk space on build machines (when can we have an android apk available for download?) 2. updates on app store and transifex accounts?
Jaqueereading backlog
moneromoooAfter the release is done, yes.
DaveyJonesoh your here :D
fluffyponywe've already branched, tho, so surely we can merge to master?
moneromooohis here.
fluffyponymsvb-lab: the dev working group don't really control external manufacturers
dEBRUYNEfluffypony: moneromooo wants to put in an additional review afaik
moneromoooI've not looked at the latest changes yet.
dEBRUYNEAnd tewinget is waiting for further feedback
fluffyponyok
Jaqueebut maybe lightwallets PR can be merged? (in masteR)
pigeons1[m]Jaquee we got the build machine so early this week on the android jobs
rehrarregarding the transifex account, I've found an open-source, self-hosted alternative in weblate.org
medusai dont think the fact if we branched mathers too much regradiing 0mq
Jaqueepigeons1[m]: Great!
rehrarjust waiting on the new server infrastructure :)
medusawe should play it safe
moneromoooIf the lightwallet stuff is the same I reviewed already, it was OK to merge IIRC.
Jaqueeit's the same
fluffyponykk
dEBRUYNE\^ Not sure we should put that up on SE already
sn0wmonsteri have a suggestion for future meetings, let me know when i can make it.
JollyMort[m]yeah i thought that too dEBRUYNE
JollyMort[m]surae what do you think?
fluffyponyyeah I think some of this is confidential-ish
hycare we still on ticket discussion?
DaveyJonesaye
JollyMort[m]i mean, putting it in the meeting logs also makes it public
JollyMort[m]the genie is out of the bottle
dEBRUYNEI can just remove it from the logs
fluffyponyhyc: about to move on, but you can still bring stuff up
hycno that's fine
dEBRUYNEJollyMort[m] \^
hyclet's move on
dEBRUYNEfluffypony: Jaquee wanted to know about the appstore accounts btw
fluffyponysurae should weigh in on that
dEBRUYNEIf you have any update on that
Jaquee^^
fluffyponyapp store accounts are waiting on the D-U-N-S number to be sent to Apple, I've sent scans of docs to Google and M$
fluffyponyso Two Weeks™ ?
fluffypony4. Any additional meeting items <- moving on to that
fluffyponysince it's part of it anyway
sn0wmonsteris this where i can make a suggestion?
fluffyponysn0wmonster wanted to make a suggestion
sn0wmonsteryay
sn0wmonsterso, i noticed the meeting started only after it was obvious it was a meeting
sn0wmonsteri don't see a Meetbot (which apparently is a package in Debian),
sn0wmonsterso if you must do it this way, i was wondering if you wouldn't make it painfully obvious to everyone with a header of some kind, like this:
othemsvb-lab asked a question but got overrun, i am willing to help sponsor his hw wallet stufdlf
fluffyponyalso the time is set two weeks in advance
sn0wmonster\/flushq
pigeons1[m]Sn0wmonster makes a great meeting bot
hycit's also announced on reddit and github
sn0wmonsterbeep bop boop
otheFfs sake, there are 2 hw wallet proposals. Feedback appreciated.
msvb-labothe: If anyone has advice on what to change in those FFS, the URLs are:
hycand was announced here a few hours earlier
endogenicsn0wmonster: https://github.com/monero-project/meta/issues
fluffyponysn0wmonster: https://www.reddit.com/r/Monero/comments/6uvu94/dev_kovri_meetings_later_today_1700_1800_utc/
DaveyJonesshhh listen to othe and msvb-lab
sn0wmonsteri didn't say it wasn't known, i said the chatlog had no introduction that the meeting had started really
endogenicsn0wmonster: it did though ?
JollyMort[m]i'm saying it had :) first post by fluffypony with the agenda 0. .. 1. .. 2.. …
JollyMort[m]maybe you missed it
msvb-labDaveyJones: Rather than listen, please speak whoever is interested in hardware crypto and border searches.
rehrarbut it didn't have the Monero symbol
endogenicmsvb-lab: doesn't quite seem like a dev item tho
hycyeah, I think we can put that meeting announcement topic to rest.
DaveyJonesmsvb-lab they cannot speak if they don`t listen :D
moneromoooIn other code news: I'm still debugging sync niggles with iDunk's help (who's been doing a LOT of testing, so many thanks). It'll be ready soon (both branch and master).
rehrarmsvb-lab: we can talk about it in Community meeting next week?
msvb-labendogenic: Okay, let's postpone. Good idea rehrar.
JollyMort[m]about the gui cold signing
iDunkYw :)
JollyMort[m]it's still missing features
moneromoooIf someone feels like syncing, please try the sync-standby3 branch :)
endogenicmsvb-lab: no need to post-pone. maybe bring it up in #Monero ?
dEBRUYNErehrar, endogenic: If there's room left, why not give msvb-lab the floor for a few minutes?
moneromoooIt may not be code per se, but it's tech. I think it's fine here. Still 10 minutes.
otheI'll just sponsor it, its hilarious that there's no secure way to store xmr.
endogenickk
fluffyponymsvb-lab: a dedicated wallet would be cool
rehrarwell that's decided then isn't it?
msvb-labSo the question is if we can achieve consensus on how to lower risk of another year with no wallet.
hycthere are two proposals tho, do we have to pick one, or do both?
msvb-labhw wallet, i mean.
fluffyponyLedger are already working on it, not sure if we need to double up efforts there
dEBRUYNEPerhaps it'd be more beneficial if we have some general firmware that hw wallets could implement
suraegosh, sorry, i got distracted. no, please don't put up a stackexchange yet. a few weeks, no problem, but right now we should maybe keep it a little quieter~
suraeif possible
suraecat's out of the bag, but i mean
msvb-labhyc: One deals with dedicated hardware design, the other with porting to existing hardware.
fluffyponymsvb-lab: https://www.reddit.com/r/Monero/comments/6thv8j/ledger_hardware_wallet_monero_integration/ <- this is from 6 days ago
endogenic2quick4u fyi
msvb-labfluffypony: That's probably Cedric's document Blue-something, quite good.
dEBRUYNE<msvb-lab> hyc: One deals with dedicated hardware design, the other with porting to existing hardware. <= Even though the former would be pretty cool, the latter is probably more beneficial
JollyMort[m]and debruyne out the link then; i feel like simply removing stuff from the logs goes against some principle on transparency
hyclooks to me like Ledger has done the hard part of figuring out the division of labor between hw wallet and Monero libraries
Jaqueeledger said alpha around end of september iirc.
fluffyponyI don't think there's value in doubling up on the Ledger effort
hyc^^ agreed
dEBRUYNEWhat about porting to Trezor and Keepkey though?
Jaquee+1
msvb-labThere have been firmware ports (to Trezor) before that have not met Monero's feature set (RingCT) or unmaintained.
dEBRUYNEPerhaps msvb-lab is interested in finishing noodle's code?
fluffyponymsvb-lab: Trezor was more complicated than that
msvb-labI just hope if Cedric completes the port, that there is maintenance after that.
fluffyponyNoodleDoodle did the Trezor firmware
JollyMort[m]Cedric is the Ledger crypto-guy
ferretinjapanfluffypony, choice is always a good thing WRT HWE wallets, otherwise we may get centralisation of support/development/monopoly of service, etc.
hycI'd say we pick up whatever changes ledger comes up with and use that as a basis for other hw projects
fluffyponythen there was a bit of a disagreement between Trezor and us
JollyMort[m]afaik
fwrttrukjwtrijdhsorry, noticed objections above to SE questions. Will delete for now. Does same objection apply to both Ruffling and RingCT2.0 paper?
fluffyponyand then I met up with them 33c3, and they said that it's not worth us moving forward on it till Trezor 2.0
hycif all the wallets use the same handshakes that saves everyone effort
fluffyponywhich was Coming Soon™
moneromoooTim Ruffing requested keeping is internal as a courtesy. I don't think anhything like that applies to Ringct 2.0.
dEBRUYNEThe 2.0 paper was posted on reddit too :P
hycthat's as close as we'll get to a "common firmware" - other hw wallets will be based on different chips anyway
msvb-labNot sure how stable (management or technically) Trezor is, hoping Cedric follows through on the Ledger work is a possibility. We then do little or nothing and wait for results.
fluffyponymsvb-lab: I'd support effort on a dedicated HW wallet
JollyMort[m]chip design etc? that sounds good
JollyMort[m]especially if all the schematics are published
msvb-labSomething that interests me is adding Monero specific features to a dedicated wallet, and make it as border search proof as possible (not supported by Ledger.)
JollyMort[m]so anyone can buy the parts and build it
hyclol. I'm not soldering surface-mount chips by myself.
msvb-labJollyMort[m]: Everything would be designed with KiCad and published in a github or similar.
sn0wmonsterwhat is not border-proof about ledger?
msvb-labhyc: I have a SMD lab, reflow and all.
ferretinjapanhyc, what's the problem? All you do is put it in the oven ;)
msvb-labsn0wmonster: No ability to destroy the private key without battery.
fluffyponyavoiding the glitching attacks just demonstrated against Trezor will be fun
hyclet's just say I've overcooked a few microcontrollers in my day…
endogenichyc: you need an intern or two
JollyMort[m]hyc baking bad :)
msvb-labfluffypony: Yes, glitch defense is part of the design. I'm not sure it's possible at all, but there will be research.
fluffyponycool beans
dEBRUYNEfluffypony: Do we still have time, I wanted to suggest something more generally?
msvb-labfluffypony: Randomness probably plays an important role, so we have chips like ATSHA240A.
DaveyJonesso dedicated hw of the two it will be ? so we can come to a conclusion before the end of meeting
JollyMort[m]Jaquee: would it be too much effort to add the import/export stuffs into gui
msvb-labdEBRUYNE: Let's close off hw wallets now, but everyone please add a post to the FFS if you have a strong opinion.
msvb-labThanks for the floor folks!
JollyMort[m]would be nice to avoid depending on the CLI to fix cold signing glitches
dEBRUYNEAll right, I'll leave a comment later msvb-lab :)
JollyMort[m]and some use cases require import/export stuffs
dEBRUYNEI personally wanted to raise the idea to release more often (e.g. a new release every quarter) to (i) tighten and improve the feedback loop and (ii) decrease time spend on helping out people that incur issues that are already long fixed in master
JaqueeJollyMort[m]: not that much effort. problem is that code is frozen in monero. so wont make into this coming release
dEBRUYNEI spoke with fluffypony about this in private and he was concerned it would put too much pressure on contributors
JollyMort[m]:(
dEBRUYNESo I'd like to hear their opinion about it
Jaqueei added some improvements yesterday
dEBRUYNEI guess I should mainly page Jaquee, moneromooo, hyc, iDunk
JollyMort[m]i saw, haven't tested it yet
dEBRUYNE\^ apologies if I forgot someone :P
hyc"release early, release often"
JollyMort[m]i'll check it out
moneromoooI think it'd put too much pressure on the pony.
dEBRUYNEhyc: Right, that was kind of my basis for the idea
Jaqueei'd love to release more often
hycI think having another interim release would be nice
moneromoooHe barely has the time to do anything AIUI.
dEBRUYNEmoneromooo: Could this be mitigated if we had an additional maintainer?
endogenici think it's funny when people say "fail fast"
fluffyponywe need to bear in mind that this is security software
dEBRUYNEI think luigi wanted to do an FFS soon for it
moneromoooWho would you trust which can do it ?
moneromooohyc!
moneromoooflees
hyc:P
dEBRUYNEWell luigi could merge stuff and FP release?
fluffyponyI don't think we should be pushing to release unstable software :-P
DaveyJoneshyc or the luigi1115
fluffyponyan additional maintainer won't make software magically stable :-P
hyctrue
dEBRUYNEfluffypony: No, but it would take time away that you have to spend on merging and reviewing stuff
ferretinjapanI'd just like to say that a backup maintainer should be seriously considered, even if the release schedule stays the same, there's nothing like redundancy…
fluffyponywe need way more eyes on PRs than that
fluffyponyferretinjapan: we already have backups
dEBRUYNEAlso, those large merging waves inhibit the momentum of the project imo
ferretinjapanah, goodo
medusathe lack of follow up bugfix releases causes huuge amunt of support work
fluffyponythe Core Team have access, and luigi1115 is my direct backup
fluffyponymedusa: we've already solved that
medusahow?
rehrarWhat if one release added content, and the intermin is just bug fixes?
fluffyponywith the branch
dEBRUYNE<fluffypony> I don't think we should be pushing to release unstable software :-P <= Not saying we should, but if master is deemed stable we could put out a release with a few new features right?
medusaso this time we going to have a follow up release 100% ?
medusalike 2 weeks later
fluffyponymedusa: it depends on if there are bug fixes
dEBRUYNEThere are always bug fixes
dEBRUYNE:P
medusawell depends on severity i agree
medusaof the bug
ferretinjapandEBRUYNE, what about early beta releases? Say just before the freeze?
JollyMort[m]for one thing, i would love to see cold signing stuffs added asap; feel like it's an important feature to those who don't want to use CLI for the same thing
JollyMort[m]and be able to resolve any problem people may have by using GUI functions
ferretinjapanor an "experimental" release?
hyccan we just get people to use a nightly build, for bugfix verification?
dEBRUYNEferretinjapan: That seems suboptimal, as there would be new binaries a few weeks later
bigreddmachineIsn't that what the nightly builds are?
hycand then at some point we can decide if we have something stable enough for another release
medusaif we potentially want to keep the branch that long, we should also slow down with merging stuff in trunk (especially 0mg)
medusauntil we can estimate the quality of the branch somehow
fluffyponyjust looking at the recent releases, I don't think there have been a lack of them
fluffyponySep 19, 2016: 0.10.0
fluffyponyDec 13, 2016: 0.10.1
fluffyponyFeb 23, 2017: 0.10.2
fluffyponyFeb 24, 2017: 0.10.2.1
fluffyponyMar 26, 2017: 0.10.3
fluffyponyMar 26, 2017: 0.10.3.1
medusaotherwise we risk, dpeending on buigs we have after release, to end up in a hairy position
hycso it sounds like release-as-needed is working
fluffyponyyeah, I'm not really seeing a lack of releases there
moneromoooespecially on march the 26th.
hycheh
JollyMort[m]release density == nan
ferretinjapanThe last 5 months have been rather quiet, but I don't think it's all bad.
medusathose 1d releases dont yount
medusathey fix emergency stuff
ferretinjapanYou guys were busy with making sure ringct was solid after all…
medusawe talk about follow up releases, with 2 weeks in between
medusawe enever do that
ferretinjapanand then there was that bug…
hyc2 weeks seems too soon for a scheduled followup
bigreddmachineQ before meeting is over. What kinds of things need to be studied on the PoW change proposal? I'm happy to dig into that but would like some direction if possible.
hycand 5 months since the last release seems too long
endogenicbidreddmachine: what problem necessitates that?
dEBRUYNEhyc: If the release merely intends to fix bugs of the latest release, is two weeks too soon?
endogenicthe PoW change
hycdEBRUYNE: I presume bug fix releases go out as soon as available
dEBRUYNEBut we haven't done that in the past
hyce.g., for emergency fixes
dEBRUYNEThat's the issue medusa is raising
hycotherwise, if it's not urgent, 2 weeks seems short.
msvb-labhas the meeting officially ended, one hour right?
fluffyponywell in the past 5 months we haven't really been able to release stable + bug fixes
DaveyJonesafaik the GUI had/has a bug that freeze's the wallet on some system thats already fixed but never got released … thats what your talking about medusa?
bigreddmachineendogenic: some things were raised in the thread on GitHub. I wouldn't be going into it saying "this needs to happen" but rather trying to dissect the potential issues and see if there is anything to be gained.
fluffyponybecause we didn't branch
fluffyponynow we branch
fluffyponyso it seems like we're discussing something we've already fixed…?
dEBRUYNEDaveyJones: Yes, which causes a lot of support issues
medusawell we expect you to be around and build a bin
medusaif thats all fine that its all good
hycyeah sounds like it's fixed already
dEBRUYNEfluffypony: For the GUI, for example, we're still helping people that incur bugs from GUI beta 2
dEBRUYNEThat were fixed a week after the release
hyc3 months from now we can raise the question of an interim release if there haven't already been a slew of releases
fluffyponydEBRUYNE: I know what the issue was, hence the branching thing
medusaits also a time and tacting thing
medusaif we plan to let the branch live that long you will need to thread the trunk differently
dEBRUYNEfluffypony: So if I understand the branching correctly, we'll release from the branch and if too much annoying bugs are found in the release version, we'll do a follow up point release to include fixes?
medusait has a lof of effects
msvb-labnetsplit for me i guess…
bigreddmachineWith branching now, couldn't we just have monthly release candidates or something?
fluffyponydEBRUYNE: yes - follow-up releases are based off the branch
rehrarI know we're already over, but can we get a brief update regarding Sarang's FFS?
moneromoooHow about we don't spam the pony yet ? Let's wait, and maybe do a release from the branch if there are bugs we want fixed.
fluffypony@bigreddmachine no need to timeframe it, we'll release when there are bug fixes part of the branch that make it worth releasing
fluffyponyie. major bug fixes
hycagreed
bigreddmachineFluffy, I just meant a pseudostable branch that's a bit more tested than the nightlies.
dEBRUYNE<fluffypony> dEBRUYNE: yes - follow-up releases are based off the branch <= All right, well, let's see how that will go then
fluffyponynot spelling errors or whatevs
bigreddmachineBut not an actual release.
bigreddmachineMaybe that's a "2 years down the road" thing
fluffypony@bigreddmachine you mean off the main branch or the release branch?
moneromoooWe tried that before, it was a massive pita.
hyccan the build system do nightlies of the release branch too?
fluffyponyhyc: pretty sure, yeah
bigreddmachineI meant as its own branch… Commits get tested, when somewhat sure moved to release candidates, which is still unstable, and then when that's tested moves to the actual release. Probably a pita like mooo said
fluffyponypigeons1[m]: ^^
fluffyponyyeah complete PITA
bigreddmachineOkay just brainstorming
pigeonsyes, i'll setup jobs for the release branch
hycthat ought to be good enough then as far as release candidates go
fluffyponyre: sarang, pero were your questions satisfied?
pizzasushibeerAs a supporter of Ledger see nothing wrong with the community funding a 2nd hw wallet initiative. More options are beneficial and im sure many of us already own multiple Bitcoin hw wallet types for a variety of reasons
DaveyJonespero is rarely available this week @ fluffypony
dEBRUYNEfluffypony: I think sarang was rewriting the proposal, but I am not sure if he has finished yet
fluffyponyok
pizzasushibeerIf the community is willing to fund, it I see nothing wrong with moving proposal to funding required (after any more required clarifications are made)
sn0wmonsteri think i'm gonna bother these guys to make a patch for their box for Monero http://bitseed.org/
sn0wmonsterwrong channel
pizzasushibeerI would help contribute to the hardware wallet proposal. Im sure others agree
pigeonsif pero's questions aren't answered maybe post a forum reply reminding him that so sarang can see clearly its outstanding still
hycyeah I recall pero was going to be unavailable for the next week or two
ferretinjapanpizzasushibeer, I'm another person and I agree.
scoobybejesussarang was about to post clarifications to his ffs a couple times recently. it's been mentioned more than once on #mrl
hycok, we're 25minutes over. any more stuff?
dEBRUYNEGuess not :-P
DaveyJoneswould it be possible that -site maybe gets an additional maintainer ?
DaveyJonesafaik it less to no coding stuff and maybe people like dEBRUYNE or rehrar would be able to maintain it… so no need to bother you fluffypony ^ ^
fluffyponyDaveyJones: we're working on alternatives, probably doing something based off issue helper
DaveyJonesfine :)
JollyMort[m]binaries and .raw downloads are high-sec
fluffypony^^
rehrarYe. Responsibility is scary.
fluffyponyso issue helper could be used to trigger merges where it doesn't touch sensitive parts of the site
rehrarDude, that's awesome.
rehrarFor all those little merchant merges
DaveyJonesyeah i had things like merchants in mind
dEBRUYNEAnd then we could give the issue helper trusted community members access to the issue helper right?
dEBRUYNE\^ fluffypony
rehrarWe eventually should drop support for Merchants on the site tbh imo
fluffyponydEBRUYNE: yes
fluffyponyrehrar: why?
moneromoooIt's a good, if small, incentive for people to support monero.
moneromoooAnd for connecting monero spenders with monero earners.
rehrarAs Monero grows it will become gigantic eventually, but maybe that's not a huge issue.
rehrarJust my thoughts.
hycsuccess problems are nice to have. we're not there yet
moneromoooOh, sure. Once Monero's world reserve currency, it can go :)
DaveyJones\^ but only then
dEBRUYNEfluffypony: All right, seems cool. That'd also relieve you from some "low hanging fruit" work
dEBRUYNEWhich still can be quite time consuming
fluffyponyyup
DaveyJonesbut maybe we should put up some kind of Disclaimer
DaveyJonesin case some service goes rogue
sn0wmonsterwhich judging by bitcoin's history, is not a matter of if, but when
DaveyJones"this is just a list of merchants, and no appraisement by the core team"
rehrarI'm actually going to be going g through all the Merchants this week to find the dead websites.
moneromoooWarning: the monero team does not control Amazon, odd as it might seem to you.
pigeonscryptokingdoms
pigeonsfor example
moneromoooCK's kinda back from the moribund actually.
pigeonsok
rehrarMeeting = end?
DaveyJonessure
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-08-20, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.