Skip to content

Latest commit

 

History

History
207 lines (160 loc) · 15.1 KB

20210209-meeting-development.md

File metadata and controls

207 lines (160 loc) · 15.1 KB
Raw

Meeting Notes: Development, Feb 09 2021

Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 80 min.

Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.

Community attendance:

  • antiochp
  • dburkett
  • joltz
  • lehnberg
  • phyro
  • quentinlesceller
  • vegycslol

(apologies if I missed someone - submit a PR or contact @lehnberg to add)

Agenda points & Actions

1. Retrospective

  • antiochp: Things have been slow these past couple of weeks. I got a couple of small prs merged - actually want to discuss process here as we have limited resources for review etc. Tl;dr things are slow - people are taking some breathing space and presumably considering future steps.

2. Agenda review

The proposed agenda was accepted with "Github Processes" and "Release planning" added to the agenda.

3. Action point follow ups from previous meetings

None.

4. Post 5.0.0 wish-list next steps

  • antiochp: I just want to preface this discussion with a personal comment - its awesome we have a wish list but given resource constraints we should be a) realistic and b) aware that building something is way more valuable than wanting something built. I would ideally like this discussion to be along the lines of "we want x and I'm going to go build it". (Not intended to come across negatively, just pragmatic.)

    • 👍: quentinlesceller, phyro, joltz, lehnberg

  • lehnberg: Yes. Currently, we have 0 dev resources that can take on work. (not counting antioch's pending funding request, which is ring fenced around specific tasks.)

    • antiochp: Right - there are 6 items at p1 and nobody to build them. And my specific tasks against the funding request are mainly personal preferences - I'd rather (as would anybody) focus on things that interest me personally, within reason.
      • 👍: phyro, quentinlesceller
    • antiochp: That said - they are not exclusive or exhaustive.
    • lehnberg: Of course, and given that you don't have an employer that gives you a to-do list, I think that's reasonable. You can suggest what you'd like to work on, people can chime in whether they think that would be useful and a good use of funds, and that's it.

  • lehnberg: So what should we do with this list now? We could try to advertise these priorities somewhere, and hope developers get interested.

    • antiochp: Its a valuable reference point for what we think is important.

  • lehnberg: We could attach bounties to them (not sure we'd want that).

    • joltz: Could always bounty some if we want to invest time to really specify what is needed.
      • 👍: lehnberg

  • quentinlesceller: I'd like to work on putting bounties together and advertising them somewhere. Maybe either setup something like zcash or simply a forum post for each.

    • 🚀: phyro
    • joltz: I can help write up the bounties as well 👍
    • 👍: quentinlesceller
    • antiochp: I think its definitely worth taking a few of these and running a bounty experiment.
    • lehnberg: Yes, experiment is a good way To put it. To do some small contained trials and see if we can flush out where the friction points are and determine a process we feel works.

  • lehnberg: Who will review these and determine whether they've been completed correctly? Is that a council task? Again, we have 0 dev resources right now.

    • joltz: If the bounties are clearly defined enough it should be straightforward to assess. As far as the final yes/no decision I would assume whoever is funding, in this case council. But would be great to have lots of community input on the formation and definition of the bounties.
    • antiochp: I'm tempted to say we cross that bridge once we get there - ideally we'd see incremental progress via prs etc. And not a big bang approach.

  • joltz: Some of the tasks can be chopped up into smaller chunks but that requires someone going through and essentially planning the development steps in advance.

    • antiochp: I suspect we'd be able to see if a bounty was realistically being tackled or not relatively early on.
    • quentinlesceller: I think it's worth experimenting with 3/4 items on the wishlist.
      • 👍: antiochp, joltz, lehnberg
    • antiochp: Agreed - no more than that initially.
    • antiochp: Put them out there and see if we can entice somebody to commit some time toward it.
    • phyro: Let's get a few bounties running and see what comes out of this. I don't expect people unfamiliar with code to tackle the big ones, but some of them might be approachable for onboarding.
    • antiochp: Yeah this has to be somebody willing to put independent time into it as we have no resources to onboard in any significant way.

  • lehnberg: Probably can be done on the forum as a start right?

    • quentinlesceller: Yes. No need to set a new platform.
      • 👍: antiochp, phyro, lehnberg
    • antiochp: Yeah forum makes sense.

  • phyro: This is also a good opportunity to possibly get new devs working on the code.

  • quentinlesceller: I think we should try to determine the price of each bounty. Maybe discuss it here?

    • 👍: dburkett

  • quentinlesceller: https://grants.zfnd.org/proposals. This can give us an idea of the pricing.

  • lehnberg: I'd be happy for @quentinlesceller to look into our list of priorities, pick the ones he thinks are suitable, and make a proposal for bounty sizes. And we could review in a dev meeting to come.

    • antiochp: Yeah maybe we start with @quentinlesceller doing an initial pass if he is up for it?
    • quentinlesceller: Yes I'm in.
      • 🚀: phyro, antiochp, joltz, lehnberg, vegycslol

  • lehnberg: Anyone who wants to get involved could ping quentin and roll up their sleeves.

    • 💪: antiochp
    • quentinlesceller: Yeah any help is appreciated:)

  • antiochp: I see "late locking" is there on the agenda under wish list - I'm starting to think about this a bit more, nothing concrete yet but its on my todo list.

    • phyro: I guess I'm lucky since I expressed this wish as well:)).
    • lehnberg: @mcmmike wrote:
    for 4.)
