On 24 April 2013 13:31, Branko Čibej <[email protected]> wrote: > 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 >
Yes Gary, I like that suggestion.
