So in the blog post, I mentioned that the Foundation would like to contribute to microPebble (and, more to the point, I want to drive that effort from the Foundation’s side ). And on Discord, @matejdro suggested transferring microPebble to pebble-dev GitHub too. So I wanted to start talking about what that looks like – and hearing ideas about what microPebble ought be?
For my side: I would like for microPebble to have “first-class” support for RWS – and to have microPebble be the reference implementation / testbed for RWS features. I think @lavender had some questions about where this puts microPebble in terms of vendor-neutrality, and we should talk about that? But my best answer to that is that presumably microPebble could also support other app stores, but anyway, you have to choose something to target or otherwise you do not build something coherent at all and you get something that works poorly with many things, and well with nothing.
I also would like to bring the old Cobble UX into microPebble. Some of this might be at least a little at odds with microPebble being minimalist, and it would end up making microPebble heavier weight – and I’m wondering how others feel about this.
So if it were up to me, microPebble would mostly just morph into Cobble But if other people want it to do other things, I guess now is the time to talk about that. Are there other opinions?
KMP microPebble continues development until it has feature parity with the regular microPebble
Regular microPebble repo is archived, KMP version is used onwards, since KMP version would now be a superset of a regular version.
However, this presents a challenge of a moving target: Until KMP version is ready, regular version is still being updated (as this is the version that us Android people are using, since the KMP is not ready yet). We could impose some sort of a freeze to make this lighter, but that would depend on how long we think KMP version would take to mature.
This makes some sense, though I feel like I’d like to have things reviewed, which presumably means having incremental things to merge back – and it might be nice to keep the PR and issue history of microPebble?
Though an implementation of the above could be:
microPebble fork into pebble-dev, matejdro/microPebble@main → pebble-dev/microPebble@kmp-develop
development branches go into pebble-dev/microPebble@whatever/feature
PRs get submitted inside pebble-dev/microPebble@whatever/feature onto pebble-dev/microPebble@kmp-develop
pebble-dev/microPebble@kmp-develop gets rebased on matejdro/microPebble@main as changes are made, and force-pushed
When pebble-dev/microPebble@kmp-develop is fully ready (and hence the rebases and force-pushes end), it gets plopped either on top of matejdro/microPebble@main (which then gets moved into pebble-dev?), or as a brand new pebble-dev/microPebble@main
And indeed one should hope that that amount of time in the middle is short.
Sounds good. Although I’m not sure merging things back incrementally would be possible. KMP migration essentially tears open half of the app and makes lots of things incompatible before they are migrated.
A suggestion from my own experience with such a situation:
Rebasing fork onto main may lead to unresolvable (read: too time-consuming and/or error-prone) rebase conflicts. It should be possible to merge matejdro/microPebble@main into the fork whenever main changes. By that you avoid rebases and force-pushes, which avoids many pitfals and saves a lot of your precious time.
Yeah, I’m hoping that the critical window in which this happens is short. We have a meeting scheduled tonight, and I’ll try to read out notes afterwards!
About the RWS integrations, I assume neither Pebble nor Rebble ever made any public-facing documentation for it? I’ve figured out enough to get the locker API working, but I’m not so sure about the dictation, weather, and timeline pin services (and whatever else it offers)
Goal: rough out implementation of @lavender’s UI widgets, port some example screens, enable other people to easily implement other screens
Not explicitly scheduled in the above, but worth talking about:
When to submit to app stores?
App is considered usable by “adventurous Rebblers” after phase 1 + 2 – start beta / invite / opt-in releases then?
What work needs to be done to placate Apple in particular? (@fishy worries about whether Apple is going to require Liquid Glass HIG compliance)
Should there be crash / other telemetry?
Rebble already has ‘treasure’ collector
Pick Sentry / Crashlytics / similar for crashes? Do either of these support relatively transparent applications (public dashboards of crash rates / other quality metrics)?
Concern: how does Intent work with part-time community folks?
Intent will have approx one FTE working on this
It would be a waste of the FTE’s time if they were blocked on part-time volunteers and could not make progress
We need to come up with good strategies to get out of Intent FTE’s way!
How to communicate / do planning?
Joshua can do PM work (weekly async planning to deconflict different people working on different things and publishing what people plan to be touching so everyone knows)
Assign tickets for work in GitHub?
Longer-form discussions in Rebble Dev Forum?
Intent can optionally use Discord?
Mostly play it by ear
How to do code review?
Intent will make narrowly-scoped PRs
(is this possible for “big ComposeMP fix”? presumably this one is going to have to be a big one)
Do “pre-review” of architecture / planned changes in Rebble dev forum threads? (i.e., ‘I plan to do x, if I implement this as I propose, would that be ok?’)
For low-risk PRs, Intent can provide fractional second engineer to do light-weight signoff and can autonomously commit to main with internal review (typo fixes; ‘someone else already agreed on this and it was not contentious, and it is done as we agreed’)
matejdro, fishy, Joshua, Stasia can review code from Rebble side
Let’s build trust together, it has worked well so far for microPebble and RWS
Next steps:
Matteo to estimate work remaining on phase1
Joshua and Matteo work together to draft SoW for phase 1
I don’t think so, no. We can always create new APIs, of course, if they’d be easier, but for any of the above things, I (or someone else) can help sift through the python to be verbal documentation, if nothing else.
The big question on my mind is how we want to do the login flow. The classic login flow is to point a browser at boot.rebble.io (which then causes you to log in with auth.rebble.io), which gives the app a customized boot JSON link (I believe https://boot.rebble.io/api/stage2/ios?access_token=blahblahblah). This is kind of miserable, though, and it would be much nicer to actually implement oauth2 rather than having a hardcoded access_token lying around embedded in a URL…
Authentication for any of the services that require it (dictation, weather) is done through chained URLs inside of boot that also have access tokens hardcoded into them (e.g., for subscribed users, boot[‘config’][‘url’] == "``https://weather.rebble.io/api/v1/api/v1/geocode/.../?access_token=blahblahblah``". Similar approach for dictation (but even worse). Sort of a mess and it would be nice for boot to be less mandatory-personalized to the user…
They can do Authorization: Bearer or ?access_token query param. The point was more that because those paths weren’t authenticated in original Pebble boot, there was need to add auth via ?access_token into Rebble boot endpoints. It would be better if we instead used a public boot json without the need for specifying the ?access_token, so that the boot functions the same for authed and non authed users, and then we can handle authentication as part of individual endpoints instead.
Yeah, Appstore I realize does not embed ?access_token because it does not need it (it does get a token through the login path).
This is a good discussion, but probably this should be punted to a different thread. I thought there was a feature in Discourse to move posts to a different thread but I can’t find it now.
). And on Discord, @matejdro suggested transferring microPebble to