PFM repo should be archived and users should be pointed to ibc-apps repo for issues.

[jtieri]

As IBC Apps maintainers
We should archive this repo (or at the very least we should point users to the new repo) so we can start migrating users and that new issues/PRs are opened up over there.
We want to centralize all PMF work and meta (ie, Issue) in ibc-apps

• migrate issues to new repo
• come up w/ labeling scheme to track PFM issues w/in ibc-apps (as separate from, say, ICQ issues)
• sunset this repo

[jonathanpberger]

Oh interesting; I just saw this PFM issue on ibc-apps/issues and thought "wrong place". Are we risking ibc-apps/issues becoming a sludge pile of issues for a bunch of child repos?

@jtieri is there a pattern you like for dealing w/ this? A few ideas come to mind:

• everything in ibc-apps, and use labels to segregate issues w/in (CON: this could get messy)
• everything keeps its home repo (and repo board) and is submodule'd into ibc-apps (CON: git submodule is a PITA)

Whaddya think?

[jtieri]

My naive response would be that we sunset the child repos and move completely over to ibc-apps and explore using some sort of label system to filter down issues/prs for modules and middleware that we are the sole maintainers of for tracking in the motherboard.

With that said, I have no prior experience with trying to maintain a mono repo with multiple teams co-mingling. Someone else may have more valuable feedback here that is born out of experience and not intuition. My reasoning for wanting to sunset the child repos is that with two different repos it feels like more cognitive overhead as far as trying to respond to issues and PRs, not only that but it also feels like you will constantly be fighting the uphill battle of trying to educate users on where the appropriate repo is located for opening new issues vs. where you should be importing the software into your downstream projects.

I am fairly open minded here and could definitely be convinced that the latter option is better, I just have no experience with git submodules and so I think I'm lacking a clear mental model on what that really looks like and the implications that it bears.

[jonathanpberger]

Feels like "six of one, half-a-dozen of the other" to me; I don't have a strong bias.

Let's go with the 'everything in ibc-apps, and use labels to segregate issues w/in' strategy.

[akc2267]

need to double check PFM repo tickets and reopen necessary ones into ibc-apps

Not sure what to do with old tags. @misko9 suggests we address these old tags before archiving PFM repo

[akc2267]

forget about the old tags when moving tickets to ibc-apps

[Reecepbcups]

I have moved Issues to the new repo & closed here w/ linking

The CI / motherboard tag things should be a requirement upstream vs a requirement to archive this. We do not have enough issues yet to "need" to sort, but agree a label based CI system is needed.

releases have been done for major versions: https://github.com/cosmos/ibc-apps/releases