[sakai2-tcc] Infrastructure discussion for future meeting?

[David Adams]

Steve Swinsburg wrote:
> How can one figure out what resources need to be applied and what
> areas need attention if you don't know the issues?

Surely anyone reading this list could come up with a list of 20 high
priority items that need to be addressed in the CLE, without needing a
formal review.

How about:

1. Confusing build/deploy process that I don't believe anyone in this
   community fully understands.

2. Wildly outdated support libraries (thanks Noah for tackling this one).

3. Failure to support basic browser features such as tabs and the back button.

4. Non-normalized, unsearchable data in core tools such as Content.

5. Lack of support for database failover except through driver indirection.

6. Poor or non-existent logging of basic processes.

7. Users are bound to a single app server, making zero-downtime maintenance
   and high-availability very difficult to achieve.

8. An authz system that scales poorly and is near impossible to maintain.

9. An API tightly bound to the particulars of the portal/portlet presentation.

10. Outstanding security issues in both unmaintained and brand new core tools.

11. Runaway database activity in most hibernate-based tools.

12. Serious lack of anything beyond the most basic administrative tools.

13. No support for a departmental tech support or junior administrator role.

14. Complete lack of inter-tool database relationships, sometimes even a
    lack of anything that could even be *used* as a pseudo-foreign key.

15. Lack of an asynchronous request system for long-running processes.

16. Incomplete and inconsistent archive/restore support.

17. RSF.

18. No clear separation between core functionality and toolset.

19. No registration of allowed property values by tools.

20. Two configuration systems munged together: properties and Spring.

21. A site management tool that's confusing and overwhelming, both to
    end-users and to developers who might want to clean it up.

22. A source code base that's full of redundant and inoperative code
    not to mention transition steps from half a dozen versions ago that
    still run at every startup.

Oh wait, I said just 20.

The last thing we need is for the best technical minds in the
community who understand Sakai's internals better than anyone else to
be spending their time running process audits and surveys to make a
carefully prioritized list of action items complete with work
estimates, full community input, and committee approval.

>From the outside, what I'd love to see is a short list of clearly and
narrowly defined improvement projects (pick one or two from my list)
that would benefit everyone who runs Sakai to take on for the next
version that I can take to my management and say: "Here's something
we've been griping about for years, and the TCC wants to fix it. Can
we commit some of our personnel to assisting with the effort?" Without
a clear project to put them on, it's nearly impossible to get any
traction with the decisionmakers.

What's chosen doesn't have to be vetted by multiple layers of decision
makers and processed through focus groups or ranked against a list of
alternatives. You guys know where the problems are, I hope. But none
of these things can be fixed without focus. The TCC needs to pick
something broken and take the lead to fix it. Then move on to the next
thing. That's the only way Sakai will truly improve.

-dave