[Building Sakai] [Management] FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

[May, Megan Marie]

I'm not sure what is meant by 'alarming.'   My point is that there is no clarity when it comes to understanding what to expect as the community ramps up for a software release, how decisions are made and when the community should expect (rely on?) the varying teams to be involved.  

As someone that used to live and breathe this stuff, it increasingly seems as if we've flying by the seat of our pants.  Perhaps it has always been this way and I've gained some clarity with distance.  Regardless, I think these are points that should be crystal clear to the entire community.    

Just my 2 cents,
Megan
-----Original Message-----
From: khomotso at gmail.com [mailto:khomotso at gmail.com] On Behalf Of Clay Fenlason
Sent: Friday, March 12, 2010 5:01 PM
To: May, Megan Marie
Cc: management at collab.sakaiproject.org; production at collab.sakaiproject.org; sakai-dev at collab.sakaiproject.org Developers
Subject: Re: [Management] FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

I've been a little puzzled about why these recommendations are for 2.7
as well. How this came about was that the Product Council has some
Sakai 2 tools in incubation, and we were talking about them in the
context of additions to new Sakai releases in future. David Horwitz
made the very good point on the management list [1] that we should be
thinking about subtractions as well as additions. Since the
maintenance team is well positioned to see where the maintenance
challenges are, I answered by asking a question: if the team might be
able to make some recommendations. I'm grateful that they've done so.
But coming from that context I had also imagined that we would be
talking about the post-2.7 case, and could think them through
carefully over an extended time. That these have become 2.7
recommendations has, I'll admit, caught me off guard.

Apart from that, I'm not certain why it should be alarming that anyone
is making recommendations. Recommendations are not binding, anyone
could be offering them, but these do offer some perspective from those
closest to the code. It's at the very least a good conversation
starter. We don't, for example, have a clear and documented
deprecation policy, and this set of examples provides a good
opportunity to talk through cases and try to arrive at such clarity.

I am, however, proceeding from the standpoint that cutting things out
of 2.7 at this point would call for rather exceptional circumstances,
and I'm not sure any of these items call for such action. We need to
talk this through. I am going to use these cases to try to draft a
deprecation policy - with help, and I'll work to make a start this
weekend - that we can iterate on and come to some consensus. I'd
encourage us all to weigh in on these recommendations, and I've got
some of my own thoughts to put forward on the particulars, but for the
moment let me just reassure that no one is about to do anything
precipitous.

~Clay

[1] http://n2.nabble.com/Product-Council-Meeting-Reminder-tt4621838.html#a4621838

On Fri, Mar 12, 2010 at 4:03 PM, May, Megan Marie <mmmay at indiana.edu> wrote:
> I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.
>
> The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.
>
> Megan
>
>
> [1] http://confluence.sakaiproject.org/display/MNT/process
>
>
>
> ---------- original message ----------
> Date: Fri, 12 Mar 2010 13:25:04 +0000
> From: Aaron Zeckoski <azeckoski at unicon.net>
> To: Clay Fenlason <clay.fenlason at et.gatech.edu>
> Cc: management at collab.sakaiproject.org, plumbers at sakaifoundation.org
> Subject: MT deprecation recommendations for 2.7
>
> Product Council,
>
> The maintenance team (MT) has discussed what should be deprecated for
> 2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
> release.
>
> When we say "remove from the build" we mean that the tools should
> remain in the checkout (exports) but they will not be built and
> deployed. Schools which need these tools can uncomment their entries
> in the main pom file.
> When we say "remove from the release" we mean the tool would not be in
> the build or checkout. It would optionally be moved over to the
> contrib space after the 2.7 release is complete.
>
> Here are our recommendations:
>
> 1) OSP reports and warehouse tools - OSP is outside of the maintenance
> team coverage and parts of it are beyond our capacity to maintain. We
> recommend these be removed from the build.
>
> 2) Mailtool - This has already been deprecated and has a number of
> outstanding issues and no maintainers. We recommend it be removed from
> the release. Mailsender will be added to the experimental build as a
> replacement option but not enabled in a default build.
>
> 3) Blog 1 (blogger) - This is not being maintained, has many
> outstanding issues, and there are 2 possible replacement options. We
> recommend it be removed from the release. We are still reviewing the
> replacement options (blog 2 wicket and blogwow) and will have a firm
> recommendation next week.
>
> 4) Profile 1 tool - Profile 2 is already in place as the replacement
> for 2.7 however there are still dependencies on Profile 1 tool in the
> codebase. MT will remove these. We recommend the profile 1 tool be
> removed from the release.
>
> 5) Presentation tool - This has been deprecated and is not being
> maintained. We recommend this be removed from the release.
>
> 6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
> burden and does not appear to be used. It increases the memory profile
> and complexity of the kernel even when not in use. We recommend it be
> removed from the release. JCR was meant as a possible replacement for
> the content hosting service but this was not completed and there is no
> one to maintain this code.
>
> 7) Static covers - The covers are out of date (missing methods) and
> not being maintained. Use of these has been discouraged since 2006. We
> recommend these be marked as deprecated. We will also send a note to
> the dev list to discourage their use clearly. The MT (and others) will
> replace usage of these as they are encountered.
>
> 8) Kernel utils - These homegrown utils tend to duplicate other open
> source libraries. They also have issues in the way they are
> implemented and sometimes even duplicate their own functionality. We
> recommend the duplicative ones be marked as deprecated. MT (and
> others) will replace these with usage of open source libraries as it
> is encountered. Some kernel utils will be updated to use the open
> source libraries by the MT. MT will also send a note to the dev list
> to discourage the usage of deprecated kernel utils.
>
> Thank you
> -AZ
> MT lead
> http://confluence.sakaiproject.org/display/MNT
>
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>