On 2/22/13, Branko Čibej <[email protected]> wrote: > On 22.02.2013 11:41, Jure Zitnik wrote: >> On 2/22/13 3:03 AM, Branko Čibej wrote: [...] >>> I have to say that for once I completely agree with Olemis. NULL table >>> column, and empty UI prefix equals "it all looks exactly like it used to >>> before the migration" and it also can't collide with any existing >>> product names or prefixes. >>> >>> Furthermore, doing it this way, if a user installs Bloodhound but >>> doesn't want to bother with product namespaces, everything will Just >>> Work. >>> >> I agree with the 'Just Work' part, I don't agree with tickets in >> global scope. >> >> My understanding was, based on the mailing list discussions, that we >> don't want tickets in global scope. That is why current implementation >> creates the 'default' product and migrates the tickets. I think that >> the 'Just Work' part is more of the UI/UX issue. I think that each >> ticket should be linked to a product, it's up to the UI to make it >> easy for the user to use environments with only one product (default >> one). I find tickets in global scope confusing as it's not exactly >> clear what they relate to. >> >> I would advocate global wikis for example, as it makes more sense. > > It's not global scope, it's default product scope which happens to have > no name and no prefix and no value in the related database column. > [...] > > Under the hood, this can be a completely different thing than the global > scope. >
jftr , I confirm this is what I had in mind since the beginning . > > P.S.: By the way, do we test upgrades from Trac to BH? If not, why not? :) > We should . That's another argument against performing MP upgrade in EnvironmentStub.__init__ method (i.e. at the beginning of one such test the env would be upgraded already o.O ) . In general , testing upgrades will be easier after committing BEP-5 and refactoring MultiproductSystem procedure accordingly . AFAICR franco included some test cases for upgrades so it seems it all (or good part of it ;) will come in a single package . @franco : coluld you please confirm ? -- Regards, Olemis.
