Bitcoin Unlimited developer meeting 6 June 2017

20170606_dev_meeting_004_formatted.txt

BU development meeting 2017/06/06 slack log
===========================================

redmarlen 2:57 PM
joined release_admin by invitation from @thezerg

Pinned by kyuupichan

thezerg 2:58 PM
Here is 1.1 release checklist:
1. Kyuupichan to review PV
2. Fix unreliable extended regtests
3. ptschip PV bug
4. ptschip xthin rerequest
5. thezerg optionally: redundant mode
6. thezerg https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues/170
7. change script checking in the past from time to # blocks
8. fix nolnet
9. BUIP055
.
Any other topics for today?

ptschip 3:00 PM
how about thinking about a new point release once all the backports get done?

kyuupichan 3:01 PM
And if we do that, please let’s make it the last of that branch

thezerg 3:01 PM
I'm not against it.  What are the compelling features/fixes?  Xthin rerequest?

kyuupichan 3:01 PM
Reliability I think.

ptschip 3:02 PM
xthin, plus i'd like to get in 641 and 646...also SENDHEADERS is already backport to release

kyuupichan 3:02 PM
And nolnet?

ptschip 3:02 PM
yes

sickpig 3:02 PM
yes and nolnet

kyuupichan 3:02 PM
So incremental robustness + nolnet seems to be the rationale

thezerg 3:03 PM
Ok, let's plan on a release next week.  That should give us time to ensure that nolnet is working and fix the seeder issue

sickpig 3:03 PM
seeder is fixed

thezerg 3:03 PM
great!

ptschip 3:03 PM
what was fixed, was the the return of the list of xthin nodes? (edited)

sickpig 3:04 PM
ptschip no

ptschip 3:04 PM
k

thezerg 3:04 PM
anyone verify that after 20 min the diff actually goes down to 1?

sickpig 3:04 PM
I was unable to get it working with the new nol net

kyuupichan 3:04 PM
Not yet… lol.  Too many blocks

freetrader 3:04 PM
no, didn't verify, but could do so on private nolnet

thezerg 3:04 PM
@freetrader, that would be very helpful

sickpig 3:04 PM
the preferential "peering" at dns seeder is the next task on my todo list

ptschip 3:05 PM
great

kyuupichan 3:05 PM
If we want to check the diff on nolnet we could ask checksum0 to ramp the diff to I dunno, several hundred, which he can in no time, and then see.

freetrader 3:05 PM
I have another agenda item related to BUIP052 -- dedicated CI - implementation going forward. (edited)

thezerg 3:07 PM
I can ramp the difficulty also, but I think its fine to manually check this on a private nolnet
@freetrader, what is your other item?

kyuupichan 3:08 PM
OK

freetrader 3:08 PM
@thezerg: basically, what's the next step toward getting a dedicated CI box for the full-suite (and whatever else, e.g. fuzzing, coverage) tests we'd like to do
I'm assuming it would be problematic to do this on a separate Travis account even if we got one
because one .travis.yml file
we need ability to configure the broader CI radically differently in terms of tests

sickpig 3:09 PM
@freetrader agreed

freetrader 3:10 PM
something like a hosted Jenkins instance would probably be good.

thezerg 3:10 PM
could we have a separate branch with one file changed?

sickpig 3:11 PM
@thezerg there's no way to have evrything running on travis without hitting the timeout (edited)

freetrader 3:11 PM
There's no way I know of to pull in the .travis.yml file from somewhere else (to override it) before it gets processed
And yes, the timeout is the killer.

sickpig 3:12 PM
take the extend functional test, e.g. pruning it tooks 30-40 min a pretty fast machine alone

thezerg 3:12 PM
I'm not advocating a particular approach, but certainly you could have a branch or even a fork repo.  Travis will still time out if we pay them more?

ptschip 3:12 PM
not sure if this makes sense but what about just running 1 random extended test every time we run a PR through? at least get some coverage.

sickpig 3:13 PM
wrt travis: you could pay whatever you want 120 min timeout is te max you will have

freetrader 3:13 PM
@ptschip: hard to form a good picture of overall status if you do it piecemeal.

sickpig 3:14 PM
@ptschip I think the plan is run all the extended tests, plus coverage, plus fuzzy tests once a day

ptschip 3:14 PM
k

