[sakai2-tcc] Infrastructure discussion for future meeting?

John Bush john.bush at rsmart.com
Sat Mar 9 21:21:46 PST 2013


I get the incubation idea for new stuff, fixing things before they get
to production and before everyone is using them is always easier, that
is common sense, I think everyone gets that.  But reviewing things
that are already out in the wild and being used seems a bit pointless.
 There is already an overwhelming amount of technical debt.  Sakai is
huge, to the tune of 1 million lines if you are running a few contrib
tools and your own stuff.  I think the problematic areas are already
well known.  An incubation process is never going to uncover anything
new or bring any focus to existing debt better than production and
maintenance experience has already produced.  In fact, what I think
turns people off to it, is that such a process could actually produce
the wrong focus.  I've seen this happen more times than I care to
count.

The nature of open source is we can never have one clear focus, this
isn't a top down type of structure.  There will in fact be winners and
losers and wasted effort, its a bit Darwinistic and probably not the
most efficient process because of that.  So anything that distracts
our passion/ our focus, is not always a good thing, which I think is
the risk with this whole incubation/review business.

I understand wanting to be proactive about quality that is admiral,
but in reality we have a giant long list of things that are already
understood and reactive in nature.  It seems it would make more sense
to simply focus on those, bringing in some process that isn't going to
actual produce anything new or bring into focus anything that is more
pressing then what is already known, seems a bit silly when we are
already under resourced.  Its just unfunded mandates at that point.



