[sakai2-tcc] Infrastructure discussion for future meeting?

[David Adams]

Agreed, JSF belongs on the comprehensive list. Make it #23, or include
it under #2. My main point was that we could keep listing these items
forever, and we can argue about how they're ranked or what else
belongs. But none are going to get fixed until someone either a lot of
resources or some level of community leadership takes the lead. No one
has "a lot of resources". So the TCC's leadership position is all
we've got.

I firmly believe that if there were specific, clearly defined
improvements proposed to be tackled in discrete projects led by expert
TCC members, it would be a lot easier to recruit resources from the
community. I feel certain that if I told my boss and our dev manager
that there was a project underway to fix something like the back
button and tab issues in even just a single tool, they would support
giving over some, and perhaps a lot, of our local developers' time. But
so long as there's no leadership from the technical experts, it will
never happen. The *last* thing management would be willing to do would
be to dedicate 500 hours of developer time to a locally-spearheaded
improvement that might not make it into the next release, or any release.

-dave

David Horwitz wrote:
> If your going to include RSF on that list you got to have:
>
> 21) A widely used display tech (JSF 1) that is both unmaintaned and known to kill app servers
>
>
> D
>
>
> On Tue, 2013-03-12 at 09:38 -0500, David Adams wrote:
>
> 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