On 09/03/2013 05:09 PM, slava77 wrote:
>
> In RecoMuon/MuonIdentification/plugins/MuonIdProducer.cc:
>
> > @@ -255,6 +255,7 @@ void MuonIdProducer::init(edm::Event& iEvent, const edm::EventSetup& iSetup)
> >     reco::Muon aMuon( makeMuon( *(track.get()) ) );
> >
> >     aMuon.setMuonTrack(type,track);
> > +   aMuon.setBestTrack(type);
>
> @bellan <https://github.com/bellan> @vadler 
> <https://github.com/vadler> @bachtis <https://github.com/bachtis>
>
> This "bug fix" was introduced in 535.
> It introduces data content inconsistency for all previously created muons.
> So, people can't rely on this quantity at all, unless everyone is 
> consistently reprocessing muons.
> A more consistent fix was added on the data member access side in
> http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/DataFormats/MuonReco/interface/Muon.h?r1=1.71&r2=1.71.2.1
> The original "bug fix" in the MuonIdProducer was then removed and 
> release 535 was killed.
>
> Nothing has changed since then, in fact the situation is even more 
> "final".
> So, I prefer to stick to that old choice.
> If we want to rely on this fixed value, we have to recommend to rerun 
> all high level muon reco chain, which is not feasible.
>
The effect of the bug fix is to give a proper label to some of the muons 
(like the tracker muons) that otherwise will remain unlabeled.
What we are talking about is a legacy release. At some point, far in the 
future maybe, somebody may even want to produce/reprocess events with 
this release. The bug fix then will be effective, as it would have been 
done for January rereco, if it would have been kept in the release (as 
net effect, we could have already have the data with the proper muon 
best track). Removing it, will make the release... buggy once more.  I 
do not see what is the arm of having this correction in.

> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/cms-sw/cmssw/pull/684/files#r6128213>.
>