Can anyone help me. A little confused on how to submit a PR on github for a new respositories.json addition to HPM.
Do I need to fork it first, add my submission to the fork and then do a merge back to the master. Not clear on the paradigm for how this process works.
If you just go to the file on GitHub (hubitat-packagerepositories/repositories.json at master · dcmeglio/hubitat-packagerepositories · GitHub), you can click the little pencil icon to edit as if it were you're own file. GitHub will automatically make a fork of it for you...you can just make your changes there in your browser and commit it. Afterwards it will leave you on the changed file in your fork and there will be a "Create Pull Request" button you can click to submit the PR to merge that change back into the real repo.
Thank you so much for pointing that out. Not sure how long it would have fumbled around before I tried that. Would you answer a couple of other questions?
How long does it take for the new repository to be visible in HPM?
When I update my own software and then update the packageManifest. Is there any additional step(s) for those changes to be reflected in HPM?
Thanks.
Your repository should show up in HPM once the Pull Request you submit is merged...which is based on when the owners of that repo notice it and have time to verify and merge it. I don't know how long that takes, but I assume they get notifications about it and will take a look when they have time.
I'm no expert, but I believe the answer to the second question is essentially No. Once your repository is registered, if you add new things to your repo or upgrade things, they should be picked up pretty quickly and automagically by HPM (that's my understanding). Just be sure if you change things to increase the version number accordingly. HPM devs recommend semantic versioning to ensure it properly detects your new versions.
That's right, once your repo is added to the HPM list, you can add updates to your drivers / apps without any involvement from Dominic (the HPM God...
)
Yea, I should have planned ahead and made a generic Hubitat repo to add...instead I made a repo specific to the iAqualink driver I just released so now I'll have to add another if/when I write more things. I give myself a solid B- on planning there. 
That can go either way.... Certainly a single repo makes some parts of the admin easier.... But I have certainly considered splitting my repo into separate repo's for each app / driver, or some logical break-up. I can't think of all the reasons why this might be a benefit. but certainly handing it over to someone else is easier.
That's a good point. In general easier for someone else to fork for their own purposes as well. I've always felt like when you have a monorepo, separate ones always seems better...and when you have separate repos, a monorepo always seems better. Grass is always greener I suppose. 
Yeah, don't look at my setup as an example of my own suggestion.... 
I just noticed HPM said updates were available. When I ran it, it said the updates where for the light strip and the red dimmer. It tried to do the upgrade for the red dimmer and failed with this error message which is just like the one @spartysh32 posted except mine said lzw31 not lzw30 like his was;
As many might have noticed by now, Dominic has decided to leave the Hubitat Community and has marked himself as no longer active. One of the first questions that brought up is what happens to HPM.
I forked his repo, as he suggested, many months ago when the handwriting was on the wall. I also took some time to augment the Search feature he built in that relies on him maintaining an Azure site. I've had that functional for quite a few months, where I added a switch to pick the search method. "Fuzzy" using Azure, or "Fast" using the search I built.
The purpose is to provide stability. If Dominic closes the Azure service, this fork will continue to work using "Fast".
Thanks for your efforts @csteele . What happens with the config file that controls the published repos now? It is also hosted in Dominic's GitHub here to which we also wouldn't have control?
We should also update the README accordingly for your fork. Are the controller/owner of that HubitatCommunity on GitHub I assume?
Yes, I agree that there's more transition needed but I'm going to hold out hope he changes his mind for a few days longer. 
I know the answer is very unlikely to be yes, given previous expressed views, but I really think that the HE team should consider building this into the platform, even if it has GIANT warnings on it about unsupported user code/no guarantees, I think HPM adds so much value to the community side it would be a shame to see this fall down. @bobbyD @bravenel @gopher.ny @bcopeland .
Please consider having this as part of the platform. Pretty please.
I just barely latched onto HPM and you want to take it away???
.
...
(Please, take it.)
Truly a tremendous loss to the community. HPM is the “Great Facilitator” and has enabled me to load multi-component complex apps that I probably would not have attempted to load on my own. Truly a great loss.
@csteele. Some questions:
Finally, @csteele thanks so much for keeping HPM alive! Indispensable app!
At this moment, I don't think there should be a RUSH to migrate. Dominic said last year he wasn't planning on removing or "breaking" anything. As the days go by, and together we conclude he really has left, I'll do a transition release to move the Master Manifest and so on, over to "my" fork. I think for most, that will be the time to migrate.
I've been using my version since July of last year. So I'll have to think a bit remember the nuances but from memory, I just copied it over... no delete, just straight paste. The change is minor at best, only "Install: Search by Keywords" got touched. That is the one place where "Fast" appears.
@csteele
Thanks again for all your work on this and keeping us informed. All your effort is much appreciated!
We have considered this, and won't take it on. Doing so would put us in an untenable position, either as to giving the appearance of approving/endorsing customer apps and drivers, or being deemed to have contributed to any liabilities arising from their use. Neither of those risks are ones we are willing to take. As it is, as a community supported system, HPM works well.
Download the Hubitat app
