To be determined... ;)
To be determined... ;)
"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.
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.  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,
(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).
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.
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.