Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 11 15:39

    antiochp on master

    implement fix past fees RFC wit… (compare)

  • May 11 15:39
    antiochp closed #3629
  • May 07 09:44
    antiochp commented #3596
  • May 07 09:40
    antiochp commented #3596
  • May 07 09:23
    antiochp commented #3596
  • May 07 09:15
    antiochp commented #3641
  • May 06 20:48
    phyro commented #3641
  • May 06 20:24
    nthrow commented #3641
  • May 06 20:15
    nthrow commented #3641
  • May 06 20:09
    antiochp commented #3641
  • May 06 20:09
    antiochp commented #3641
  • May 06 20:01
    antiochp commented #3641
  • May 06 19:57
    MCM-Mike commented #3641
  • May 06 19:57
    antiochp commented #3641
  • May 06 19:35
    MCM-Mike commented #3641
  • May 06 19:27
    nthrow commented #3641
  • May 06 19:22
    MCM-Mike commented #3641
  • May 06 19:21
    nthrow commented #3641
  • May 06 19:20
    nthrow commented #3641
  • May 06 19:19
    MCM-Mike commented #3641
lehnberg
@lehnberg

In the planning issue,

I'm changing PoW issue to ✅

I'm changing Node API v2 to ✅
Yeastplume
@yeastplume
Are we just looking at fixes or want to slip any changes in. The only thing I really have is packaging and verifying payment proofs, which is just surface-level stuff that shouldn't affect anything, but also happy to leave it till 3.0.1 if we decide against this kind of thing in general
Antioch Peverell
@antiochp
@lehnberg 2 and 6 are both green now also
lehnberg
@lehnberg
great was just about to ask you!
Antioch Peverell
@antiochp
:+1:
lehnberg
@lehnberg
@yeastplume - payment proof is fully implemented now?
Antioch Peverell
@antiochp
and sync stuff should be limited to minor fixes at this point
lehnberg
@lehnberg
did I dream there was some (minor) stuff missing?
Yeastplume
@yeastplume
all wallet stuff is green
lehnberg
@lehnberg
Antioch Peverell
@antiochp
@JosephGoulden has a couple of minor TUI fixes that I think there is consensus for getting into the next beta release (low risk fixes)
lehnberg
@lehnberg
oh yes it is
Yeastplume
@yeastplume
Right, so if everyone's okay with a proof verification in the next release, (also low risk) I can get that in as well
lehnberg
@lehnberg
I mean...
we're meant to cut a release candidate in three days?
or is that timeline changing?
Antioch Peverell
@antiochp
24 hours of beta.2 or something
Yeastplume
@yeastplume
It's dependent on the sync issues for the most part, the other stuff is minor and can really wait if needed
what's a 'release candidate'?
Antioch Peverell
@antiochp
some eyes on mimblewimble/grin#3164 and mimblewimble/grin#3165 would be good to get the sync issues hopefully resolved
Yeastplume
@yeastplume
I mean, we don't do special RC builds, if it turns out everyone is happy with beta.2 that's the release candidiate
lehnberg
@lehnberg
Release Candidate is like "this is a version we think is good enough for final"
Yeastplume
@yeastplume
I meant in our context
Antioch Peverell
@antiochp
yes I guess the assumption here is beta.2 is the RC (pending anything unexpected)
lehnberg
@lehnberg
And then it's out in the wild until our assumption is proven right
Yeastplume
@yeastplume
Yes, I'm okay with the assumption beta.2 is the RC, until someone demonstrates any reasons why it shouldn't be
Antioch Peverell
@antiochp
beta.1 is the RC currently given the fact we are doing a release for HF2
lehnberg
@lehnberg
oh I see. yeah I mean, generally, if you're doing bug fixes and release, there's a good chance you might get a release candidate if there's no regression
but if you add new functionality and release, you might get a release candidate, or you might get a list of bug fixes that you need to do
Antioch Peverell
@antiochp
yes absolutely - last thing we want to do right now is add to the list of outstanding bugs
Yeastplume
@yeastplume
Okay, so happy with saying no to new features as well
and just including any needed sync fixes
lehnberg
@lehnberg
I feel it's up to you guys as devs to agree on. I'm skeptical myself, but don't feel I've got a horse in the race
my opinions are as per the comment in the thread
https://github.com/mimblewimble/grin/pull/3161#issuecomment-563217208
Antioch Peverell
@antiochp
I'm going to test the TUI changes though locally - they are limited enough in scope I think and give some tangible benefits (no new features)
one fixes a known panic in the tui for example
Yeastplume
@yeastplume
Okay, look let's leave it at that then.
lehnberg
@lehnberg
but I'm not the one that's at risk of being stuck doing last minute troubleshooting & bug fixes over the holidays
Yeastplume
@yeastplume
And on the stuff I'm looking at I'm happy to have at least one definite feature add for 3.0.1
Antioch Peverell
@antiochp
all that said - the TUI is usable right now, so I'm not entirely convinced by my own argument here
Yeastplume
@yeastplume
heh
lehnberg
@lehnberg
I used to be liberal with these things, but a couple of years of releasing turned me into ultra-conservative
Yeastplume
@yeastplume
... okay... Sync fixes + TUI fixes, since they're fixes they make sense to put in
lehnberg
@lehnberg
as I've heard enough "and you won't believe what happened next" war stories
Yeastplume
@yeastplume
and no new features. Yes, I was bitten by 'just a small change' as recently as the 2.1.0 release as well
Antioch Peverell
@antiochp
sync stuff should be fixed if we can wing it though - we've seen enough "locked up sync at step 6/7" for it to be an issue across a large number of nodes
lehnberg
@lehnberg

sync stuff should be fixed if we can wing it though

agree

Antioch Peverell
@antiochp
I just ran 3 successful sync in a row though with a combination of the two PRs up, so I think we have a fix with relatively minor changes involved
Yeastplume
@yeastplume
Okay, so think we're agreed here? Sync fixes necessary, TUI up to @antiochp 's judgement, nothing else?