i would like to put the late locking on top (or at least top 10) to fix some issues (add features).

the late locking feature is enabled on the wallet and can be used with the -l flag. There is a known limitation currently in that the transaction can not be finalized if the required number of inputs changes. This could be solved by adding a second kenrel that pays for the difference.

in reference to e.g. Mimblewimble/grin-wallet#541
    • dburkett: Yikes! A second kernel would be not great.
    • antiochp: Good to note, but yeah maybe not how we end up doing this. I suspect we still fail tx building in some situations. And just need to restart the process. It does not need to handle every situation.
    • dburkett: Maybe input fees was a mistake:/
    • vegycslol: Why does the number of inputs matter with late-locking? We could just pick x and then in phase 3 pick and inputs and make them sum to x or not.
    • antiochp: We are getting off topic.
    • dburkett: It's a dev meeting. Isn't that on topic? I mean, we're discussing dev.
    • antiochp: Lets stay on the agenda.
    • dburkett: Late-locking is on the list.
    • antiochp: There's a late locking issue in github - feel free to comment there. Actually please comment there so we can keep on track for the meeting. Its a "dev meeting" with agenda - not for generic dev discussions.
    • dburkett: It's not generic. It's lIterally about one of the agenda Items (late-locking). But sure, I can move to the github issue.
    • antiochp: Moving on.
      • 🙃: dburkett

5. Github processes: Reviewing, branches, etc.

  • antiochp: Tl;dr do we have the resources to do effective code review? And if not, what do we do about it.

  • lehnberg: 18 prs open on grin: https://github.com/mimblewimble/grin/pulls. 7 open on grin-wallet.

  • quentinlesceller: Right now we are 2/3 able to do review.

  • antiochp: Some of those probably warrant review, some may be stale. So we likely want to do some housekeeping. And in terms of branches etc. We have 5.0.x (for bugfix if needed) and master.

  • lehnberg: @phyro would you be up for doing triage / maintenance of the repos and keeping them tidy on an ongoing basis? I.e. Not reviewing, but just making sure things don't get lost or forgotten, and pinging others to review, and if you don't get any reviewers, flagging that in a meeting such as this one?

  • quentinlesceller: Imo we can do a coordinated effort to review + housekeeping. We can start with grin repo.

    • lehnberg: Right, but would be good to do it continuously and have someone in charge for it.
      • 👍: antiochp
    • quentinlesceller: Indeed.
    • lehnberg: Doing a sweep every once in a while doesn't quite cut it, we need to remember to sweep as well!
    • antiochp: Yes it would be a win if we could come away from this meeting with somebody owning this.
      • 👍: quentinlesceller

  • quentinlesceller: Though I'd find it much easier to keep it in clean once we have done a cleanup.

  • phyro: Alright, I'll do my best, but this may result in pings on the pr as I'll lack the context 👀.

    • 👍: quentinlesceller, vegycslol, lehnberg
    • lehnberg: Awesome! Do your best, feel free to ask questions here or dms, wherever you feel like.

  • phyro: Would it make sense to go through these at dev meetings? Or to check on the state or something similar.

    • antiochp: No I think we can summarize in the dev meetings, but not go item by item. We have the issues etc in github for that.
    • lehnberg: Generally, use this as your dumping ground, you could for example come up with a recommended list:
      • stale (close?)
      • to review (who will review?)
      • in progress.
    • antiochp: Pings on prs are good because it means relevant things will bubble to the top of the heap as they will be discussed.
      • 👍: lehnberg, phyro
    • antiochp: And we prune anything that lacks engagement.
      • 👍: quentinlesceller