thezerg 3:14 PM
@freetrader, I think that the passage of BUIP052 and your past experience gives you some authority to make a proposal and bring it to us and @solex.  Do you want to do that?
and also talk to @awemany about fuzzing

freetrader 3:14 PM
Such workarounds (choosing sets of tests which don't time out and could be randomized) might work.
However, the BUIP stipulated clearly - separate dedicated CI box , to avoid all this hassle

sickpig 3:14 PM
and have some sort of dashboard to expose the results (edited)

freetrader 3:14 PM
@thezerg : ok, I'll research options there.
Within the price range proposed by the BUIP.

thezerg 3:15 PM
great
I also have a spare machine that could run tests once a day here.  But it would have to be very automatic

freetrader 3:16 PM
We should add make targets , these are easy to slot in anywhere
I'm also getting a faster dev box, hopefully freeing up one here on which I could run those tests daily too.

thezerg 3:17 PM
I'm suggesting devs in addition to a dedicated service

freetrader 3:18 PM
Yes, me too.

thezerg 3:18 PM
ok great
so on the 1.1 checklist we basically knocked off 8 and 4
and 1 and 9 are in progress

sickpig 3:19 PM
one minor point to add if I may: @redmarlen's PRs (edited)

ptschip 3:19 PM
3 , no progress, maybe this week will have time

thezerg 3:19 PM
ah, yes I invited him here actually

freetrader 3:20 PM
2. Fix unreliable extended regtests
I checked bip9-softforks still had a problem after the recent 'bad-prev-blk' fixes were made for nolnet
I think the regtest problems are mostly related to BU deviating from p2p orthodoxy (edited)

thezerg 3:20 PM
I don't have them in the checklist because they are not required.  But I would be very surprised if we didn't get them in

ptschip 3:20 PM
@freetrader did you try PR 650? for bip9-sof... (edited)

sickpig 3:21 PM
and my usual reminder (if I may) make AD/EB effective without the need to restart the node and also make BU reconsider the fork it is monitoring if the change of EB/AD impose this

thezerg 3:21 PM
that's #6
no progress today, sorry
I'll be back in 5min keep talking

sickpig 3:21 PM
wooops

freetrader 3:22 PM
@ptschip : I don't think so, I'll try PR650

sickpig 3:22 PM
sorry @thezerg didn't see that

kyuupichan 3:22 PM
I’m working on parallel review / improvements; it will take time.  Expedited reviews of parallel-related PRs would be appreciated!  It makes it much easier to progress.

ptschip 3:23 PM
@kyuupichan your 640 i think looked good...haven't got to the others but will in the next few days.

sickpig 3:23 PM
@freetrader I've checked abandonconflict.py and it still have problem.. ti failed after the 4 of 5th iteration (tested with yesterday dev) (edited)

thezerg 3:27 PM
so not much to discuss today... its a good thing :slightly_smiling_face:
any other topics?

freetrader 3:27 PM
I'll need to do some more runs with recent networking changes. Thanks for the feedback.
I think the PR 652 might also help.
https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/652

thezerg 3:27 PM
are classic and XT going to implement BUIP055?

sickpig 3:28 PM
who knows

freetrader 3:28 PM
Are we going to release a revised spec for it ?

ptschip 3:28 PM
i thought xt was going to do something with bip100....but i don't know.

sickpig 3:28 PM
@ptschip I had the same impression

freetrader 3:29 PM
me too :  XT wanting to go with BIp100 after the bump to 8MB

thezerg 3:29 PM
my issue with the BIP100 PR is that it changes the format of the blockchain header database
so if you switch from core to BU or back you have to reindex
what do you guys think about forcing people to do that? (edited)

freetrader 3:30 PM
can you run on existing BU datadir without re-index?

sickpig 3:30 PM
is it unavoidable?

ptschip 3:30 PM
well if reindex took 5 mins that would probably b ok, but how long does it take now? probably not very fast.

sickpig 3:31 PM
reindex takes forever

thezerg 3:31 PM
took me days last time I tried it

freetrader 3:31 PM
is it not possible to just migrate the data using a special program?

thezerg 3:32 PM
the issue is that BIP100 wants to store voting data in the header blockchain
it would probably be better to have a separate database

sickpig 3:32 PM
what's the alternative? the coinbase? (edited)

thezerg 3:32 PM
its already in the coinbase

ptschip 3:32 PM
i mean there must a short cut...in this case...we have already the correct UTXO and blockchain verified...all we need is to update the index..shouldn't take long but would require some new code

thezerg 3:32 PM
it extracts from the coinbase and writes it for quick access into the header database

kyuupichan 3:33 PM
Sorry 5 mins behind the chat, but I’d rather avoid having to use a different DB for switching clients, until the current fork is resolved.

thezerg 3:33 PM
if you had a separate database, it could be sparse tolerant.

freetrader 3:33 PM
this should be an extract-to-different-DB migration step
if the extra DB is not there, sorry - option disabled

ptschip 3:34 PM
agree

thezerg 3:34 PM
so look up in separate DB, if its not there, load the block from disk, extract the vote and write it to the db

freetrader 3:34 PM
yeah

thezerg 3:34 PM
ok you know I just thought of that solution, I'll annotate the PR now (edited)

sickpig 3:34 PM
but if XT is going to take the BIP100 root after we forked, the problem is less "problematic", no?

thezerg 3:35 PM
really?  post fork?

sickpig 3:35 PM
this what @freetrader said

freetrader 3:36 PM
@sickpig : why less problematic? (for BU to implement it) ?

sickpig 3:36 PM
and if I have to be honest this what I rember form what @dgenr8 said yesterday
less urgent <--- @freetrader (edited)

freetrader 3:36 PM
I agree on low urgency
BUIP055 is much more important now

sickpig 3:37 PM
me sometime I really struggle to find the right adjective

freetrader 3:37 PM
https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/654

sickpig 3:37 PM
WRT BUIP055

freetrader 3:37 PM
@deadalnix submitted anti-replay PR (edited)

sickpig 3:37 PM
exactly was saying this

freetrader 3:38 PM
he asked me yesterday which branch , I said I don't know, so he said he would do both
but now he should rather do buip055 branch? (edited)

sickpig 3:39 PM
is buip55 a clone of dev? (@thezerg) (edited)

thezerg 3:39 PM
clone of dev plus some code
is there more stuff in #654?
and yes #654 should be targeted to buip055 branch, but I can move it there myself if @deadalnix doesn't want to

sickpig 3:42 PM
@deadalnix you on line ?

freetrader 3:42 PM
https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/b065195e2fb09e2827c724bf5a94c8283d087a69
'wip' ?

thezerg 3:44 PM
this is a working branch to put buip055 changes into

freetrader 3:44 PM
I'd suggest to revert that last one and do things via PRs
otherwise we lose even Github's rudimentary review functions (edited)
since no-one has used the branch yet, should be easy to start from a clean 'dev'

thezerg 3:45 PM
my intention was to issue the PR when buip055 -> dev

sickpig 3:45 PM
wouldn't it be to big to review then ?

freetrader 3:45 PM
yes. This isn't going to be small.
We need to review on the branch until its ready.

ptschip 3:46 PM
makes sense (edited)

freetrader 3:46 PM
PRs or at least atomic commits, please.

sickpig 3:48 PM
@freetrader agreed

thezerg 3:49 PM
@freetrader, do you want to run a branch in your own repo with PRs and then issue a PR to BU when its ready?

freetrader 3:50 PM
how would that work?
have the buip055 be a dirty branch, and then mangle that back into PRs for 'dev' directly ?
I think we need a branch for BUIP055 that is cleanly maintained.

thezerg 3:51 PM
make a branch in your repo, people submit PRs to it.  you merge them.  then when its ready issue a PR that merges that branch into BU

freetrader 3:52 PM
is there an upside to this roundabout way instead of developing BUIP055 on the BU repo ?

sickpig 3:54 PM
fwiw I could volunteer to maintain a BUIP055 branch on the official repo  used to develop a clean and review-able process...

freetrader 3:55 PM
if others want me to do it by maintaining such a branch on my repo, I would do it.
I just don't understand the rationale behind it.

sickpig 3:55 PM
I see more value in having the buip055 branch on the official repo rather than an external one

thezerg 3:55 PM
the purpose is delegation

sickpig 3:56 PM
afk for 20 mins sorry

ptschip 3:57 PM
agree, i think it's a good idea, not ideal, but gets rid of a merging bottleneck and @thezerg can get focus on other things (edited)

thezerg 3:58 PM
@freetrader, you wrote a careful spec, do you want to shepard the process of implementation through?

freetrader 3:59 PM
The 'shepherding' requires a lot of decisions which are required from project lead.

kyuupichan 3:59 PM
shepherd :slightly_smiling_face:  respect for the sheep

freetrader 4:00 PM
@thezerg : as I wrote above, I'm willing to maintain a branch on my repo and feed PRs to BU
as long as this is a process others want to follow.
I consider it not optimal.

deadalnix 4:01 PM
Sorry I has a last mintue thing to deal with
@thezerg I can base that on anothe rbranch no problem
However, i would advice against basing thr BUIP055 on master per se, there is too much doubtful stuff in master.

freetrader 4:02 PM
I liked the idea of trying to dev this HF against both branches, because of BU instability

deadalnix 4:02 PM
I would also advise against creating a ton of different branches

thezerg 4:04 PM
"dev" is targeted to be released around midsummer (edited)
to become the "release" branch
while there are certainly bugs in dev AND in release, we need to move forward
so let's find and fix them
If you want to make the argument that dev is fundamentally, structurally significantly more bug prone than release, then I'm all ears, but please include some example bugs.

deadalnix 4:06 PM
Sure, making more branches doesn't help solve this however.
In fact, quite the opposite

freetrader 4:07 PM
let's also get the spec issues resolved.
BUIP repo.
Some people have commented, but far too few.
I believe @sickpig needs input to decide on what to merge in.
https://github.com/BitcoinUnlimited/BUIP/pull/31
https://github.com/BitcoinUnlimited/BUIP/pull/32
https://github.com/BitcoinUnlimited/BUIP/pull/33
https://github.com/BitcoinUnlimited/BUIP/pull/35
https://github.com/BitcoinUnlimited/BUIP/pull/36 (edited)

thezerg 4:07 PM
the buip055 branch will only exist for the duration of the buip055 development (edited)
yes links would be great

deadalnix 4:08 PM
Listen, I did 3 release a day for the past 4 years? i know one thing or 2 about this. I'm telling you this is a bad idea. How many SNAFU does BU need until you are able to take an advice ?

thezerg 4:09 PM
your advice is abandon "dev" on your blanket say so?

deadalnix 4:09 PM
No.
My adive is to continue dev in dev and back port into release and not start a 3rd branch
The situation is bad enough with deiverging that much from release.

freetrader 4:10 PM
If buip55 is made an option, this is no problem (dev in dev)
None of the code should interfere with current code unless the option is activated.

deadalnix 4:13 PM
https://en.wikipedia.org/wiki/Continuous_integration
Wikipedia
Continuous integration
In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. Grady Booch first named and proposed CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

freetrader 4:14 PM
I would also strongly advise moving from a completed spec to an agreed upon design first, before jumping to implementation.
And parallelize test development with implementation, otherwise there isn't enough time.
It shouldn't be a problem once the design is clear.
Planning and design pays off hugely.

deadalnix 4:16 PM
Well we can have the implementation start at the same time the spec is fleshed out. If the spec change we can tweak the implementation. For part of the spec that are still under a big ?, we can indeed delay.

freetrader 4:17 PM
sure - there are some areas that are already fairly clear and should begin.
but I give up on my design, it seems the distinction between spec and design is unclear to many. (edited)

ptschip 4:17 PM
agree , we need to keep this moving

sickpig 4:18 PM
@freetrader what do you mean with "your design"?

freetrader 4:18 PM
the idea of discussing and agreeing on a design before we implement it.
and no, the spec is not the design.
if we think this is simple enough to 'wing it' without discussing the design, I'm fine for BU to do it like that. (edited)

sickpig 4:18 PM
ok, got it.
so what's the plan about BUIP055 then?

deadalnix 4:20 PM
flesh out the spec, decide on the points that are unclear ATM, and implement the points that are mostly fleshed out in //
merge against dev, cherry pick into release.
Do not merge anything that do not have test for the gating code.

sickpig 4:21 PM
so we are going to make buip055 as an option?
-bip55? (edited)

freetrader 4:21 PM
i detected favor for that when it was suggested to change back from 'UAHF'  to 'BUIP055'

deadalnix 4:21 PM
@sickpig even if it is not an option there is some activation code for the feature

freetrader 4:22 PM
see, now we are talking about design :stuck_out_tongue:

deadalnix 4:22 PM
when you dev the feature, you put it behind a flag and test that you get an error when using the feature and not using the flag

sickpig 4:22 PM
@freetrader ahahahhahaa

deadalnix 4:22 PM
@freetrader yes but that was the question

sickpig 4:22 PM
@thezerg @ptschip @kyuupichan what's your take ? (edited)

deadalnix 4:22 PM
you can dev the feature and dev what set the flag in //
you can even delay one of the 2 if the spec is not fleshed out enough.

freetrader 4:23 PM
from a spec POV : do we want to make it a requirement to allow the user to specify forktime, new EB/MG ?
because current spec doesn't require it.

sickpig 4:24 PM
freetrader isn't the point of BUIP055  to have a flag day/block?

freetrader 4:25 PM
i take it we don't want to implement the fork-on-block-height as well?
or do we?
if so, someone please do a PR

sickpig 4:25 PM
MTP / date is ok for me

ptschip 4:25 PM
i thought it was pretty clear we were going with date...

sickpig 4:25 PM
my point was that be it a a time or a block height we have it hard coded, am I wrong?

freetrader 4:26 PM
subject to discussion. It was already suggested in the other channel to make it a command line option.
sth like `-buip55=<timestamp>,<new EB>,<new MG>

ptschip 4:26 PM
i also thought it was something asked for and needed.

freetrader 4:27 PM
Who needs it?

sickpig 4:27 PM
ok

ptschip 4:27 PM
miner

sickpig 4:27 PM
does this triplet have default values?

freetrader 4:27 PM
They didn't suggest this openly in the discussion, it was proposed by us. It might make sense, but this is the sort of input we need...

sickpig 4:27 PM
(sorry if asking stupid question)

ptschip 4:27 PM
not sure though i like it  entirely because then there is a chance of opting out easily

freetrader 4:28 PM
@sickpig: yes: August 1, 8MB, 8MB

sickpig 4:28 PM
@freetrader great

freetrader 4:28 PM
we might not need the MG because current spec (or PRs to it) propose to set new MG to = new EB
which would make it only two parameters, date and new EB

thezerg 4:29 PM
as per the BUIP, and BU philosophy of choice, it needs to be an option

ptschip 4:30 PM
@freetrader are you saying we should get rid of MG...i thought after the fork MG=EB but that's just for time of the fork.?

freetrader 4:32 PM
@ptschip: no, merely that the default would be to increase MG to equal EB at fork time, and if '-buip55' option is given, the client would check at startup that EB is at least 8MB.

ptschip 4:32 PM
good (edited)

freetrader 4:33 PM
Miners would configure their EB=8 MB
and the fork activation would wait for a block > 1MB and <= 8MB (actually, the <= is still a PR to be decided)
https://github.com/BitcoinUnlimited/BUIP/pull/31

ptschip 4:35 PM
why would they have to set EB=8 specifically...why not have MG =8 at forktime and EB>=8 if they want to...not sure why they need co-ordinate at EB8 (edited)

freetrader 4:36 PM
[omitted for privacy] stated several times that there is some sort of willingness to go to 8MB . Could be they agreed on this.
They can still increase their EB / MG easily after the fork.

ptschip 4:36 PM
ok sure, but i think any miner should still be able to use whatever EB they want...just at forktime they will autmatically get bumpted to MG8 EB8 at a minimum. (edited)

freetrader 4:37 PM
Relay nodes can use whatever EB they want.

thezerg 4:37 PM
its important for dissenting miners to be able to produce 1MB or 0MB blocks to reduce the average block size

freetrader 4:37 PM
If miners disagree with the spec, they need to give more inputs.
Directly after the fork block, they can reduce their MG to 1MB if they wish.
This is not impeded by the spec and the hypothetical design.

ptschip 4:38 PM
ok sound reasonable...

freetrader 4:39 PM
There is no requirement on the sizes of blocks after the fork.

ptschip 4:39 PM
good

freetrader 4:40 PM
its important for dissenting miners to be able to produce 1MB or 0MB blocks to reduce the average block size
@thezerg: do you think dissenting miners will run this fork ?
I think if, then only to attack it...

thezerg 4:42 PM
I am always focusing on a majority or soon-to-be-majority fork

freetrader 4:42 PM
the more features which are not optional, the more potential to dissent. (edited)

ptschip 4:42 PM
i think the miners are going to be focused on their bottom line  and will decided quickly which way the wind blows. (edited)

thezerg 4:44 PM
but what I meant was a miner that was somehow limited to X MB blocks on average (say by bandwidth restrictions) could bring the average down by mining X/Y MB blocks.  But that miner would still get the block reward and the highest paying txns so would not be that uncompetitive with a miner that fills the blocks
so a miner dissenting on the exact large block size not a 1MBer (edited)

ptschip 4:45 PM
yes true, the chance of orphaning increases depending on relative block size, i remember someone doing a study on that...which is incentive for the miners not to diverge too far fromm the mean. (edited)
i think it actually peter todd that did that study...sorry  to bring up that name.
(sorry maybe talking about diff things here)

redmarlen 4:48 PM
@freetrader you mentioned earlier you have questions related to my PRs?

freetrader 4:49 PM
no

sickpig 4:49 PM
@redmarlen it was me
imho we need to find a way to have your PR developed against dev rather than the ad hoc cltv branch
but let's talk about it later once we settle the other points

ptschip 4:52 PM
I feel like our meeting is fizzling out here, are we done or is there anything else?

freetrader 4:53 PM
i offered to thezerg to keep a branch on my personal repo, on which I would merge PRs for BUIP55 that others submit.
So, am I to submit PRs to BU's 'dev' branch based on those ?
I'm not sure I fully understand the process @thezerg wants to follow.

sickpig 4:54 PM
neither do I

ptschip 4:56 PM
he must have stepped away for a few mins...

sickpig 4:57 PM
could be
wait for him to chime in and to wrap up the meeting or continue it if we have other points

redmarlen 4:59 PM
re PR 653 I don't think it needs reviewing since PR 521 will bundle the review

sickpig 5:05 PM
@thezerg you around?

freetrader 5:11 PM
can someone try to reach him on another channel?

ptschip 5:12 PM
i've pinged but no answer...i'm have go for 20 mins or so.

sickpig 5:17 PM
pinged on wechat

freetrader 5:22 PM
I'll open a branch on my personal repo and announce further steps in the relevant channel(s)
then we can decide on a good workflow.

sickpig 5:23 PM
so the dev of buip55/hf will happen on branch locate at one of @freetrader's repo (edited)
so far we discussed also about a minor release (1.0.3) to have the next week
do we have a list of PRs that we want to be in/backported  before tagging a release ? (edited)

ptschip 5:25 PM
i'll feed the list of backports and pr's we need for that to @thezerg , already started....current release backports of course, then the xthin patch and also i thought 641 and 646...any others you think we need?

thezerg 5:26 PM
hi sorry

ptschip 5:26 PM
also 608 i'll include in the xthin backport as i'll need that

thezerg 5:26 PM
some people came to install solar
I have to help them

ptschip 5:27 PM
don't fall off the roof...

sickpig 5:27 PM
@ptschip the nol patch from @kyuupichan

ptschip 5:27 PM
right forgot that
oh that's already one of the release backports

sickpig 5:27 PM
yeah

thezerg 5:28 PM
WRT BUIP055, I would like freetrader to create a working branch in his repo and review and pull in PRs in the normal fashion with my and other people's input
when BUIP055 is 90-100 percent done we merge to BU dev
we will not need such an exhaustive review at taht point since stuff has already been reviewed going into @freetrader's branch
yes this is not daily CI

freetrader 5:29 PM
This branch will run on Travis.

thezerg 5:29 PM
but daily CI means that I spend all day every day merging your stuff
this is a problem
additionally, much of this work will and should be isolated

freetrader 5:30 PM
why don't you delegate merge responsibility on BU ?

thezerg 5:31 PM
step by step @freetrader
esp since you value your anonymity, I can give a final merge a quick once over to ensure that some backdoor hasn't been injected

freetrader 5:32 PM
it's not an aswer to a "why" question, and my question was not application, in case you mistook
My opinion is that there are capable non-anonymous persons around who would like to help you.

thezerg 5:33 PM
I am delegating merge responsibility here, just not following the exact git recipe that some of you would prefer (edited)
instead, let's try this recipe for now

freetrader 5:33 PM
Well, I'll do my best to help you on this
Others will let us know if it's working or not.

thezerg 5:34 PM
yes, thanks!

sickpig 5:34 PM
@thezerg this is your call. But I can't see the diff to delegate someone to curate a branch and only one branch on the repo with the solution you propose. There's a diff, the work flow is more complicated.
but as I say is is your call. (edited)
I'm ok with your decision, just want to express my view on that. (edited)

freetrader 5:35 PM
w.r.t. review, I cannot be sole reviewer of those PRs to the branch, but we need to set ourselves a target of time.
if you expect daily merges, that means review has to happen daily.

thezerg 5:35 PM
let us use the same review technique we use on BU
so people need to be reviewing and approving eachother's work
its not freetrader's responsibility to review everything

freetrader 5:36 PM
Not sure if I have to set up something on my repo to facilitate this Approval workflow
If you needed to set up sth for BU repo to get that, please let me know so I can adjust my repo.

sickpig 5:36 PM
@freetrader I think is standard github workflow

freetrader 5:36 PM
ok

sickpig 5:37 PM
now we just need to remember to look to at your repo :stuck_out_tongue:

thezerg 5:37 PM
people can always just add "I approve" comments if there is any github issues

freetrader 5:37 PM
@sickpig: oh, i'll remind you :slightly_smiling_face:

sickpig 5:37 PM
I'm going to watch it so that I'll receive notification  emails (edited)

thezerg 5:37 PM
ok shall we close the meeting out for today?

sickpig 5:38 PM
do we have discuss everything ?

ptschip 5:38 PM
@freetrader can you post a link to your repo
nothing else here...

sickpig 5:39 PM
https://bitcoinunlimited.slack.com/archives/G3R162XK8/p1496753931238844
thezerg
1. Kyuupichan to review PV
2. Fix unreliable extended regtests
3. ptschip PV bug
4. ptschip xthin rerequest
5. thezerg optionally: redundant mode Show more…
Posted in #release_adminYesterday at 2:58 PM

thezerg 5:39 PM
that is the 1.1 TODO list, we don't have to hit every topic...

sickpig 5:39 PM
what about issue 170?
nolnet seems fixed
I suggested to @redmarlen to split is big PR in small ones

freetrader 5:40 PM
another point: what about bu-dev mailing list
can we all subscribe to there if we haven't, as a form of continency comms channel for development (edited)

sickpig 5:40 PM
and submit them separatelu against dev
there's news
jsut a sec need to find a link

thezerg 5:41 PM
I've been reviewing and helping redmarlen during the process on a branch

sickpig 5:41 PM
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ng

thezerg 5:41 PM
and his work is not P2P -- its GUI transaction features
what news?

sickpig 5:42 PM
see the link above
we have a mailing list hosted at the linux foundation
jeff garzk helped
it is something we could use with Classic and XT
we also have a Bu specific one that I set up two weeks ago
but I don't thing we need to have two

freetrader 5:43 PM
is our current bu-development deprecated?

sickpig 5:43 PM
the one hosted on google group ? (edited)

freetrader 5:43 PM
I think it was that one

thezerg 5:44 PM
ok I just joined bitcoin-ng

freetrader 5:44 PM
so is the 'bitcoin-ng' explicitly for wider group (e.g. incl Classic / XT) ?

sickpig 5:44 PM
actually we have 3 MLs:
- one hosted on google
- one hosted on mailman service provider
- the last one id the linux foundation one
@freetrader yes
I consider the one on google deprecated
we can "park" the second one
and start using the third (btc-ng)

freetrader 5:45 PM
i'm ok with that, thanks for the summary

sickpig 5:45 PM
we can change plan as we see fit

freetrader 5:46 PM
https://github.com/ftrader-bitcoinunlimited/BitcoinUnlimited/tree/buip-hf
^ branch on my repo based on current 'dev'

sickpig 5:46 PM
@thezerg WRT @redmarlen PR, I'm ok with whatever you prefer, I just thougth that the PR as is is gigantic but if you say that you already reviewed and it is ok, fine by me
thanks @freetrader
gtg now
bye all

freetrader 5:52 PM
I'm enabling 'Issues' on my personal BU repo, and will set the default branch there to 'buip-hf'
Issues can please be used for anything you find related to this HF development.
If it looks like a general 'dev' issue --> BU repo Issues
Let's discuss other technical details in the existing channel.