On Sat, Mar 9, 2013 at 1:48 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> Because there have been only two brief meetings and the work is very much in
> its infancy. As Ian mentioned, more will be released soon as to what
> incubation aims to achieve, and the whole thing will be public and everyone
> can have at it.
>
> I said fear because everyone has been very skeptical and said we don't need
> an incubation process and that its a waste of time. It's like people don't
> want to find the problems that this process will uncover.
>
> I've already put forward my wishes for a CLE review in multiple prior
> emails, and that is that 'all tools be evaluated against a set of criteria (
> code review, jira review, dev resources, licenses, internationalisation,
> community usage etc) so that we can identify issues that need to be focused
> on, identify tools that have a lot of technical debt, identify possible
> depreciations and promotions.'
>
> Cheers
> S
>
>
> Gesendent von meinem iPhone
>
> On 10/03/2013, at 0:37, Anthony Whyte <arwhyte at umich.edu> wrote:
>
> I read Ian's private comments and, in the main, they do not conflict with
> what I wrote below.  Second, I know of no one who is "afraid" of a CLE
> review.  Certainly, not me.  After all, I encouraged you in my reply to
> present a proposal to the TCC on the subject.  That hardly equates to fear.
>
> What baffles me is the apparent need for secrecy that mark these
> proceedings.  Why?  There is nothing in what Ian wrote privately to the TCC
> that should not already be public.  Moreover, whatever proposal you've been
> crafting should be undertaken in the full light of day in front of the
> community and not behind a curtain.  The IRG/IWG meeting notes don't cast
> much light on the subject either.  This all runs counter to the transparency
> that we aim for in open source.
>
> And one that I have presented to both the board and the incubation group and
> received positive support.
>
>
> Let's see your proposal.  Embrace transparency.  Put it in Github now.
> Invite public scrutiny whatever the current state of your proposal.
> Encourage comments and pull requests of text edits.  Stop misinterpreting
> skeptical or critical responses as fear and recognize instead that the
> debate is largely about CLE priorities.  Work to win hearts and minds as
> regards where this initiative should rank in order of importance or urgency.
>
> Cheers,
>
> Anth
>
>
> [1] https://sites.google.com/a/apereo.org/www/incubation
> [2] https://wiki.jasig.org/display/INCU/Incubation+Home
>
>
> On Mar 9, 2013, at 3:21 AM, Steve Swinsburg wrote:
>
> Further, I just read Ian D's post to the private TCC list and encourage you
> all to read it, and if not on the private list, just hang tight for a few
> weeks.
>
> No one ever said anything about policing, just a lightweight QA checklist
> that can be used to identify areas that need attention. IMO that will be
> very valuable information to have.
>
> Thanks
> Steve
>
> Gesendent von meinem iPhone
>
> On 09/03/2013, at 14:13, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>
> This really does reinforce the point that people are afraid of a review of
> the CLE.
>
> Ultimately it is my view that for all existing projects ( ie CLE, uPortal,
> all portlets, CAS etc,) that a lightweight checklist be applied to ensure
> quality and consistency. And one that I have presented to both the board and
> the incubation group and received positive support.
>
> How can one figure out what resources need to be applied and what areas need
> attention if you don't know the issues? All this aims to so is highlight
> those issues so they can be addressed, and so that we know the state of
> sponsored projects. And since sponsored projects will be Apereo projects
> there should be one process that suits all.
>
> It really baffles and disappoints me that people are against this idea.
>
> To reiterate, we already have a lot of these processes in place, they are
> too disparate though.
>
> We also have accessibility reviews taking place, should they stop also? What
> if someone introduced an incompatible license for a library or upgraded a
> version not knowing the license had changed (ala wurfl)?
>
> S
>
> Gesendent von meinem iPhone
>
> On 09/03/2013, at 13:29, Anthony Whyte <arwhyte at umich.edu> wrote:
>
> Steve--The Apereo IRG should focus its attention on developing a robust
> incubation process that encourages outside projects or products of the likes
> of a Class2Go or some other initiative featuring an independent codebase,
> development team and leadership structure to join the Apereo Community.  The
> IRG should avoid wasting time and energy on trying to mandate and/or police
> incubation/review processes or "quality checklists" for existing top-level
> projects like the CLE.
>
> A project like Class2Go--a purely hypothetical example--is a fit target for
> an IRG-led incubation process.  A new CLE service or tool is not.  We should
> leave it to the various Apereo software communities to both articulate and
> implement their own incubation/review/deprecation practices covering
> capabilities subordinate to and incorporated within existing top-level
> projects.
>
> If you think current CLE practices are deficient in these areas I recommend
> framing an actionable proposal and presenting it to your TCC colleagues for
> consideration.
>
> Cheers,
>
> Anth
>
>
>
> On Mar 8, 2013, at 1:56 AM, Steve Swinsburg wrote:
>
> Are you saying that there will be no incubation process within Sakai, or
> that you will oppose it, or that it wont matter too much when the process
> comes along? If the latter then thats correct, it's not going to impact
> anyone any more than adhering to a few simple principles.
>
> I dont see incubation being any barrier to forward progress either, it's
> simply a checklist of quality. We already have a number of requirements in
> place that people need to adhere to, e.g. not using incompatible licenses,
> making tools look roughly the same as the others, including i18n, ideally
> including help etc. Then to get tools into core we need committers and
> people running it in production etc. Those are already in place.
>
> All the incubation process seeks to do is gather all of that and formalise
> it so that people wanting to get an existing tool into a sponsored state
> (e.g in to the core of CLE) know what standards need to be met in order for
> that to happen.
>
> cheers,
> Steve
>
>
> On Fri, Mar 8, 2013 at 11:18 AM, Charles Severance <csev at umich.edu> wrote:
>>
>>
>> On Mar 7, 2013, at 2:57 PM, Noah Botimer wrote:
>>
>> But as far the CLE is concerned, I find the actual, present, technical and
>> coordination demands within our project of much more interest. I don't think
>> we have to wait for anything.
>>
>>
>> I talked extensively and directly with Ian about how incubation would
>> affect Sakai.  I reminded him that during merger negotiations two years ago,
>> incubation was characterized as additional resources rather than additional
>> hoops or additional paperwork or some new authority layer.  He agreed and
>> told me not to worry about incubation being a barrier to Sakai forward
>> process.
>>
>> I believe Ian.  So I have stopped worrying about it.   I am not wasting my
>> time thinking about incubation *at all*.
>>
>> /Chuck
>>
>>
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
John Bush
602-490-0470


More information about the sakai2-tcc mailing list