Close/move issues related to LiveTable?

Development
#1

Hi devs,

Now that we have progressed enough on LiveData, we need to decide what we do with all open LT jira issues

I propose the following:

  • Officially mark LiveTable as deprecated once we implement Loading... (the last feature available in LT but not in LD)
  • Don’t work on improving LT, nor fix bugs (except for blocker ones). The goal is to spend all our energy on improving LD to the maximum and to migrate the remaining LTs to LDs.
    • Note: For blocker issues, they should be merged on the LTS too (15.10.x ATM)
  • Close issues in jira (as “won’t fix”) when an issue is for LT and doesn’t exist for LD (except for blocker bugs)
  • Move issues in jira from component = LiveTable to component = LiveData for all issues that also exist for LD

WDYT?

Thanks

See also Pagination template of LiveData and LiveTable - #2 by CharpentierLucas

Pagination template of LiveData and LiveTable
#2

As long as we haven’t migrated AWM to Live Data (which depends on the missing tag cloud support), I’m -1. Once we’ve added tag cloud support and migrated AWM, +1, sure. We could even discuss transparently replacing LiveTable by Live Data.

As we’re probably still a few months if not a full year away from this transition, I think this proposal is too early, and we should discuss again once the move has been completed.

#3

I’m not sure you what you really mean. I’ve mentioned that the deprecation would be only when the tag cloud is available.

Right now, nobody is going to work on, implementing any improvement for LDs (nor fix not important bugs), simply because if there’s time, it’s better used to migrate to LDs and improve LD. Also, this proposal is not about saying that a dev or contributor cannot work on fixing/improving something for LD (if we get a PR we’ll apply it if good enough ofc). The proposal is meant to be a statement that the XWiki devs are not going to improve LT and that all the work is going to be spent on LD.

Honestly, I’d find it very strange that we’d continue saying that we want to fix/improve LTs just because there’s one missing feature in LD (that is not used much either btw).

In fact my proposal was about stating and agreeing about what is currently happening…

#4

Imagine a user having a problem with a LiveTable that is generated as part of AWM, a flagship feature of XWiki, and then we just close this as “won’t fix”. What kind of signal does this send? That we’re not taking our flagship features seriously. That’s what I want to avoid.

Of course, we should focus the available development time on the Live Data migration, and it doesn’t make sense to work on improvements for LiveTable. But in my opinion, we should not actually close bug reports until we’ve officially deprecated LiveTable, which should be after migrating AWM.

1 Like
#5

Yes me too, but the close comment would explain that we’re working on fixing this by migrating AWM LT to LDs where the problem is fixed. Not that we’re not working on the subject.

I think a bigger topic is to decide if we’re going to do something to help our users migrate their LTs to LDs (this includes LTs generated by AWM).

Ok so let me change the proposal a bit:

  • Officially mark LiveTable as deprecated after all LTs have been migrated to LDs in XS (this includes having implemented Loading... since it’s a feature of AWM).
  • Don’t work on improving LT. The goal is to spend all our energy on improving LD to the maximum and to migrate the remaining LTs to LDs.
  • Close improvement issues in jira (as “won’t fix”) when an improvement issue is for LT and doesn’t exist for LD
  • Move improvement issues in jira from component = LiveTable to component = LiveData for all improvement issues that also exist for LD

This leaves out bug issues. I’ve also expanded the deprecation condition to not just Tag cloud + AWM migrated to LD but to all places in XS having migrated to LDs. It seems more logical.

WDYT?

Thanks

#6

I’m +0 for the updated proposal.