On 24.04.2013 13:48, Gary Martin wrote: > On 24/04/13 11:57, Joachim Dreimann wrote: >> On 24 April 2013 11:54, Joachim Dreimann >> <[email protected]>wrote: >> >>> On 24 April 2013 10:19, Matevž Bradač <[email protected]> wrote: >>> >>>> 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. =) >>>> >>> From the interface perspective I've always said that there should >>> be no >>> product until a user decides to create one. I have changed my mind now >>> after seeing some of the issues that brings and our discussions. >>> >>> We could just prompt the user to name the default product during >>> installation: >>> *Name for initial product:* >>> >>> During upgrade from trac users get prompted for an upgrade trac >>> command, >>> so we can do the same there. >>> >>> Wouldn't that make it much easier to ship a decent implementation of >>> this >>> in 0.6? >>> >> Just to be clear I would then leave system wikis at a global level >> (matched >> by page name) and all other wiki pages and tickets etc moved to the >> default >> product. Permissions to edit the system wiki can remain with the >> admin for >> now. >> >> Incorrect links (#1 should really lead to #PRODA-1) should be dealt >> with by >> providing disambiguation. > > I think I can agree with the idea of requesting a name for the initial > product if we are already treating the global product as a container. > > I suppose that we will eventually have to start meddling with user > edits to the guide pages but I would still tend to go with moving all > the pages to the product wiki, rather than attempting to make any > distinction now. We can install a fresh set of guide pages, either in > the global wiki or in the orthogonal guide wiki I suggested earlier. I > am hoping that disambiguation will also help reduce any confusion this > causes here too. > > Once we find we have to upgrade guide pages we should probably do this > as updates which maintain the history of the pages on the assumption > that there will be a means for users to edit them. > > Meanwhile, are you suggesting that #1 should never actually lead > directly to PRODA-1? That would be consistent with how you suggest > that the search will work but, given that the previous intent was > clear, I was thinking it might be better to go to PRODA-1 and provide > disambiguation links at the top of the page as an encouragement to > make people use properly scoped links.
Old-format links should always work, same as pre-multiproduct URLs should work. Remember that the links do not only appear in BH tickets and wikis, but also in mails or IM's and code comments etc. that we do not control. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
