Perforce tracks where revisions of a file have been integrated, but it doesn't automatically propagate check-in comments with your bug-tracking metadata.
Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I'm using "branch" in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let's say you've been working in //source/project/trunk/... and you have a changelist @1234 that you'd like to check whether it's been integrated into your release branch //source/project/rel/.... Create a client that maps //source/project/rel/... and execute:
$ p4 integrate -n //source/project/trunk/...@1234,1234 //source/project/rel/...
If Perforce tells you "All revision(s) already integrated.", changelist @1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It's also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)
This doesn't scale especially well -- you need to check each bugfix on each branch you care about, though it does lend itself to automation.
You can use the "unsupported" Perforce command interchanges to get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, "unsupported" means something like "might not work the same in the next revision, but we think it could be useful so we'll release it anyway".) To see what changelists haven't been integrated from our example trunk to release branches, execute:
$ p4 interchanges //source/project/trunk/... //source/project/rel/...
Change 1236 on 2010/10/10 by user@client 'Fixed some bug you don't care about'
Change 1235 on 2010/10/09 by user@other_client 'Fixed some other random bug'
In this example, I haven't listed changelist @1234 because it's already been integrated into the release branch. One problem I've experienced using interchanges is it'll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you're cherry-picking revisions for a release branch you may see changelists listed again. I use interchanges as a first pass to get a rough idea of what I need to integrate, then look at integrate to get a better idea of what's really missing.
(Perforce also supports a similar concept of "jobs", that let one attach particular fixes to particular changelists, but my organization doesn't use them so I don't know how well they work or whether they are propagated automatically on integration.)