6. Release planning: next minor and patch releases

  • antiochp: Not sure if we have much to discuss on this point. We kind of need something to release first.

  • quentinlesceller: Loosely related to release planning but we do need to check that everything that is on v5.0.x branch is on master as well.

    • 👍: antiochp, phyro
    • antiochp: Yes - good point. There's a task to reconcile those 2 branches so nothing gets missed.

  • lehnberg: So I guess a question here is. How do we do releases. Say that I submit a pr with an improvement, it gets merged. It's not a bug fix, so it should get out in a minor release. When does it get released? I think it could be nice if we could get into a cadence here.

    • antiochp: Yes agreed. We don't want to wait too long between releases.
    • quentinlesceller: We should probably focus on bugfix and expose the build_coinbase api (very specific I know).

  • lehnberg: Means contributors know what to expect here, and it doesn't all feel so ad hoc. Also means it's equal for all.

    • antiochp: But not sure we want a rigid schedule right now.
    • lehnberg: Patches perhaps continuously? And minors every month? Maybe patches every week or two weeks? Unless something critical? Idk.

  • quentinlesceller: Technical objection but the release process is a bit long to do every week (unless automated).

    • lehnberg: Maybe bounty the automation up as well?

  • antiochp: At this point release planning just feels like extra drain on resources, but yeah maybe minor on a monthly basis.

    • 👍: quentinlesceller

  • quentinlesceller: Maybe a 2 week schedule?

  • antiochp: I'm honestly not sure about patches. Are we supporting 5.0.x branch with official patches for anything other than critical fixes?

  • phyro: I'm not sure what the current flow is, but I believe the master doesn't have the latest code right now. Would it make sense to have master being the latest release at any point in time?

  • antiochp: Master is latest code - if not then we need to get anything missed onto there.

  • vegycslol: I think the latest tag on master could be a release.

  • antiochp: And master should be buildable and deployable at all times.

    • 👍: lehnberg, quentinlesceller

  • quentinlesceller: Yep that'd be great. Maintaining 2 branches is a pita.

  • phyro: Agree, I think we need to merge a few things to master 👍

  • antiochp: 5.0.x branch (at least in my mind) is if we do something on master that needs more testing in the wild before we are willing to make it official release. And we encounter a fix that needs to go out immediately. But 5.1.x should be the next scheduled release (off master) - I think. But others may have other opinions on this.

    • quentinlesceller: Agree with that.

  • antiochp: This all needs a bit of a rethink though post-hf4. Pre hf we had a 6 month schedule and a branch for each hf. And we needed to support both as we got closer to a hf. Its different now.

  • quentinlesceller: Agree with all the above actually.

  • antiochp: Non-contentious stuff goes in master - anything remotely contentious is tbd in terms of how we even think about merging/deploying it. To @lehnberg point about process.

    • lehnberg: I mean, what's a contentious thing that we merge? Anything we merge, we should be happy to put in a release, no?
    • antiochp: Sure but we can only hope people deploy it, there is no real incentive to do so now. (no 6 month deadline to keep up to date with).
    • lehnberg: Deploy, as in deploy a release? Or run the node?
    • antiochp: Oh I guess run a node - we can release it, no guarantee anybody upgrades their node. We at least had rough idea that people would proactively upgrade before and then at hf would be forced to upgrade. We can release 5.1.0 but will everybody upgrade?
    • vegycslol: What's the downside if they don't?
    • antiochp: For the dev team? More combinations of things to support over time, compatibility issues etc.
    • phyro: They eventually will need to, if nothing else, we probably won't be supporting the txhashset.zip forever.
    • antiochp: Perf issues to support with old code running etc. Its not so much a downside as just a different environment compared to pre hf4.

  • lehnberg: I guess everything we merge from now on will need to take this into account.

    • 👍: antiochp

  • phyro: Yeah, everything needs to be backwards compatible:(

  • lehnberg: We prob can't merge stuff that requires / expects a majority of nodes to use it, unless it's a major (x.0.0) release, i.e. a hard fork. This is the path of the distributed network. We must walk it.

    • 🚶‍♂️: phyro
    • antiochp: Totally. Pibd support is a good example. It needs to be opt-in based on nodes upgrading.
    • lehnberg: So yeah actually, maybe a 6.0.0 branch is necessary...:/ Launch date: 2024.
    • antiochp: And we need to support txhashset.zip for a while yet.

7. Other questions

None.

Meeting adjourned.