[Building Sakai] sakai-2.9.x-all build broken

[Matthew Jones]

Yea, it's a tough problem. The goals of the indies were admirable, but it
was a different time, when Sakai CLE had dedicated staff working directly
on the release and many more people in general involved in core tools. We
might get there again by next summer with Neal, but it's still a lot of
work to even depend on part time effort from a single person on.

When the concept of indies started a few years ago in 2.7 (2010) and even
still in 2.8 (2011) there were much more active development and more
individual project teams. As Steve said, these teams were doing out of
cycle releases for more projects. Aside from maybe Profile2 and Samigo, I
don't think anyone is strongly interested off cycle releases, since
everyone is depending on community QA. Lessons is technically an indie, but
Chuck has said because of QA he'll probably stick to the typical release
schedule.

Other than ~5 tools all of the other indies and other tools were updated by
the Maintenance Team, and the Maintenance Team collapsed into the Release
Team, which is relatively small and all volunteered time. Some of the
indies are indies *only* because some other tool depended on them, where in
most cases it really only depends on the api being released, stable and
available rather than the entire tool. Some of these went into edu-services
but many more projects didn't get refactored into there yet.

There are only two things I make priority for the release (working on it
myself on time volunteered from Longsight). Do all tools have released
fixed versions (not SNAPSHOT)? For 2.9.0 and all the indies I wasn't
concerned *what* version they were at, just that they had a version. This
guarantees that QA tests a version that is predictable and people can use.
I also needed to make sure the internal Longsight deploy/undeploy scripts
(which are essentially similar to what the undeploy goal would do
[SMP-10<https://jira.sakaiproject.org/browse/SMP-10>])
works so we can update code. Locally we deploy from the released tags as
well as maintenance branches and it generally does a good job cleaning up
first. We build and deploy binary overlays for everything (from
sakai:deploy), even non-indies, but it can't be extracted 'in-place'
without some kind of cleanup first.

I'm not entirely sure what the main goals of the indies were beyond kernel
but I can guess at some of them.

There are very few specific tools anymore that actually have dedicated
teams making decisions, planning roadmaps or working on fixes. Generally
this is all on the TCC or the release team. These were generally the indies
that existed in 2.7 (~14) and 2.8 (~19) In 2.9, many more projects became
indies (34). Some of this was because projects at the end of the chain like
Lessons and Samigo had dependencies on other tools (though really just the
apis). These core tools in turn required either becoming indies or being
re-factored into something like edu-services, even if nobody was dedicated
to releasing them. It also allowed for shorter build times and quicker to
track down bugs when these tools had errors, but that wasn't often a huge
advantage.

I feels like this was all done half-way, but it's tough as the person
working on the release is essentially just keeping the system running and
has very little time for innovation and making things *better* (large
refactoring). I think there were problems with the 2.5 style build system
and problems with the current system, but they're different problems. And
each has advantages and disadvantages depending on how much customization
(or how little) you're trying to do with Sakai. 2.9.0 was an effort to keep
the current system running and get something out, hopefully now we'll have
time to figure out something better. ;)


On Fri, Nov 16, 2012 at 11:10 PM, Steve Swinsburg <steve.swinsburg at gmail.com
> wrote:

>
> On 17/11/2012, at 11:05 AM, Seth Theriault <slt at columbia.edu> wrote:
> >
> >
> > On the subject of indie-fication, my personal opinion is that it's a
> > bit out of control and needs to be scaled back. Feel free to call this
> > re-evaluation if you like. It was said to greatly simplify release and
> > deployment, but I don't think it has seen the level of expected
> > benefits. If you look at the evolution from 2.6 (kernel is the only
> > indie) to 2.7 (couple of indies) to 2.8 (more indies), it got harder
> > and hard to keep track of what is actively being developed and what
> > was just being indie-fied for other reasons.
>
>
> Totally agree here. For example the portal is an indie, though its kind of
> a required component... IMO there should be a core set of components that
> allow Sakai to build and run. Kind of like what the cafe build use to be,
> the minimum. That should be the default source code. Then the rest of the
> tools are available as indies and then it becomes like a plugin based
> approach. Those that want to build everything from source still can by
> modifying the externals/msub.
>
> cheers,
> Steve
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20121119/280a7b2f/attachment.html