Sergey, Thanks :)
No doubt though. But it sounded like some of the concerns in the thread(s) were people mistakenly thinking that we were going to completely get rid of the wiki altogether or something similar. Either way I am sure a clean wiki install should be done soon so we can at least get it usable again (and get rid of that /index.php/ url part). Dan On Sun, Feb 28, 2016 at 6:16 AM Sergey Sharybin <sergey....@gmail.com> wrote: > Dan, > > Well, it's definitely faster than my laptop. So screw it, gonna to sell my > laptop on ebay and buy two r210 for the same amount of money. One i'll > donate to you ;) > > Back to serious tho. > > Think we were not talking about putting manual back in there. That would > piss some contributors off even more. Dont' want that to happen. We've been > mainly talking about preventing further split of documentation any further. > So current manual will stay as it is now, but rest of docs will stay in > wiki. > > With a new wiki installed we can simply do the same as we did with manual: > instead of 1-to-1 data migration only migrate needed paged, fix links on > them and so on. Surely it's some work to be done, but that's still simpler > than fixing pages AND moving them to another system AND setting up another > system. > > > On Sun, Feb 28, 2016 at 3:00 AM, Trouble Daemon <troubledae...@gmail.com> > wrote: > > > Sergey, > > > > My point was that our R210 server where the docs are built is probably > > pretty similar to many users home machines, as far as full build time > > estimates are concerned. > > > > As for wiki, I agree it would be nice to reinstall it into a fresh MW > setup > > and clean things up. I worry though that there would be a lot of work to > > put the manual back into the wiki, not to mention the hundreds of man > hours > > put in sphinx that would be thrown out. Plus to use the wiki as the > manual > > again would mean old organization and layout headaches for versioning and > > localization URL schemes that plagued the old setup, not to mention poor > MW > > search system that returns wiki markup that people didn't think kindly > of. > > > > Dan > > > > On Sat, Feb 27, 2016, 8:34 PM Campbell Barton <ideasma...@gmail.com> > > wrote: > > > > > On Sun, Feb 28, 2016 at 11:48 AM, Sergey Sharybin < > sergey....@gmail.com> > > > wrote: > > > > Dan, i'm not talking about compilation on server, talking about > > > compilation > > > > on my laptop and desktop. > > > > > > > > Campbell, I don't follow IRC that much, but happened few times there. > > > > > > > > As for timing, while it's not exact 30min (at least not with latest > > > sources > > > > etc), it's an order of magnitude more on my core i7 desktop, took > > almost > > > > 10min to do a rebuilt. After doing simple modifications it's in > average > > > > 5sec. > > > > > > > > While content was based on existing wiki, remember how much effort > was > > > put > > > > to fix missing pages and broken libraries. > > > > > > > > In any case, we can compare who's machine is faster, it's all not > gonna > > > to > > > > make things faster here and it's not what's the thread originally was > > > about. > > > > > > > > Let me summarize and stop wasting time and energy in this discussion. > > > > > > > > - I am an opponent of increasing offline-factor of documentation, it > > just > > > > adds extra complexity without solving any real issues, or will have > the > > > > same technical aspect issues if they're becoming any more popular for > > > > editors. > > > > - I am also an opponent of using dev.b.o's wiki: it is a limited wiki > > > > engine, it would have more issues as any stand-alone wiki, it > wouldn't > > > > really be any more sustainable to abuse that the current wiki.b.o > and i > > > do > > > > not want dev.b.o being abused in any way. > > > > - I do agree with the fact that we should fresh install wiki and not > > have > > > > any piss-poor hacks in it, and keep it maintainable, accessible by > the > > > > community. > > > > - I do believe with freshly installed and properly configured wiki we > > can > > > > avoid splitting of any documentation further, and to keep > documentation > > > in > > > > an actual non-broken state we'll need a strong editor team (we'll > need > > it > > > > with any underlying tool for docs/manual, it's not something new, it > is > > > > just something current wiki is lacking completely). > > > > > > +1 this has been the plane for some time anyway, closed T47563. > > > > > > In the future it would be good if we could discuss topics without knee > > > jerk reactions and mixing up multiple topics. > > > _______________________________________________ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers