On 23. Apr, 2013, at 16:49, Gary Martin wrote: > On 23/04/13 10:45, Matevž Bradač wrote: >> On 22. Apr, 2013, at 17:17, Gary Martin wrote: >> >>> On 22/04/13 13:29, Matevž Bradač wrote: >>>> On 1. Apr, 2013, at 17:54, Branko Čibej wrote: > >>>>> I think everyone is focusing a bit too much on implementation details >>>>> and failing to ask the important question, which is: what role do system >>>>> wiki pages play in a multiproduct setup? >>>>> >>>>> Answer that question, and most of the debate falls by the wayside. >>>>> >>>>> 1. If system wiki pages are meant to support the whole BH installation, >>>>> then I see no good reason for anyone but system admins to be able to >>>>> modify them. There's potentially room for a new role here (system >>>>> wiki admin), that could only modify the system wiki, but not other >>>>> aspects of the system-wide setup; however, that's not an immediate >>>>> concern, IMO. >>>>> 2. On the other hand, if these "system wiki" pages are modifiable by >>>>> /product/ admins, or even ordinary users who have access to a >>>>> product, then it follows that each product can have its own version >>>>> of those pages, which implies these are no longer "system" pages at >>>>> all and you're back to square one -- deciding what to do with the >>>>> "real" system wiki pages, and whether or not they even exist. >>>>> >>>>> >>>>> IMO, pick one; but I suspect that #1 is the saner alternative. >>>>> >>>>> -- Brane >>>>> >>>>> -- >>>>> Branko Čibej >>>>> Director of Subversion | WANdisco | www.wandisco.com >>>>> >>>> Hi, >>>> >>>> I'm continuing with this topic since there doesn't seem to be a general >>>> agreement on how the (system) wikis should function in multiproduct >>>> environments. >>>> >>>> As Brane pointed out, it's firstly a decision on what role system wikis >>>> should assume. I'm leaning more towards #1, as having an >>>> installation-wide wiki may make sense, even if products are not directly >>>> connected with each other. Should we move in that direction? >>> As I said before, this is the approach that I would advocate. If users >>> disagree then it shouldn't stop them from migrating pages to a product. >> Ok, moving into that direction then. >> >>>> The second issue would be how to handle wikis form the installation and >>>> upgrade point of view. Before multiproduct (MP) support, there was only >>>> one set of wiki pages to handle. With MP however, each product now gets >>>> its set of wiki pages, plus there is also a global scope which may (or >>>> may not) be used for system-wide wikis. >>> I think that it would help us to distinguish upgrade and import. For >>> upgrading we could (should?) choose to leave the entire global wiki in >>> place and let our users decide what they want to move into a product. For >>> importing, we should probably import any global wiki into it's own project, >>> and we could even ask for a name for this product in the process. Any >>> products that we are importing can retain their names as long as there is >>> no clash. If we don't want this to fail on those rare occasions, we can >>> just append a uuid to the namespace names or something similar. >>> >>> Trying to think through clever solutions is probably not worth it if we can >>> instead just provide appropriate tools for the users to sort themselves out. >>> Cheers, >>> Gary >> I'm not sure what you mean by import, would this perhaps be importing an >> existing Bloodhound or Trac environment into a specific product? If so >> I think we should postpone resolving this for now, IIRC it should be out >> of scope for upcoming releases? > > That is probably fair for now. I imagine that eventually users may want to > consolidate separate installations into a single database (be that individual > trac environments into a single new product or bloodhound environments into, > potentially, multiple products). Of course, I may be wrong.
I completely agree, it's one of the use cases we eventually have to cover, there just wasn't much emphasis or focus on import so far. > >> For upgrade I think your proposal doesn't fit into 1-3, so we can treat >> it as a separate one: >> 4. Leave all wikis in global scope >> + consistent with (current) clean installation behaviour >> - broken ticket links (wiki -> ticket, because tickets are moved into >> product scope) >> - empty product dashboard (but this is minor) >> >> I'll think about it a bit more, but this one seems to be the cleanest >> solution so far. > > While this might be a little off the current topic, I am still not entirely > sure of the reason to move tickets into a different scope unless the users > choose to do this. Providing the means for a user to easily migrate the > global product tickets and optionally a wiki into a new product makes a bit > more sense to me. Until a user explicitly does this, why would we need the > tickets to be in anything other than the null product? Another nice aspect of > this approach is that the wiki -> ticket links should remain available once > users decide to move tickets into a different product as I believe previous > links are meant to remain as synonyms specifically to maintain old links; the > very fact that the tickets were in the null product should mean that they can > still be referred to as if they are still in the null product. Redirection in > this sense should be fine with the caveat that permissions of the current > product in which the ticket resides should be respected. Wouldn't this bring us back to square one though? Global environment is currently considered as a "parent" to all product environments, and as such it allows for global configuration which specific products then inherit. If we change the role of the global environment to being "just a product", we'd have to rethink on how to handle global configuration. It's certainly doable, but likely at a substantial cost (design- and implementation wise). But that's just my opinion, I'll wait for others to chime in. =) > > Anyway, I'm trying to work out whether it is worth suggesting another > orthogonal wiki on a different path for the Guide pages so that we can > separate out concerns. So, if there is a path/to/wiki/ for each product's > wiki, path/to/guide/ could be for system pages and then we would only have to > consider upgrading the Guide pages in the Guide wiki and only actually at a > single location and we can drop any excuse to meddle with the product wikis. That makes a lot of sense, and is IMO closely related to proposal 2 - global wikis moved to default product, empty global wiki populated with links to product wikis. Would it make sense to replace the global WikiStart with the Guide page in this case? > > Many of the same problems remain, including page duplication but the general > disambiguation link solution is equally valid here. This wiki solution also > seems consistent with subdomain setups that Olemis is so keen on. > > Cheers, > Gary -- matevz
