Re: BiDi, Unicode 6.3 and Wine.
While I have no experience contributing code to wine itself so far, BiDi or not, I smell a high-level design choice here. If the new revision to the Unicode algorithm looks superior, my first idea would be to try rebasing the code on that and then explicitly overriding it for Windows quirks. I don't know enough about wine's code or performance issues to advocate when that redirection should take place. I suppose it could be done during compilation and linking, during runtime, or even by just hard-coding and commenting standards and quirks versions in the source. Mine's not the most informed opinion though so I would take it with a grain of salt. -Kyle On 10/04/2013 07:54 AM, Aric Stewart wrote: Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric
Re: Wiki RFC: Redirects, swarm tactics, etc.
Thanks everyone, I've created a table of all of the pages that seemed relevant at http://wiki.winehq.org/WebContentTasks/WikiParty. I put down details on that page and its parent instead of cluttering up this email. On 08/02/2013 06:49 AM, Rosanne DiMesio wrote: By any chance do any of those fixes/branches take care of http://bugs.winehq.org/show_bug.cgi?id=28578? That bug stops me from touching any page with preformatted text on it, specifically the FAQ, which is the one page I use most often and need to be able to update. As for the preformatted text issue, I actually just tried a few things in the sandbox and you can cancel the exorcism. I'm seeing it too. It seems to be specific to the GUI editor so if you don't mind using the text editor in the short term, that won't choke on the preformatted text. I'll post my thoughts in more detail on the bug report. From http://bugs.winehq.org/show_bug.cgi?id=33470#c6: disable new user registration and force users to manually request accounts. Then for the spammers, I'm with the discussion in the link. We have a lot of valid links to resources, and restricting all external sites would cripple the wiki much more than the spammers, but having to request an account sounds reasonable to me. I doubt someone familiar with Wine and interested enough to edit the wiki would be discouraged by a short confirmation process. -Kyle
Wiki RFC: Redirects, swarm tactics, etc.
So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. 1. Do we want some kind of guideline on redirects for the wiki? Some stable interface pages to the main site might be good, but beyond that, I think minimizing redirects makes sense in this use case. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts? 3. There are actually a few more fixes to the theme code at the head of my bitbucket repo (and also branches for 2 different Moinmoin upgrade paths). I'm cool with keeping the theme code for the near future; if and when we move it onto WineHQ's git server though, just let me know so I can note that I'm not upstream anymore. 4. Finally, spammers... they keep coming... and they're getting smarter. We can mostly stalemate them with the regex filter, but it blocks legit edits too sometimes (in very annoying fashion). In fact, I think there are a few of them that have learned to turn the filter against us by completely wiping pages with false positives so we can't revert the page. Are there any relatively easy things we could do to cut the spam? I don't know, but it's possible the newer version of Moinmoin has more potent anti-spam tools. -Kyle
Re: Fresh WineWiki Theme, Straight from the Farm
On Sun, Apr 7, 2013 at 8:43 AM, André Hentschel wrote: First: Wow! You did a great job! Finally our Wiki theme is up to date :) I had a look at some Pages already and they look perfect here with FF 20.0 What i wonder is how we want to proceed with tables, i've seen different tables already and we should maybe choose one style: http://wiki.winehq.org/FOSDEM2013 http://wiki.winehq.org/Gecko - Here we used a workaround for the missing boarders and spacing http://wiki.winehq.org/Recommended_Packages - strange HTML http://wiki.winehq.org/Portability Thank you for the compliment! I just pushed Dimi's changes (I reset the author flag to him used the time of his email for the date) and my own last set of changes to my repo. If everyone wants, we could probably put the upstream repo on WineHQ now. After a bit more testing, I was actually able to figure out the other problems. The overflow issue was coming from a subtlety with absolutely positioned elements (if no explicitly positioned container exists, the container defaults to the browser window, not the page). I also fixed the problem where any link in a message box was being rendered like the clear button. The other funky rendering I was seeing actually has nothing to do with IE or the CSS. I forgot but Moin 1.5 doesn't spit out strict HTML4 so my browsers were defaulting to quirks mode. I guess the standalone server injects a doctype declaration though, which is why I wasn't seeing the problems in testing. Those problems should go away once upgrading to Moin 1.9. And regarding the tables, I'm cool with whatever style everyone agrees on, but I don't know how everyone feels about setting styles in the wiki- markup. Moin (1.5 at least) doesn't use th elements so I created a custom CSS class for tr elements called heading. It just makes the text heavier in print view, but on screen, it's like a heading row on the other pages, only with a wine-red background instead of black. - Kyle
Re: Fresh WineWiki Theme, Straight from the Farm
On Sat, Apr 6, 2013 at 5:14 PM, Dimi Paun wrote: I've actually deployed your theme to production already: http://wiki.winehq.org My only change was this: diff --git a/winewiki.conf b/winewiki.conf index 4e79248..e3da9cc 100644 --- a/winewiki.conf +++ b/winewiki.conf @@ -8,7 +8,8 @@ #RewriteLog /var/log/httpd/rewrite.log # map some static files to their respective locations RewriteRule ^/favicon.ico$ /var/www/wine/wiki/favicon.ico [last] - RewriteRule ^/logo.png$ /var/www/wine/wiki/logo.png [last] + RewriteRule ^/logo_glass.png$ /var/www/wine/wiki/logo_glass.png [last] + RewriteRule ^/logo_text.png$ /var/www/wine/wiki/logo_text.png [last] # map /wiki static files to Moin htdocs RewriteRule ^/wiki/(.*)$ /usr/share/moin/htdocs/$1 [last] # map everything else to server script Oh, cool! Don't worry about taking time to reply, I know when people are busy it's good to follow up just now and then. I'm looking at it right now on some of the computers in my apartment's business office it does seem to be causing IE 8 9 some problems. One of them has Firefox 3 though (they go a while without updates), and even for that old version, there are only a few issues I can see. I'll get my laptop out in a little bit to check it on newer versions of the major browsers, and over the next few days, I'll try to iron out any IE issues and last wrinkles. After that, I guess the next order of business will be to see about moving the repo onto WineHQ. - Kyle
Fresh WineWiki Theme, Straight from the Farm
So as usual, my estimate of how long it would take was way off, but I'm finally done adapting the WineHQ theme to Moinmoin. It's not perfect, but I feel it's ready to submit for switching over. I've tested it in Firefox, Chromium, Midori, and Opera (briefly in IE8 IE9 too). I did do everything through Moinmoin's stand-alone server, but while I know there always seem to be ghosts in the machine, I'm guessing that Apache shouldn't interfere with layout issues. I mostly followed the WineHQ current WineWiki theme for large things, just tweaking the CSS to make it fit what Moinmoin spits out. I did make more design choices of my own on the smaller stuff though. After wrestling with Moinmoin's theme system, I was surprised how many things are still hard-coded (at least as of v1.5). For example, Moinmoin wraps some things in divs without providing a CSS class for the div, just the child element. The fortune cookie on the RecentChanges page the edit page are two cases of that. The dummy content in the search bar is another tricky one. It's set in the javascript for the search bar (don't remember where it was in the source tree) so I left that one alone. One other tricky issue was handling overflows RTL support. They both seem to work ok in isolation, but go crazy when you mix them. I haven't checked RTL in IE, but if you force an RTL page to overflow in Webkit, it positions things based on what's actually in the window (so the sidebar winds up floating in the middle of the page). Firefox simply doesn't try to apply any of the overflow rules in RTL (which I guess is nice in a Hippocratic sense). Opera alone handled things exactly like I hoped. As for the tables, I think they should display ok now, although I don't know if everyone wants my exact values for paddings such. The old theme had some table-based layout that may have had conflicting CSS rules, but I've div-vied everything up so the only table tags now should be when Moinmoin itself chooses them over a div and well... tables. I've pushed all of the changes to my Bitbucket repo at: https://bitbucket.org/kauble/wine-wiki-migration The refined branch is the one you want although I expect that once the code is hosted at WineHQ's git repo, it would become the new master branch. At that point, I can just reset my repo to point to the WineHQ one as the origin. - Kyle
Re: Updating WineWiki Theme?
On Friday, March 15, 2013 7:45 PM, André Hentschel wrote: What i'd like is that you first upgrade the theme for now, whatever changes it may need. For this task don't care about search fields, tables, sponsoring, ... The result should be a wine wiki with the same quality and/or bugs as we have now, just with a new look. After that is pushed and running and you fixed remaining bugs with the new look, you can then start fixing other bugs, changes things (keep in mind to talk to Jeremy Newman) and upgrade the wiki software itself. Sounds like a good plan. I've been testing the new theme with a v1.9 install of Moinmoin, but I should be able to create a branch and backport that to v1.5 pretty easily. After that, I can work on the tweaks and we can look into upgrading the underlying software. Dimi mentioned that he has some maintenance scripts written up, and I also have some on my Bitbucket account so getting the tarball up again and converting the data shouldn't take too long. - Kyle
Updating WineWiki Theme?
Hi everybody, Although my hiatus was longer than expected, I've been making progress with updating the wiki code over the past few days (spring break is a very good thing). My workflow is a bit non-linear so I want to sort my changes into patches first, but fingers-crossed, I'll be pushing them to my Bitbucket account by the weekend. I did want to ask for input on a few things: 1. Should we just keep Moinmoin's search, replace it with the custom Google search, or offer both? 2. How about the icon? I can get the standard WineHQ one to display fine, but I'm not sure about which approach to take. Essentially, do what's simplest for us, or should I make it play well with other themes too? 3. Finally, the credits are currently just text links. In the future though, if Dimi wanted to, we could have a sponsored by Lattica banner like the Codeweavers ones on the other pages. After I get the theme together test it some more on different browsers, I can look into migrating the data to the newest Moinmoin version. -Kyle
Re: Wine Wiki needs your help!
On Wed, Jan 16, 2013 at 12:19 AM, Juan Lang wrote: Could the password hashes be excluded from the regular tarball? E.g. using --exclude in the tar command? Sorry I didn't reply sooner, been a little busy the past week. I don't have a copy of the Wine Wiki data in front of me, but if I remember, the passwords aren't stored separately at the file level. Each user has a data file (and at least for v1.5, a .trail and possibly a .bookmark file). The password is stored as a single record in that file. I'm no security expert, but my gut feeling is that separating the password data by default might be a good change upstream. Short of that though, I fiddled with reading off each password, running it through bcrypt, then putting it back into place before packing up the files. It probably wouldn't be too hard to sift out the passwords before archiving the user directory. Ultimately, it seemed just keeping the user directory out of the open was the best bet though. My logic was that while there are several reasons someone might want to fork or independently archive the content (which is LGPL), I couldn't think of a legitimate reason someone would want everyone's account info without cooperating with the current maintainers. -Kyle
Re: Wine Wiki needs your help!
On Tue, Jan 15, 2013 at 1:06 PM, Dimi Paun wrote: Thanks everyone for your help! I'll take down the Pages spreadsheet. Now, what about the users? Those are files (not directories) so we don't face the same low limit (32k), but it would be nice if we could, somehow, cleanup those files as well. If I'm remembering right, a full install of Moinmoin (not just running the service portably in the unpacked tree) puts a moin command into /usr/bin. The documentation for it isn't great yet, but you can find it at http://master.moinmo.in/HelpOnMoinCommand. Unfortunately, it doesn't have a mechanism for cleaning out users beyond obvious duplicate accounts. One possibility that I was looking at is that v1.5 of Moinmoin updates .trail files for all logged-in users, even if the page trail display has been disabled. The idea was to scan the user directory for all .trail files with a mod-time older than a certain time period (I picked 1 year). If a user has logged in to do anything more recently than then, it should show up in the mod-time of the .trail file. I wanted to test my scripts a little more, but this was one thing my sweep-once script at https://bitbucket.org/kauble/moin-admin was designed to do. Besides blanking-out and putting file.new instead of file.tmp in line 96 of split-logs.pl, the logic seemed sound on small test batches. I wanted to try it on a full copy of the Wine Wiki just to be safe though. On Tue, Jan 15, 2013 at 4:40 AM, André Hentschel wrote: This should also speed up that old wiki and maybe helps upgrading it (hopefully that'll happen soon :D). I haven't touched a line of code in a couple of months (had a holiday job that really knocked the wind from my sails at times), but after getting settled into my classes over the next few days, I plan on working on moving the wiki to v1.9 of Moinmoin again. The one thing that would probably help a lot is if there was a regularly updated tarball of the wiki content either at WineHQ or Lattica's FTP again. I haven't messed with cron itself much, but my archive.cron script should pack up the files correctly. The main complication is that the user dir probably should be shared on a need-to-know basis because it contains weakly-hashed password info. Kyle
Re: Updated Wine Wiki Repo
On Mon, Oct 8, 2012 at 9:18 AM, Jeremy Newman wrote: I'd like to port our theme over to this. Also, yes, I think we should look into WineHQ hosting the git for this. I've played with the code just a little on my own machine and MoinMoin 1.9.5. I haven't made much progress yet; some of the old MoinMoin methods used for themes were deprecated. I've been able to make the old theme load, but it has several glitches. I was planning on trying to adapt the old theme to run on v1.9.5 exactly like it runs at the Wine Wiki. After that, I was going to work on importing the current WineHQ theme to MoinMoin. If I make any patch-worthy changes while the repo is on my account, I'll post them (probably in a branch so there can be some code review). - Kyle
Re: Updated Wine Wiki Repo
On Mon, Oct 8, 2012 at 5:17 PM, André Hentschel wrote: Am 08.10.2012 01:06, schrieb Kyle Auble: Just wanted to let everyone know I've created a git repo for the Wine Wiki from the CVS one at SourceForge. You can find it at: https://bitbucket.org/kauble/wine-wiki-migration Not sure if bitbucket is the right place, there are not much repos regarding wine. Have a look at github, there we have e.g. 49 wine forks (https://github.com/mirrors/wine/network/members) and it's recommended by http://wiki.winehq.org/GitWine There is also some wine-specific stuff on repo.or.cz, e.g. http://repo.or.cz/w/wine.git/forks I actually just chose Bitbucket for my personal code-sharing account (private repos, I've been using a lot of python recently, and sometimes I just have to be a silly, stubborn contrarian ;-) So Bitbucket just happened to be where I posted the repo. I'm hoping we can move it to WineHQ's git server relatively soon, but if anyone on Github wants to clone it too, that would be great. Since there are more people, it would probably be better for code review, and if someone else wants to manage it, I would have no problem setting my fork on Bitbucket to track a Github version as upstream. - Kyle
Updated Wine Wiki Repo
Just wanted to let everyone know I've created a git repo for the Wine Wiki from the CVS one at SourceForge. You can find it at: https://bitbucket.org/kauble/wine-wiki-migration Since it's a fresh repo, I thought editing the history should be ok (just moved the right info into Author Committer fields and made the commit message formatting more consistent). I do still have the unedited branches from cvsimport and can put those up too if there's any demand for them. I've been talking with Dimi about what we would need to upgrade MoinMoin, and once he can find some time, he said he would setup a regular archive of the Wine Wiki's data. I also like the idea of using tags to mark which wiki version is in use, but I'm not sure how many times the wiki has been upgraded. If anyone knows what versions of MoinMoin we've used and when the upgrades took place, I can add the extra tags. I don't know if there's much interest in just moving this to the Wine git repo yet. If not, I can probably review patches, but would be happy to add someone else as an admin if they have a bitbucket account. - Kyle
Re: Help getting amd64 assembly patch into wine?
On 10/03/2012 09:49 PM, Dan Kegel wrote: The main challenge was figuring out how to get the variable list of arguments off the stack, and then put them back onto the stack when calling the provided function pointer. This bit of varargs hackery can't be done in pure C as far as I can tell, so I used assembly. I started programming in machine language long ago, so getting that working wasn't too hard once I realized that's what was needed. Getting it to pass the Alexandre test is another matter. Alexandre did give feedback on one earlier iteration of the patch, telling me I was re-inventing the wheel, so I tossed my old assembly and copied the helper-calling code nearly verbatim from call_method in oleaut32/typelib.c I haven't studied assembly in a while, and I've never looked at this part of Wine before, but every once in a while, a silly question from a novice doesn't hurt. I'm just wondering is assembly definitely needed? This is just based on some googling and skimming through StackOverflow, but it sounds like you can still use va_list on amd64. It just takes some tweaking: http://stackoverflow.com/questions/8047362 One method involves a va_copy macro, but that may only apply to C99 or later: https://forums.oracle.com/forums/message.jspa?messageID=8536520 The other solution mentioned just involves wrapping va_list inside a struct, as mentioned in the top answer of the first link. I don't know if that helps or if I'm totally misunderstanding the problem. - Kyle
Re: WineHQ on CMS/Framework
Sun, Sep 23, 2012 04:33, Aleksey Bragin wrote: Two prototype websites were made, one using Drupal7 and another one (more recent and more complete) using Typo3. What's important is that we have a substantial set of interconnected services too: I honestly haven't heard of Typo3 before now (I guess it really hasn't caught on outside the German-speaking world yet), but my first impression is that may be closer to what we would want than Drupal. I've heard that Drupal can be very brittle and hard to use if your design doesn't fit a template. The fact that your T3 prototype is more complete despite being a younger site seems like a hint that it has been more productive for you. Being able to integrate most of your services with the CMS is also very reassuring. Have you come across a situation where you think having a framework would have helped? The main scenario I'm picturing is if someday we wanted to combine data from different parts of the website (for example, bugzilla queries along with related git patches). That may be overdoing things, but I feel like those cross-connections are one of the main things that could really help WineHQ. Right now it seems like there's a lot of good information, but it may be spread out over forum threads, mailing lists, the wiki, AppDB, etc. with no simple way to connect the dots (even after using search). - Kyle
WineHQ on CMS/Framework
After working on the wiki for a while, I finally wanted to ask about possibly moving WineHQ to a CMS or web framework. First off, while there are a couple of mentions on the wiki and mailing lists, is there still much interest in doing this? If there is, I think the second question is which kind of system do we want to use? While http://wiki.winehq.org/WinehqDesign mentions Drupal, which has a lot of plugins and features for easy editing, I've read that a CMS can become a hassle if your website needs to do more complex things than serving regular chunks of content. WineHQ provides a bug-tracker, a forum, a wiki, mailing lists, source-code browsers, and other tools besides static content, with lots of interconnections between them. If we did go with a web framework, we could still probably run a CMS on top of it for the AppDB and static pages. Finally, for the frameworks, it seems that one of the main differences is simply which language we want to deal with. Is there a strong preference for using a specific language? Right now the various parts outside of Wine proper use a mix of Perl, PHP, and Python. This also raises the question of whether there's any desire to (over the very long term) try consolidating all the code outside Wine around one or two languages. I'm guessing it wouldn't be worth the trouble (different tools for different jobs), but if there is a strong reason to, it would probably be good to pick a framework in the language we want to emphasize. - Kyle
Translations of the About Pages
I just submitted a draft rewrite of WineHQ's About page in English that integrates some things from the wiki page, but there are still Hebrew and Spanish about pages on the wiki. I started working on translating the Spanish one, but realized someone else should probably do it after one paragraph, and my Hebrew is even weaker. I think the goal is still to move all central pages to WineHQ so I'd like to remove those versions from the wiki soon too. If any Hebrew or Spanish-speaking contributors would prefer to work from the wiki content though, I can leave it up for a while. If you would rather translate from the new English version to keep the different translations in sync though, I'll go ahead and clean up the wiki some more. - Kyle
Re: Moving pages to/from wiki
Thu, Aug 30, 2012 11:55, André Hentschel wrote: Am 30.08.2012 04:32, schrieb Kyle Auble: As for redirecting to http://www.winehq.org/cvs, since that was designed as a notice page for people trying to browse the source code, I was picturing just redirecting the links to http://source.winehq.org/git and deleting http://www.winehq.org/cvs as only WWN issues and news would still have dangling links. I don't want to remove it if there's another reason for keeping it though. please don't remove it. there's still much linking to it on the web, or hiding links, like in sourcecodes somewhere OK, sounds good. I'll leave the CVS notice pages but update the links. - Kyle
Re: Moving pages to/from wiki
Thu, Aug 30, 2012 12:23, Michael Stefaniuc wrote: On 08/30/2012 06:05 PM, Jeremy Newman wrote: On 08/29/2012 09:32 PM, Kyle Auble wrote: just checked http://cvs.winehq.org and sure enough, there is still a very outdated CVS repository there, but I can't find a template or a PHP applet for it, just the same links you found (most in WWN issues). I've CCed Jeremy Newman because I'm guessing the site admin would have to remove it. I am not opposed to removing it. We had left it up as a historical archive, or for people that were not ready to switch to GIT yet. If there is consensus then I can certainly take it down. According to Alexandre it is used by http://source.winehq.org/ for the Wine Cross Reference. Ahhh, that certainly changes things. Does the server have to run a CVS instance to generate the web interface? If so, and if it's possible to somehow store the CVS data somewhere else, it might not hurt to consolidate it someday. That's really distant, low-priority stuff though. I'll remove the line from the WineHQ Todo list and make a note on the wiki SourceCode page so no one gets confused. - Kyle
Moving pages to/from wiki
I'm starting to work on moving static pages to and from the wiki, but I wanted to ask for opinions on a few changes first: 1. Move all static IRC pages to the wiki or add info from the wiki to the static templates? The static pages only mention #winehq and don't describe guidelines, but IRC details shouldn't change much right? 2. For the static About page, some languages also have wiki versions. Do we want to keep the sparser versions currently in use, or add the more detailed information from the wiki version? Both versions seem well-written, and exist for English, Hebrew, Spanish (I deleted the Polish wiki version; it was a duplicate). 3. Do we still need the static cvs page, or should I just redirect any links to it, then delete? On a related note, the WineHQ ToDo on the wiki still claims that a browser for the old CVS source tree is lurking on the site somewhere. Is that true, or do I need to cut that line from the ToDo list? 4. Since licensing tends to be really static could we just redirect the WikiLicense page to the static license page, or should they be kept separate? While I'd think it wouldn't be too hard to reword the static page's intro to include other projects, I'm leery of editing any legal-ese without asking first. By the way, the WikiLicense page says it's LGPL v2.1 in the intro text, but the included license actually looks like v2.0 of the GPL with a modification for libraries. If the wiki version of the page should stay, I'll put in a copy of v2.1 - Kyle
Re: Moving pages to/from wiki
Wed, Aug 29, 2012 16:09, André Hentschel wrote: get the website source and do grep -Ri cvs * then ignore wwn/ and news/ ... all that should somehow bring you to http://www.winehq.org/cvs or be deleted grep -r * is rapidly becoming a very good friend of mine ;) I just checked http://cvs.winehq.org and sure enough, there is still a very outdated CVS repository there, but I can't find a template or a PHP applet for it, just the same links you found (most in WWN issues). I've CCed Jeremy Newman because I'm guessing the site admin would have to remove it. As for redirecting to http://www.winehq.org/cvs, since that was designed as a notice page for people trying to browse the source code, I was picturing just redirecting the links to http://source.winehq.org/git and deleting http://www.winehq.org/cvs as only WWN issues and news would still have dangling links. I don't want to remove it if there's another reason for keeping it though. - Kyle
Re: About WineHQ Wiki
Tues, Aug 28, 2012 4:47 AM, Oleg Yarigin wrote: Now I wait an answer from Dimi Paun. Well, in addition, how do you think, is any necessarity there to move wine site and wiki from Apache to Cherokee? While I think it's good to keep alternatives in mind as new technology comes out, I wouldn't want to switch the actual http server out until it starts having noticeable problems, or in the distant future once higher priorities have been taken care of. For me, WineHQ itself seems to be really fast, and as we were discussing earlier in the thread, the wiki is hosted at Lattica, which may not have the same hardware resources or bandwidth of WineHQ. If you're mainly noticing problems with the wiki, that may also be that we're using an outdated version of moinmoin. Cheer Xiao was saying that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend upgrading Moinmoin, then converting the pages to Mediawiki syntax. I've never run a real Apache server myself (just played with it on my computer), but while it can be a pain to set up, it is battle-tested. Since the site admins would have to do all the dirty work, I feel like this should be their call in the end. However, I believe all the content on WineHQ the wiki are under the LGPL so if you really wanted to, I'd think you could try testing a mirror of the site as a proof of concept, running Cherokee on your own computer. If you can show the advantages outweigh the trouble of switching over, the site admins would probably be more willing to consider it. Rather than switching out the http server, I think there is some interest in moving WineHQ over to a web-framework/CMS. I wanted to handle the wiki first, but afterwards if there's still demand for it, I'd like to try helping make the jump to a CMS. -Kyle
Re: About WineHQ Wiki
Sorry if my replies come in large batches, I'm subscribed to the mailing list digest. Sun, 26 Aug 2012 10:08, Cheer Xiao wrote: Hi all, I'm a MoinMoin contributor, one of MoinMoin's participating students in this year's Summer of Code. 2012/8/26 Kyle Auble randomidma...@yahoo.com: Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: When I edited pages in the WineHQ Wiki, I notised, its markup lankuage isn`t so good as MediaWiki`s one. How do you think about moving the Wiki into MediaWiki engine? Besides, moving each language section of the Wiki into separated subdomain (like in Wikipedia) would be a good idea too. There are some pluggable parsers for Moinmoin, and there may be one that allows MediaWiki syntax. After going through and checking, categorizing, and editing so many pages, I definitely agree with your suggestion that each language be given a domain, instead of one flat namespace. Then maybe just add a single common translation menu to the side toolbar? Indeed there is a MediaWiki parser[1]. Also, take a look at MoinMoin 2.0[2]. It has multiple markups support out of the box (including mediawiki of course). You can even mix them in a single wiki instance - this is not necessarily a good idea, but it helps when you have to migrate some content from another wiki by hand. ... Feature requests are welcome, but be noted that MoinMoin 2.0 is the current development version (it's not a development branch since the codebase is almost a total rewrite) and quite likely the feature you want is already there (or a TODO). :) Hello, I'm glad to hear there's already a line of communication. Allowing people to use MediaWiki syntax will probably be a big plus. There have been performance problems, but I noticed both the Ubuntu and Moinmoin wikis are pretty snappy so I'm thinking it's due to a strained server and using an old version of Moinmoin (although the SystemInfo macro seems to be disabled, I ran across version info somewhere, and I think Wine Wiki is running Moinmoin 1.5 or 1.6). I'm not sure if other problems I've noticed have been fixed in v1.8 or 1.9 so I would have to try out those versions before checking against v2.0. One thing I have done is written up some python code to help convert HTML tables to Moinmoin ones. I checked in Moinmoin's script market, but could only find full-blown page converters, and their output was kind of messy. I probably got carried away, but I'll attach it to http://wiki.winehq.org/WineStatus because I'm using it to move WineHQ's static status pages to the wiki. I guess that would make it LGPL so if you want to salvage a few parts from it or have me submit it to your utility marketplace, just let me know. Sun, 26 Aug 2012 16:07, Andre Hentschel wrote: Further it seems a bit more complicated with Wine, the moinmoin wiki is sponsored by http://lattica.com/ (whatever sponsored means, didn't find further information) and the code is not accessable via a wine git repo (maybe it should be in tools.git, website.git or its own). This also leads to the fact that we still have no new wiki theme years after the theme change on the website. Now that we upgraded the Forum engine we (we as in laxdragon xD) could maybe do something about the wiki, it needs love. It seems Kyle is doing a good job at the content, but the content is not everything. Thank you for the compliment. I am actually planning on doing more coding soon, but besides ramping up, I though cleaning up the wiki some first would let me see where the different parts of the project are. Applying the theme from the rest of the WineHQ is on both the WikiToDo and my own list (no guarantees about how long I would take though). Sun, 26 Aug 2012 22:46, Cheer Xiao wrote: And yes, as I noted in a previous post moin2 is *not* production-ready yet and I don't suggest you jump ship now. :) What I do strongly suggest, however, is that you upgrade to moin1.9 first, since 1) there has been many security fixes[1] which are not backported to old versions, and 2) upgrade to moin2 will only be supported from moin1.9. Helping to upgrade the wiki is on my list somewhere between finishing a first round of polishing content and trying a couple of patches to Wine itself. Although the maintainer would actually have to deploy it, I could test and work some of the kinks out of the upgrade using a local install. Dimi Paun put a lot of work into setting up the wiki in the first place and is the maintainer at lattica. From the git logs and mail list, it seems like he has been really busy with other things for a while. At times, Jeremy Newman has raised the possibility of moving the wiki to WineHQ: http://www.winehq.org/pipermail/wine-devel/2006-June/048712.html I remember stumbling across another email too, but I can't find it right now. If it's still a possibilty, I think the first step would be somehow setting up datadumps so we could start on the upgrade. If there is already a feature for admins
Re: About WineHQ Wiki
Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote: When I edited pages in the WineHQ Wiki, I notised, its markup lankuage isn`t so good as MediaWiki`s one. How do you think about moving the Wiki into MediaWiki engine? Besides, moving each language section of the Wiki into separated subdomain (like in Wikipedia) would be a good idea too. I've been working a lot on the wiki recently, and I actually brought up something similar in this thread: http://www.winehq.org/pipermail/wine-devel/2012-July/096198.html While I'm busy with other things right now, I wanted to discuss this in more detail in the near future, particularly how it ties into possibly migrating the entire site over to a CMS. The Moinmoin syntax was new to me too, but after using it a little, I don't mind it too much. There are definitely a few missing features and rough edges compared to MediaWiki. However, and this is just my impression, I think MediaWiki has really evolved to fit Wikipedia's needs. I'm not sure how well it integrates (style-wise at least) if you don't run your entire site off of it, and while I haven't actually looked at MediaWiki's code, I've heard that it can be really tricky to setup, maintain, and reprogram. There are some pluggable parsers for Moinmoin, and there may be one that allows MediaWiki syntax. After going through and checking, categorizing, and editing so many pages, I definitely agree with your suggestion that each language be given a domain, instead of one flat namespace. Then maybe just add a single common translation menu to the side toolbar? I've come to the opinion that we should probably stick with Moinmoin, and migrate to a new engine other than MediaWiki only if there are strong reasons. What might be best is if we actually got in touch with some of the Moinmoin developers and put in some feature requests. Helping with the wiki's engine is on my list so I'd like to hear some more opinions. -Kyle
Re: Policy for the Wiki?
On Friday, July 6, 2012 at 3:14 PM, Austin English wrote: Dimi Paun (CC'ed) set up/runs the wiki, so he'd be the guy to ask. Other people have discussed MoinMoin/alternatives before, but to my knowledge, there hasn't been much effort put into changing it. Thanks for the suggestion. I've looked into the moinmoin code a little more, and Dimi already switched out the cgi module. Besides possibly updating to a newer version and adding Xapian search, there may not be much more that can be done on the software end. Ubuntu wiki is fast and it apparently uses moinmoin so it could just be server resources too. If that's the case then moinmoin is probably still the best choice: uses python, no database required, customizable, and it seems to be the main alternative to MediaWiki. On a side note, is there any talk of moving the wiki code from the sourceforge CVS repo to a Git one at WineHQ someday? -Kyle P.S. Sorry about the word-wrapping in my last email. Yahoo zigged when I thought it would zag.
Policy for the Wiki?
Hello all, I've been working on the wiki recently and noticed that a lot of out-of-date or redundant information is retained. For example, completed tasks on to-do lists are checked off and never removed. Isthere an unofficial policy of not deleting info, even if it may exist elsewhere (in the git repo history, wikipage revision history, etc)? Other instances might be stubs dedicated to features in development years ago, or pages on bugs that have already been fixed or triaged in Bugzilla.I know even page deletions can still be reverted, but I wanted to check first before cleaning things out more aggressively. If there are a few unwritten rules everyone likes the wiki to follow, I could add them somewhere as editing guidelines. While the topic's up, I was also wondering how moinmoin was chosen as the wiki engine. I couldn't really find a discussion on the mailing lists so I figured it was the best option when the wiki was first started. I can appreciate that it doesn't require a database and it's written in python instead of php. Allowing only inline CSS in tables causes some headaches, but mainly it can be really slow sometimes, especially when editing, and unless using wikilinks or going directly to a page, navigation is tricky. Has the possibility of migrating the wiki to a different engine ever come up? Or does the Wine wiki code just need some tweaking and maybe some tools? To be honest, I don't know if there is a better alternative (MediaWiki is designed for a very different use case and has really messy code). It just seems like something is discouraging even basic upkeep on the wiki, which kind of defeats its whole purpose. -Kyle
