Last modified: 2013-10-05 17:41:16 UTC
To be determined... ;)
Turning this into a mini tracking buglet. *** Adding andrew to cc Adding blockers Adding keyword
Now ready to deploy to smaller sites, on the condition that the namespaces are localised.
Brandon and Andrew, is it still appropriate to ask Ops to get through this backlog, or do you prefer they hold off until the next version of LQT?
I'd prefer to hold off.
"Next version", what does that mean? Should a new dependency be recorded? Swedish Wiktionary (bug 25761) has now waited 2 months. How many man-hours does the activation take for one site? Why is that part complicated?
(In reply to comment #5) > "Next version", what does that mean? Should a new dependency be recorded? > Swedish Wiktionary (bug 25761) has now waited 2 months. How many man-hours does > the activation take for one site? Why is that part complicated? Activation takes less than one man-hour, that's not the problem. I think Brandon wants to hold off because significant parts of LQT are being refactored and redesigned in the coming weeks/months.
(In reply to comment #6) > Brandon wants to hold off because significant parts of LQT are being refactored > and redesigned in the coming weeks/months. We will get nowhere if we try do deploy some kind of "perfect" software.
I am not willing to deploy to other wikis with the current version of the software. There will be a new version within the next several weeks. Note that my opinion means doodley-squat with this. I have no authority to hold up deployments. I am, however, saying that *if you wait for just a little bit* then what we deploy will be *significantly better*. So take that for what it is.
(In reply to comment #8) > I am, however, saying that *if you wait for just a little > bit* then what we deploy will be *significantly better*. Swedish Wikisource already uses LQT and is perfectly happy, even though it took 4 months between request and activation. If the software is improved, I assume this would take effect there too. So what's the problem to activate the current version on Swedish Wiktionary? If it takes one man-hour, the WMF should be happy to pay for this. We have spent far more than one man-hour establishing community consensus and debating these bug reports.
Hi all, I've been thinking about this and having discussions with Erik, Alolita and others. As you know, LiquidThreads is undergoing major re-engineering, including updates to both the architecture and the user interface (documentation is being uploaded to MediaWiki.org as it is finished). You can find full details of this project at MediaWiki.org. [1] Having the old version of LiquidThreads in production adds complexity to the migration process that will occur once re-engineering is complete. It also means that engineering time would need to be spent supporting and maintaining the older version. This would distract from the development work that is currently in progress on LiquidThreads. Being the lead developer for LiquidThreads, my priority remains to focus on the re-engineering work that we are doing, so that we can start piloting the new version as soon as possible (hopefully by the end of March). Accordingly, it is our decision that further pilot deployment of LiquidThreads instances is placed on hold for the time being. LiquidThreads re-engineering will hopefully be finished in two to three months, and at that point we will be very pleased to roll out pilots to additional wikis. Thanks for your understanding, Andrew [1] http://www.mediawiki.org/wiki/Extension:LiquidThreads/Q1_2011_re-engineering
Andrew, do you know if LQT will be deployed across all projects? If so, I will close all pending requests in bugzilla (pointing to this bug).
(In reply to comment #11) > Andrew, do you know if LQT will be deployed across all projects? If so, I will > close all pending requests in bugzilla (pointing to this bug). Ashar, My understanding of the plan is that we will be deploying pilots on various projects (on an opt-in basis) before a global deployment. So the bugs can remain open for the time being. When we're ready to deploy, we can check with those communities that they still want to be a part of our pilot, and proceed with deployments. Thanks, Andrew
Please, when it will be ready don't forget about us. https://bugzilla.wikimedia.org/show_bug.cgi?id=25121
I hope the new version actually fixes most of the long standing problems that are present in the current version.
Adding tracking bug to the (main) tracker bug 2007.
*** Bug 29657 has been marked as a duplicate of this bug. ***
Closing this tracking bug. Lqt has been "ready", all dependencies have been closed. If you read this: Please consider giving *any* of the 120 or so open Lqt bugs some love.
It is "ready" but not "deployed". Most of the requests to deploy it are still marked as "LATER" not as "FIXED".
It's not (no longer) ready, which is why it's not further deployed.
Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116
Why was the development cancelled? Dont we need better discussion system on wikis to have bigger editor engagement?
Jan: Sure we need, and that's worked on. See http://www.mediawiki.org/wiki/Flow
See [[mw:Thread:Talk:Flow/LiquidThreads?]] for context. James has written elsewhere that work on Flow (not LQT3) will start in the second half of 2013, if I remember correctly; in the meanwhile we're not seeing any bug fix or improvement to LQT2 by the WMF, only new issues, <https://www.mediawiki.org/w/index.php?title=Extension:LiquidThreads&diff=593948&oldid=593256> so it's quite sure that LQT will not be enabled on any more wiki, but some pseudo-replacement will (in a couple years?).
Do we really need YEARs to develop a simple discussion system? That seems absurd to me... Flow is only targeted at User:Talk - that is great... so we will again be stuck with unusable discussions at article talk pages. This will never bring better editor engagement...
Feel free to contact the corresponding developers or ask on a mailing list. In a bug report categorized as setting up extensions (handled by people with shell access) it's very unlikely that developers of some specific extension will see your questions.
