[sakai2-tcc] Emerging consensus to focus on 2.10

classic Classic list List threaded Threaded
36 messages Options
12
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

[sakai2-tcc] Emerging consensus to focus on 2.10

Hi All,

Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 



Supporting evidence
----------------------------------------
This consensus is based on :

* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 


* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release


Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   

2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).



If I have misstated anything, please feel free to correct me. 

Thanks!
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin










_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
May, Megan Marie-2 May, Megan Marie-2
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 

 

If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10

 

Hi All,

 

Summary

-----------------

There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 

 

 

 

Supporting evidence

----------------------------------------

This consensus is based on :

 

* The TCC discussion at Open Apereo 2013 (under future release cycles) - <a href="https://confluence.sakaiproject.org/display/TCC/2013&#43;Apereo&#43;TCC&#43;Meeting&#43;Notes">https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 

 

 

* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release

 

 

Additional thoughts

-----------------------------------

It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   

 

2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).

 

 

 

If I have misstated anything, please feel free to correct me. 

 

Thanks!

Neal

 

 

Neal Caidin

Sakai CLE Community Coordinator

Skype: nealkdin

Twitter: ncaidin

 

 

 

 

 

 

 

 


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

<base href="x-msg://404/">
2.10 shall be the version thou shalt develop, and the version of the development shall be 2.10. Not.

------

I don't think there can be any reasonable "position" on this issue. I'm belaboring the point, but I consider a controllable "development focus" on 2.9 vs. 2.10 to be a complete red herring. Almost as silly as my opening.

All developers involved will focus on what seems important to them and their organizations. 2.9.4 and 2.10 are not mutually exclusive as far development effort. Except where trunk has moved beyond compatibility with 2.9, all work should happen there. If a defect is present and important, it will be merged to 2.9.x. A rare, one-off for a defect in 2.9.x but not trunk is just that.

If people are interested in investing in new features, upgrades, etc., that interest should be curated and, to an appropriate extent, coordinated. For example, what on "Dave's list" seems important to the community and who is ready to work on any of it? If something is disruptive, let's discuss a timeline and mitigation. If something needs particular skills or resources, let's discuss it and maybe do some matchmaking.

But this is not a dictated "development focus". That is simply not something we can command.

If what we're saying is that QA is interested in testing the next major features/release because the 2.9 bug count is low, that's fine. If we're saying that developers are interested in developing new features/upgrades, that's fine. If we're saying that institutions are finding 2.9.3 solid enough and that they are interested in paving their future with features, that's fine.

My ultimate point is that this "focus" is really only a reflection. It's good to observe, but it is not a prerequisite to any work (on any release), nor can it be "shifted" forward except by work in trunk and a clear outline of how changes fit together, leading others across the gap.

Those who are interested in 2.10 should work on it and help coordinate it by being vocal about the specific features they are working on and think should be in our next major release. Nothing more, less, or different than ever.

2.10 with all due haste; 2.9 with all due conscience.

Thanks,
-Noah



P.S., Please forgive my ranting if I misunderstand the summary and question. I read it as excessive deliberation amounting to "we think we can do work soon; just need a few more converts". If it is more along the lines of "the 14 on the call have already been working on new stuff, so the calls are going to spend more time on those items", I apologize and applaud the movement.


On Sep 5, 2013, at 12:33 PM, May, Megan Marie wrote:

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 
 
If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   
 
From: [hidden email] [mailto:[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10
 
Hi All,
 
Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 
 
 
 
Supporting evidence
----------------------------------------
This consensus is based on :
 
* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 
 
 
* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release
 
 
Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   
 
2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).
 
 
 
If I have misstated anything, please feel free to correct me. 
 
Thanks!
Neal
 

 

Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin
 
 

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

Hi Noah,

Well, maybe it is a terminology thing, but I'm confused, because it clearly impacts my life and what I focus on, how I communicate, etc, as I'm confident you can imagine. Working with the TCC, CLE and others to set schedules, priorities, test plans, etc. So if we were to say that we are focusing on getting a 2.9.4 out by November, that would be a very different focus for me than if we focus on getting a alpha release (or whatever ) of 2.10 by November. In fact, I'm not even sure of the activities needed to get a 2.10 alpha/beta out, so that is part of what I'll be working on, understanding what is needed. I'm pretty confident of what would be needed if we try to get a 2.9.4 out.

I am probably missing your red herring argument. It's not making sense to me. It seems to me the more we are all on the same focus, the more effective we will be, and the greater the opportunity for achieving milestones and goals. I do see it as a focus and not merely a reflection. But maybe I'll have to fly up to Michigan to discuss, get some more coffee and some of those home baked cookies, just to clear things up ;-)

Cheers,
Neal




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 2:51 PM, Noah Botimer <[hidden email]> wrote:

<base href="x-msg://404/">
2.10 shall be the version thou shalt develop, and the version of the development shall be 2.10. Not.

------

I don't think there can be any reasonable "position" on this issue. I'm belaboring the point, but I consider a controllable "development focus" on 2.9 vs. 2.10 to be a complete red herring. Almost as silly as my opening.

All developers involved will focus on what seems important to them and their organizations. 2.9.4 and 2.10 are not mutually exclusive as far development effort. Except where trunk has moved beyond compatibility with 2.9, all work should happen there. If a defect is present and important, it will be merged to 2.9.x. A rare, one-off for a defect in 2.9.x but not trunk is just that.

If people are interested in investing in new features, upgrades, etc., that interest should be curated and, to an appropriate extent, coordinated. For example, what on "Dave's list" seems important to the community and who is ready to work on any of it? If something is disruptive, let's discuss a timeline and mitigation. If something needs particular skills or resources, let's discuss it and maybe do some matchmaking.

But this is not a dictated "development focus". That is simply not something we can command.

If what we're saying is that QA is interested in testing the next major features/release because the 2.9 bug count is low, that's fine. If we're saying that developers are interested in developing new features/upgrades, that's fine. If we're saying that institutions are finding 2.9.3 solid enough and that they are interested in paving their future with features, that's fine.

My ultimate point is that this "focus" is really only a reflection. It's good to observe, but it is not a prerequisite to any work (on any release), nor can it be "shifted" forward except by work in trunk and a clear outline of how changes fit together, leading others across the gap.

Those who are interested in 2.10 should work on it and help coordinate it by being vocal about the specific features they are working on and think should be in our next major release. Nothing more, less, or different than ever.

2.10 with all due haste; 2.9 with all due conscience.

Thanks,
-Noah



P.S., Please forgive my ranting if I misunderstand the summary and question. I read it as excessive deliberation amounting to "we think we can do work soon; just need a few more converts". If it is more along the lines of "the 14 on the call have already been working on new stuff, so the calls are going to spend more time on those items", I apologize and applaud the movement.


On Sep 5, 2013, at 12:33 PM, May, Megan Marie wrote:

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 
 
If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   
 
From: [hidden email] [mailto:sakai2-[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10
 
Hi All,
 
Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 
 
 
 
Supporting evidence
----------------------------------------
This consensus is based on :
 
* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 
 
 
* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release
 
 
Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   
 
2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).
 
 
 
If I have misstated anything, please feel free to correct me. 
 
Thanks!
Neal
 

 

Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin
 
 


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

I always use too many words. I wish I were more succinct and eloquent, but here we go...

Maybe I'm reading "we" too broadly, but I am allergic to any prospective, community-wide statements. That is, "we will" and "we are" should be much more qualified about who is or will be doing what. They should be statements of fact and commitment -- persuasion or debate about priorities should be completely separate (I suggest it is not very valuable in a broad context).

If you, and others on the calls, decide that it's time to coordinate activity around 2.10, just do it. There is no prerequisite -- not even 2.9.0 being released. The scale will tip by virtue of the scale being tipped -- others will follow if and when they are ready, but never simply because someone else is or says they should be. This is my excess deliberation bit -- just go and do. If people depending on 2.9 releases sense something wrong and need help, they will tell you and you can adjust.

To clarify my sticking point about development, I think that the focus issue is much more about where you spend your CLECC time, QA spends their time, and what bugs/features are discussed on the calls. Development is just development and it basically all happens in trunk anyway. If new features have more priority, it will feel like 2.10 is being worked on. If fixes are being made and merged for the stuff people are running now, it will feel like 2.9 is being worked on. But effectively all development is "for 2.10" -- the "development shift" happened around January, albeit without much strategy or coordination.

So, yes, it probably is just terminology. Maybe we mean coordination, QA, and mechanical release prep focus shifting to the next major release. And I do support that. With all due haste.

But you are definitely welcome to visit. :-)

Thanks,
-Noah



P.S., I think we should be talking strategically about two major releases. A way to earmark a feature/project for "not now, but definitely for next time" is long absent. Our classical "done" and "to do sometime" lists lose the value of identified priority items and the planning to mobilize them by piling them up with a bunch of stuff that isn't as important and causes endless, too-late rehash of the same list. See also, the excitement and pretty quick flatline around "Dave's list" -- not many of the items will be done for 2.10 and some of them are elephants we should start eating now, but we don't have a mechanism for talking strategically about "v.next".

P.P.S., I'll be quiet now. Development focus probably meant what you intended to everyone else. The more alignment the better.


On Sep 5, 2013, at 3:20 PM, Neal Caidin wrote:

Hi Noah,

Well, maybe it is a terminology thing, but I'm confused, because it clearly impacts my life and what I focus on, how I communicate, etc, as I'm confident you can imagine. Working with the TCC, CLE and others to set schedules, priorities, test plans, etc. So if we were to say that we are focusing on getting a 2.9.4 out by November, that would be a very different focus for me than if we focus on getting a alpha release (or whatever ) of 2.10 by November. In fact, I'm not even sure of the activities needed to get a 2.10 alpha/beta out, so that is part of what I'll be working on, understanding what is needed. I'm pretty confident of what would be needed if we try to get a 2.9.4 out.

I am probably missing your red herring argument. It's not making sense to me. It seems to me the more we are all on the same focus, the more effective we will be, and the greater the opportunity for achieving milestones and goals. I do see it as a focus and not merely a reflection. But maybe I'll have to fly up to Michigan to discuss, get some more coffee and some of those home baked cookies, just to clear things up ;-)

Cheers,
Neal




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 2:51 PM, Noah Botimer <[hidden email]> wrote:

<base href="x-msg://404/">
2.10 shall be the version thou shalt develop, and the version of the development shall be 2.10. Not.

------

I don't think there can be any reasonable "position" on this issue. I'm belaboring the point, but I consider a controllable "development focus" on 2.9 vs. 2.10 to be a complete red herring. Almost as silly as my opening.

All developers involved will focus on what seems important to them and their organizations. 2.9.4 and 2.10 are not mutually exclusive as far development effort. Except where trunk has moved beyond compatibility with 2.9, all work should happen there. If a defect is present and important, it will be merged to 2.9.x. A rare, one-off for a defect in 2.9.x but not trunk is just that.

If people are interested in investing in new features, upgrades, etc., that interest should be curated and, to an appropriate extent, coordinated. For example, what on "Dave's list" seems important to the community and who is ready to work on any of it? If something is disruptive, let's discuss a timeline and mitigation. If something needs particular skills or resources, let's discuss it and maybe do some matchmaking.

But this is not a dictated "development focus". That is simply not something we can command.

If what we're saying is that QA is interested in testing the next major features/release because the 2.9 bug count is low, that's fine. If we're saying that developers are interested in developing new features/upgrades, that's fine. If we're saying that institutions are finding 2.9.3 solid enough and that they are interested in paving their future with features, that's fine.

My ultimate point is that this "focus" is really only a reflection. It's good to observe, but it is not a prerequisite to any work (on any release), nor can it be "shifted" forward except by work in trunk and a clear outline of how changes fit together, leading others across the gap.

Those who are interested in 2.10 should work on it and help coordinate it by being vocal about the specific features they are working on and think should be in our next major release. Nothing more, less, or different than ever.

2.10 with all due haste; 2.9 with all due conscience.

Thanks,
-Noah



P.S., Please forgive my ranting if I misunderstand the summary and question. I read it as excessive deliberation amounting to "we think we can do work soon; just need a few more converts". If it is more along the lines of "the 14 on the call have already been working on new stuff, so the calls are going to spend more time on those items", I apologize and applaud the movement.


On Sep 5, 2013, at 12:33 PM, May, Megan Marie wrote:

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 
 
If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   
 
From: [hidden email] [mailto:sakai2-[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10
 
Hi All,
 
Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 
 
 
 
Supporting evidence
----------------------------------------
This consensus is based on :
 
* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 
 
 
* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release
 
 
Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   
 
2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).
 
 
 
If I have misstated anything, please feel free to correct me. 
 
Thanks!
Neal
 
 
Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin
 
 



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

2.10 with all due haste; 2.9 with all due conscience.

Beautiful line (the best of the bunch, with all due respect).  Poetic in its cadence and expresses well the sentiments of those who participated in the CLE Team call today.  

Anth


anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


On Sep 5, 2013, at 6:15 PM, Noah Botimer wrote:

I always use too many words. I wish I were more succinct and eloquent, but here we go...

Maybe I'm reading "we" too broadly, but I am allergic to any prospective, community-wide statements. That is, "we will" and "we are" should be much more qualified about who is or will be doing what. They should be statements of fact and commitment -- persuasion or debate about priorities should be completely separate (I suggest it is not very valuable in a broad context).

If you, and others on the calls, decide that it's time to coordinate activity around 2.10, just do it. There is no prerequisite -- not even 2.9.0 being released. The scale will tip by virtue of the scale being tipped -- others will follow if and when they are ready, but never simply because someone else is or says they should be. This is my excess deliberation bit -- just go and do. If people depending on 2.9 releases sense something wrong and need help, they will tell you and you can adjust.

To clarify my sticking point about development, I think that the focus issue is much more about where you spend your CLECC time, QA spends their time, and what bugs/features are discussed on the calls. Development is just development and it basically all happens in trunk anyway. If new features have more priority, it will feel like 2.10 is being worked on. If fixes are being made and merged for the stuff people are running now, it will feel like 2.9 is being worked on. But effectively all development is "for 2.10" -- the "development shift" happened around January, albeit without much strategy or coordination.

So, yes, it probably is just terminology. Maybe we mean coordination, QA, and mechanical release prep focus shifting to the next major release. And I do support that. With all due haste.

But you are definitely welcome to visit. :-)

Thanks,
-Noah



P.S., I think we should be talking strategically about two major releases. A way to earmark a feature/project for "not now, but definitely for next time" is long absent. Our classical "done" and "to do sometime" lists lose the value of identified priority items and the planning to mobilize them by piling them up with a bunch of stuff that isn't as important and causes endless, too-late rehash of the same list. See also, the excitement and pretty quick flatline around "Dave's list" -- not many of the items will be done for 2.10 and some of them are elephants we should start eating now, but we don't have a mechanism for talking strategically about "v.next".

P.P.S., I'll be quiet now. Development focus probably meant what you intended to everyone else. The more alignment the better.


On Sep 5, 2013, at 3:20 PM, Neal Caidin wrote:

Hi Noah,

Well, maybe it is a terminology thing, but I'm confused, because it clearly impacts my life and what I focus on, how I communicate, etc, as I'm confident you can imagine. Working with the TCC, CLE and others to set schedules, priorities, test plans, etc. So if we were to say that we are focusing on getting a 2.9.4 out by November, that would be a very different focus for me than if we focus on getting a alpha release (or whatever ) of 2.10 by November. In fact, I'm not even sure of the activities needed to get a 2.10 alpha/beta out, so that is part of what I'll be working on, understanding what is needed. I'm pretty confident of what would be needed if we try to get a 2.9.4 out.

I am probably missing your red herring argument. It's not making sense to me. It seems to me the more we are all on the same focus, the more effective we will be, and the greater the opportunity for achieving milestones and goals. I do see it as a focus and not merely a reflection. But maybe I'll have to fly up to Michigan to discuss, get some more coffee and some of those home baked cookies, just to clear things up ;-)

Cheers,
Neal




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 2:51 PM, Noah Botimer <[hidden email]> wrote:

<base href="x-msg://404/">
2.10 shall be the version thou shalt develop, and the version of the development shall be 2.10. Not.

------

I don't think there can be any reasonable "position" on this issue. I'm belaboring the point, but I consider a controllable "development focus" on 2.9 vs. 2.10 to be a complete red herring. Almost as silly as my opening.

All developers involved will focus on what seems important to them and their organizations. 2.9.4 and 2.10 are not mutually exclusive as far development effort. Except where trunk has moved beyond compatibility with 2.9, all work should happen there. If a defect is present and important, it will be merged to 2.9.x. A rare, one-off for a defect in 2.9.x but not trunk is just that.

If people are interested in investing in new features, upgrades, etc., that interest should be curated and, to an appropriate extent, coordinated. For example, what on "Dave's list" seems important to the community and who is ready to work on any of it? If something is disruptive, let's discuss a timeline and mitigation. If something needs particular skills or resources, let's discuss it and maybe do some matchmaking.

But this is not a dictated "development focus". That is simply not something we can command.

If what we're saying is that QA is interested in testing the next major features/release because the 2.9 bug count is low, that's fine. If we're saying that developers are interested in developing new features/upgrades, that's fine. If we're saying that institutions are finding 2.9.3 solid enough and that they are interested in paving their future with features, that's fine.

My ultimate point is that this "focus" is really only a reflection. It's good to observe, but it is not a prerequisite to any work (on any release), nor can it be "shifted" forward except by work in trunk and a clear outline of how changes fit together, leading others across the gap.

Those who are interested in 2.10 should work on it and help coordinate it by being vocal about the specific features they are working on and think should be in our next major release. Nothing more, less, or different than ever.

2.10 with all due haste; 2.9 with all due conscience.

Thanks,
-Noah



P.S., Please forgive my ranting if I misunderstand the summary and question. I read it as excessive deliberation amounting to "we think we can do work soon; just need a few more converts". If it is more along the lines of "the 14 on the call have already been working on new stuff, so the calls are going to spend more time on those items", I apologize and applaud the movement.


On Sep 5, 2013, at 12:33 PM, May, Megan Marie wrote:

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 
 
If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   
 
From: [hidden email] [mailto:sakai2-[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10
 
Hi All,
 
Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 
 
 
 
Supporting evidence
----------------------------------------
This consensus is based on :
 
* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 
 
 
* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release
 
 
Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   
 
2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).
 
 
 
If I have misstated anything, please feel free to correct me. 
 
Thanks!
Neal
 
 
Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin
 
 


_______________________________________________
cle-release-team mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

I have yet to learn to throw away the chaff. Someday. Glad to hear it.

Thanks,
-Noah

On Sep 5, 2013, at 7:02 PM, Anthony Whyte wrote:

2.10 with all due haste; 2.9 with all due conscience.

Beautiful line (the best of the bunch, with all due respect).  Poetic in its cadence and expresses well the sentiments of those who participated in the CLE Team call today.  

Anth


anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


On Sep 5, 2013, at 6:15 PM, Noah Botimer wrote:

I always use too many words. I wish I were more succinct and eloquent, but here we go...

Maybe I'm reading "we" too broadly, but I am allergic to any prospective, community-wide statements. That is, "we will" and "we are" should be much more qualified about who is or will be doing what. They should be statements of fact and commitment -- persuasion or debate about priorities should be completely separate (I suggest it is not very valuable in a broad context).

If you, and others on the calls, decide that it's time to coordinate activity around 2.10, just do it. There is no prerequisite -- not even 2.9.0 being released. The scale will tip by virtue of the scale being tipped -- others will follow if and when they are ready, but never simply because someone else is or says they should be. This is my excess deliberation bit -- just go and do. If people depending on 2.9 releases sense something wrong and need help, they will tell you and you can adjust.

To clarify my sticking point about development, I think that the focus issue is much more about where you spend your CLECC time, QA spends their time, and what bugs/features are discussed on the calls. Development is just development and it basically all happens in trunk anyway. If new features have more priority, it will feel like 2.10 is being worked on. If fixes are being made and merged for the stuff people are running now, it will feel like 2.9 is being worked on. But effectively all development is "for 2.10" -- the "development shift" happened around January, albeit without much strategy or coordination.

So, yes, it probably is just terminology. Maybe we mean coordination, QA, and mechanical release prep focus shifting to the next major release. And I do support that. With all due haste.

But you are definitely welcome to visit. :-)

Thanks,
-Noah



P.S., I think we should be talking strategically about two major releases. A way to earmark a feature/project for "not now, but definitely for next time" is long absent. Our classical "done" and "to do sometime" lists lose the value of identified priority items and the planning to mobilize them by piling them up with a bunch of stuff that isn't as important and causes endless, too-late rehash of the same list. See also, the excitement and pretty quick flatline around "Dave's list" -- not many of the items will be done for 2.10 and some of them are elephants we should start eating now, but we don't have a mechanism for talking strategically about "v.next".

P.P.S., I'll be quiet now. Development focus probably meant what you intended to everyone else. The more alignment the better.


On Sep 5, 2013, at 3:20 PM, Neal Caidin wrote:

Hi Noah,

Well, maybe it is a terminology thing, but I'm confused, because it clearly impacts my life and what I focus on, how I communicate, etc, as I'm confident you can imagine. Working with the TCC, CLE and others to set schedules, priorities, test plans, etc. So if we were to say that we are focusing on getting a 2.9.4 out by November, that would be a very different focus for me than if we focus on getting a alpha release (or whatever ) of 2.10 by November. In fact, I'm not even sure of the activities needed to get a 2.10 alpha/beta out, so that is part of what I'll be working on, understanding what is needed. I'm pretty confident of what would be needed if we try to get a 2.9.4 out.

I am probably missing your red herring argument. It's not making sense to me. It seems to me the more we are all on the same focus, the more effective we will be, and the greater the opportunity for achieving milestones and goals. I do see it as a focus and not merely a reflection. But maybe I'll have to fly up to Michigan to discuss, get some more coffee and some of those home baked cookies, just to clear things up ;-)

Cheers,
Neal




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 2:51 PM, Noah Botimer <[hidden email]> wrote:

<base href="x-msg://404/">
2.10 shall be the version thou shalt develop, and the version of the development shall be 2.10. Not.

------

I don't think there can be any reasonable "position" on this issue. I'm belaboring the point, but I consider a controllable "development focus" on 2.9 vs. 2.10 to be a complete red herring. Almost as silly as my opening.

All developers involved will focus on what seems important to them and their organizations. 2.9.4 and 2.10 are not mutually exclusive as far development effort. Except where trunk has moved beyond compatibility with 2.9, all work should happen there. If a defect is present and important, it will be merged to 2.9.x. A rare, one-off for a defect in 2.9.x but not trunk is just that.

If people are interested in investing in new features, upgrades, etc., that interest should be curated and, to an appropriate extent, coordinated. For example, what on "Dave's list" seems important to the community and who is ready to work on any of it? If something is disruptive, let's discuss a timeline and mitigation. If something needs particular skills or resources, let's discuss it and maybe do some matchmaking.

But this is not a dictated "development focus". That is simply not something we can command.

If what we're saying is that QA is interested in testing the next major features/release because the 2.9 bug count is low, that's fine. If we're saying that developers are interested in developing new features/upgrades, that's fine. If we're saying that institutions are finding 2.9.3 solid enough and that they are interested in paving their future with features, that's fine.

My ultimate point is that this "focus" is really only a reflection. It's good to observe, but it is not a prerequisite to any work (on any release), nor can it be "shifted" forward except by work in trunk and a clear outline of how changes fit together, leading others across the gap.

Those who are interested in 2.10 should work on it and help coordinate it by being vocal about the specific features they are working on and think should be in our next major release. Nothing more, less, or different than ever.

2.10 with all due haste; 2.9 with all due conscience.

Thanks,
-Noah



P.S., Please forgive my ranting if I misunderstand the summary and question. I read it as excessive deliberation amounting to "we think we can do work soon; just need a few more converts". If it is more along the lines of "the 14 on the call have already been working on new stuff, so the calls are going to spend more time on those items", I apologize and applaud the movement.


On Sep 5, 2013, at 12:33 PM, May, Megan Marie wrote:

I don’t think it’s possible to say if I have concerns without a timeline for 2.10.    Goals would be nice but I don’t want to press it J 
 
If it’s in the Spring 2014 I am less inclined to be concerned.   If we’re talking summer or fall, that will likely change.   
 
From: [hidden email] [mailto:sakai2-[hidden email]] On Behalf Of Neal Caidin
Sent: Thursday, September 05, 2013 11:21 AM
To: [hidden email]; [hidden email] Committee
Subject: [sakai2-tcc] Emerging consensus to focus on 2.10
 
Hi All,
 
Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 
 
 
 
Supporting evidence
----------------------------------------
This consensus is based on :
 
* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 
 
 
* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release
 
 
Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   
 
2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).
 
 
 
If I have misstated anything, please feel free to correct me. 
 
Thanks!
Neal
 
 
Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin
 
 


_______________________________________________
cle-release-team mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

In reply to this post by Neal Caidin-3
I think this could tie in nicely with the CLE 4 (or whatever version) discussion. Why don't we put a hold on getting 2.10 out the door, and take some additional time to invest in a Major (big M) release, targeted for say the end of 2014. 2.9 is in a good place, it can still have a few maint releases here and there during this timeout we can focus on really big items to get into the next Major release.

S



Sent from my iPad

On 06/09/2013, at 1:21, Neal Caidin <[hidden email]> wrote:

Hi All,

Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 



Supporting evidence
----------------------------------------
This consensus is based on :

* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 


* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release


Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   

2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).



If I have misstated anything, please feel free to correct me. 

Thanks!
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Neal Caidin-3 Neal Caidin-3
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

What specifically would you like to see in a Big M release?




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 7:19 PM, Steve Swinsburg <[hidden email]> wrote:

I think this could tie in nicely with the CLE 4 (or whatever version) discussion. Why don't we put a hold on getting 2.10 out the door, and take some additional time to invest in a Major (big M) release, targeted for say the end of 2014. 2.9 is in a good place, it can still have a few maint releases here and there during this timeout we can focus on really big items to get into the next Major release.

S



Sent from my iPad

On 06/09/2013, at 1:21, Neal Caidin <[hidden email]> wrote:

Hi All,

Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 



Supporting evidence
----------------------------------------
This consensus is based on :

* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 


* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release


Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   

2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).



If I have misstated anything, please feel free to correct me. 

Thanks!
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Jean-Francois Leveque Jean-Francois Leveque
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

In reply to this post by Neal Caidin-3
Hi Neal,

Here's what I wrote at the end of the etherpad for yesterday's meeting I
wasn't able to attend:

In order for 2.9.4 to be released, we need merges, QA and release work.
Did I forget something?

     Do we still have QA volunteers for 2.9.4?

     Do we still have 2.9.x maintenance merge volunteers?

     Do we have a release building volunteer and if we don't, how much
work is it (learning and doing)?

I need to know if we're gonna release 2.9.4 because it seems a
significant chunk of the community is using releases only and it seems
to me this is the institutions which don't have much staff assigned to
Sakai or have joined the community recently. It also seems those
institutions have a larger non-English Sakai deployment ratio that the
global community.

Because I have to care for i18n/L10n, I feel I have to care for getting
maintenance releases out. However, I'm afraid I can't do all the work.
Maybe, if others don't volunteer to help 2.9.4 out, I should try to get
mostly i18n/L10n maintenance releases out. What do you think?

Cheers,

J-F

On 05/09/2013 17:21, Neal Caidin wrote:

> Hi All,
>
> Summary
> -----------------
> There appears to be an emerging consensus to shift the development focus
> to 2.10. If you have concerns about this please speak up.
>
>
>
> Supporting evidence
> ----------------------------------------
> This consensus is based on :
>
> * The TCC discussion at Open Apereo 2013 (under future release cycles) -
> https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes
>
>
> * The email discussion thread -
> http://sakai-project-mail-list-archives.1343168.n2.nabble.com/sakai2-tcc-CLE-2-9-4-vs-CLE-2-10-effort-tt7591837.html
>
> * Today's CLE release team meeting with approximately 13-14 attending,
> for which there was consensus to focus on the 2.10 release
>
>
> Additional thoughts
> -----------------------------------
> It seems to me that there are still some open questions with 2.10, but
> nothing that would prevent us from shifting development/qa focus onto
> it. In my mind we still need to flesh out the goals for 2.10, work on a
> realistic timeline, and perhaps, most difficult of all, decide on a name
> ! :-)
>
> 2.9 will continue to be supported as the production release, of course,
> and we might want some further discussion on the best way to manage the
> 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x
> changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though
> there was not a lot of enthusiasm on today's CLE call for that
> strategy], etc.).
>
>
>
> If I have misstated anything, please feel free to correct me.
>
> Thanks!
> Neal
>
>
>
> Neal Caidin
> Sakai CLE Community Coordinator
> [hidden email] <mailto:[hidden email]>
> Skype: nealkdin
> Twitter: ncaidin
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

In reply to this post by Neal Caidin-3
Anything from the massive list of stuff we have collected, from the past two conferences TCC meetings etc.


On Fri, Sep 6, 2013 at 10:34 AM, Neal Caidin <[hidden email]> wrote:
What specifically would you like to see in a Big M release?




Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









On Sep 5, 2013, at 7:19 PM, Steve Swinsburg <[hidden email]> wrote:

I think this could tie in nicely with the CLE 4 (or whatever version) discussion. Why don't we put a hold on getting 2.10 out the door, and take some additional time to invest in a Major (big M) release, targeted for say the end of 2014. 2.9 is in a good place, it can still have a few maint releases here and there during this timeout we can focus on really big items to get into the next Major release.

S



Sent from my iPad

On 06/09/2013, at 1:21, Neal Caidin <[hidden email]> wrote:

Hi All,

Summary
-----------------
There appears to be an emerging consensus to shift the development focus to 2.10.  If you have concerns about this please speak up. 



Supporting evidence
----------------------------------------
This consensus is based on :

* The TCC discussion at Open Apereo 2013 (under future release cycles) - https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes 


* Today's CLE release team meeting with approximately 13-14 attending, for which there was consensus to focus on the 2.10 release


Additional thoughts
-----------------------------------
It seems to me that there are still some open questions with 2.10, but nothing that would prevent us from shifting development/qa focus onto it. In my mind we still need to flesh out the goals for 2.10, work on a realistic timeline, and perhaps, most difficult of all, decide on a name ! :-)   

2.9 will continue to be supported as the production release, of course, and we might want some further discussion on the best way to manage the 2.9.x branch and/or community expectations (e.g. keep track of 2.9.x changes post-2.9.3 ; possibly create a 2.9.4 tag at some point [though there was not a lot of enthusiasm on today's CLE call for that strategy], etc.).



If I have misstated anything, please feel free to correct me. 

Thanks!
Neal



Neal Caidin
Sakai CLE Community Coordinator
Skype: nealkdin
Twitter: ncaidin









_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Matthew Jones-2 Matthew Jones-2
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] Emerging consensus to focus on 2.10

In reply to this post by Jean-Francois Leveque
As far as your questions go?

On Fri, Sep 6, 2013 at 4:33 AM, Jean-Francois Leveque <[hidden email]> wrote:
In order for 2.9.4 to be released, we need merges, QA and release work.
Did I forget something?

     Do we still have QA volunteers for 2.9.4?

We have limited volunteers to do QA. In order to get trunk out, we'll need to get many issues that are resolved/unverified in trunk resolved. We'll also want regression testing. Some of this testing is applicable to the 2.9 release as if bugs are verified they can get merged back, but we may want more verification on features and fixes not getting back. So QA isn't specifically assigned, it's wherever the release team directs our attention.
 
     Do we still have 2.9.x maintenance merge volunteers?

2.9.x merges don't require much work and Longsight will continue to merge bugs into 2.9.x as we have been at least until 2.10 is released. I'm sure Michigan will be the same. The more things that get merged into the branches, the less work we have to do locally on maintaining a fork.

     Do we have a release building volunteer and if we don't, how much
work is it (learning and doing)?

I most likely still will have time, the release takes 4-6 hours depending on what goes wrong and it has to run overnight. It's well documented, but someone moderately technical will need to take over the current process as sometimes the ruby scripts break down, or sometimes Jenkins doesn't start up and you have to manually go in and fix it. The time to train someone this late in 2.9 isn't worth it when we plan to change the process for 2.10. I've went through the process before with Sam and it's not too far different from the old process that Steve and Anthony were working on. 

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

In reply to this post by Steve Swinsburg-3
OK, let me start with where we stand together -- this is a fantastic idea, and I think you are right on, except in that we should delay anything. I agree that the numbers don't matter much, but...


I'm sorry, but I feel that a BIGGER AND BETTER single release is precisely the wrong approach. Doubling down to put more stuff in a release is a major problem, resulting in less frequent releases, later and less QA coverage, and slower adoption.

We have suffered this for major and maintenance releases for years. They build inertia and get harder and harder to release and harder to adopt when we get there. It even delays and kills ambitious projects waiting for a time when they can be disruptive.

I do think a big-M release is a good idea, but it seems rather separate from the 2.10 schedule. There is already stuff in trunk that should be released. If there is other great stuff ready by a reasonable time to release the incrementals, that'd be wonderful. I'm just saying that being ambitious and releasing valuable, less ambitious stuff are not mutually exclusive.

I stand by it that I think a "same as expected" 2.10 release that tightens up 2.9 and a "whoa, that's awesome" 4.0 release is the winning strategy.

I think Apple has done this well since Leopard and it bears out that adopters are divided by their contentment with something familiar and solid versus picking up something that is different and has more features. If we did what I suggest, I think we would find a lot of 2.10 and 4.0 adopters, spread out pretty naturally.

I also stand by it that 4.0 should be bold and move to Github/Bitbucket and Gradle with a reduced core size (an easier build/install process making contrib a fine place to live) -- note that both can happen readily in parallel to preparing a 2.10 release.

I think we are very close together in direction -- just my same old drumbeat of "work on a pragmatic, imminent release and an ambitious, future release simultaneously".

Thanks,
-Noah



P.S., I'm on 10.6.8 now and I think it'd be fine if someone ran 2.10 for three years. When I get new hardware or there is something I can't resist, I'll jump to the front. I think institutions run the same calculation when there is a big feature or technical bridge to cross for an upgrade. It's natural and we should embrace it.

On Sep 6, 2013, at 7:09 AM, Steve Swinsburg wrote:

Anything from the massive list of stuff we have collected, from the past two conferences TCC meetings etc.

On Fri, Sep 6, 2013 at 10:34 AM, Neal Caidin <[hidden email]> wrote:
What specifically would you like to see in a Big M release?

On Sep 5, 2013, at 7:19 PM, Steve Swinsburg <[hidden email]> wrote:

I think this could tie in nicely with the CLE 4 (or whatever version) discussion. Why don't we put a hold on getting 2.10 out the door, and take some additional time to invest in a Major (big M) release, targeted for say the end of 2014. 2.9 is in a good place, it can still have a few maint releases here and there during this timeout we can focus on really big items to get into the next Major release.


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Kirschner, Beth Kirschner, Beth
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth

On Sep 6, 2013, at 6:18 PM, Noah Botimer <[hidden email]> wrote:

> OK, let me start with where we stand together -- this is a fantastic idea, and I think you are right on, except in that we should delay anything. I agree that the numbers don't matter much, but...
>
>
> I'm sorry, but I feel that a BIGGER AND BETTER single release is precisely the wrong approach. Doubling down to put more stuff in a release is a major problem, resulting in less frequent releases, later and less QA coverage, and slower adoption.
>
> We have suffered this for major and maintenance releases for years. They build inertia and get harder and harder to release and harder to adopt when we get there. It even delays and kills ambitious projects waiting for a time when they can be disruptive.
>
> I do think a big-M release is a good idea, but it seems rather separate from the 2.10 schedule. There is already stuff in trunk that should be released. If there is other great stuff ready by a reasonable time to release the incrementals, that'd be wonderful. I'm just saying that being ambitious and releasing valuable, less ambitious stuff are not mutually exclusive.
>
> I stand by it that I think a "same as expected" 2.10 release that tightens up 2.9 and a "whoa, that's awesome" 4.0 release is the winning strategy.
>
> I think Apple has done this well since Leopard and it bears out that adopters are divided by their contentment with something familiar and solid versus picking up something that is different and has more features. If we did what I suggest, I think we would find a lot of 2.10 and 4.0 adopters, spread out pretty naturally.
>
> I also stand by it that 4.0 should be bold and move to Github/Bitbucket and Gradle with a reduced core size (an easier build/install process making contrib a fine place to live) -- note that both can happen readily in parallel to preparing a 2.10 release.
>
> I think we are very close together in direction -- just my same old drumbeat of "work on a pragmatic, imminent release and an ambitious, future release simultaneously".
>
> Thanks,
> -Noah
>
>
>
> P.S., I'm on 10.6.8 now and I think it'd be fine if someone ran 2.10 for three years. When I get new hardware or there is something I can't resist, I'll jump to the front. I think institutions run the same calculation when there is a big feature or technical bridge to cross for an upgrade. It's natural and we should embrace it.
>
> On Sep 6, 2013, at 7:09 AM, Steve Swinsburg wrote:
>
>> Anything from the massive list of stuff we have collected, from the past two conferences TCC meetings etc.
>>
>> On Fri, Sep 6, 2013 at 10:34 AM, Neal Caidin <[hidden email]> wrote:
>> What specifically would you like to see in a Big M release?
>>
>> On Sep 5, 2013, at 7:19 PM, Steve Swinsburg <[hidden email]> wrote:
>>
>>> I think this could tie in nicely with the CLE 4 (or whatever version) discussion. Why don't we put a hold on getting 2.10 out the door, and take some additional time to invest in a Major (big M) release, targeted for say the end of 2014. 2.9 is in a good place, it can still have a few maint releases here and there during this timeout we can focus on really big items to get into the next Major release.
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

I think that Noah is wrong and disagree with Beth below.

We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.

To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.

I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  

Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".

If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:


This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.

We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.

It time to move on.

/Chuck

On Sep 9, 2013, at 8:32 AM, Beth Kirschner <[hidden email]> wrote:

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
markjnorton markjnorton
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

As strange as it is for me to agree with anything Chuck says, I agree with him.  It's time to reboot Sakai and take a stab at some of those really big issues.  Technology marches on and it's easy to be left behind. 

Jira is full of good suggestions, so there is no lack of things to tackle.  Still, I'd like to see some architectural review done.  Perhaps we should build support for TinCan into the kernel.  We might consider support for a database that isn't owned by Oracle.  Sakai runs okay in a cloud environment, but what could we do to make it SCREAM there?  There are issues that came up in Sakai 0.5 that have NEVER been addressed (like full back button support, for example).  We should move up to Java 7, too.

Yeah, it's a time to consider incremental improvements, too, but let's think big.  Let's think about what it will take to put Sakai back on the CIO radar and bring back the buzz of the early days.

- Mark Norton

On 9/9/2013 9:50 AM, Charles Severance wrote:
I think that Noah is wrong and disagree with Beth below.

We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.

To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.

I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  

Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".

If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:


This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.

We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.

It time to move on.

/Chuck

On Sep 9, 2013, at 8:32 AM, Beth Kirschner <[hidden email]> wrote:

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

In reply to this post by Dr. Chuck
My only rebuttal -- I agree that we are ready for 4.0; just not that we should hold the things currently in trunk for even-later QA. It *is* time to move on.

I don't really care about the numbers -- except that we might take advantage of a numbering change to indicate a practice change (see also Firefox [1]). There are certainly practices to change.

Flush the buffer, get the release out, and start with a couple of new rules. I suggest starting with one: no feature changes or major bugfixes without a consolidated changelog entry -- a JIRA number does not count; one minute of summary time saves hours of backtrack later (across 70 modules). This is very major QA and release drain.

Thanks,
-Noah


[1] https://blog.lizardwrangler.com/2011/08/25/rapid-release-process/ -- no, we don't need to release every 6 weeks, but they cued a cultural change with the versioning change.

On Sep 9, 2013, at 9:50 AM, Charles Severance wrote:

I think that Noah is wrong and disagree with Beth below.

We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.

To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.

I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  

Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".

If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:


This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.

We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.

It time to move on.

/Chuck

On Sep 9, 2013, at 8:32 AM, Beth Kirschner <[hidden email]> wrote:

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Aaron Zeckoski-3 Aaron Zeckoski-3
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

In reply to this post by markjnorton
On Mon, Sep 9, 2013 at 10:03 AM, Mark J. Norton
<[hidden email]> wrote:
> Still, I'd like to see some architectural review done.  Perhaps we should
> build support for TinCan into the kernel.  We might consider support for a

Good idea, already done in trunk.
https://jira.sakaiproject.org/browse/KNL-1042


> button support, for example).  We should move up to Java 7, too.

Same as above... but in 2.9.
https://jira.sakaiproject.org/browse/SAK-20908

-AZ

--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Bryan Holladay Bryan Holladay
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

In reply to this post by markjnorton
Please no more 2.x minor releases!  2.10 is confusing in general, plus, as Chuck said, 2.9 itself doesn't even look anything like 2.0 and shouldn't have been considered a maintenance release in its own.  4.0 doesn't just have to be a feature improvement release (which there are plenty of new features).  It's also showing how the Sakai community is changing and how we handle our releases.  We need to get rid of the 2nd decimal point in the releases and move to just single: 4.0, 4.1, 4.2, 5.0, 5.1, 5.2; otherwise, we'll get stuck in release 4.x like we did in 2.x.  I'd like to quote someone on this:

"We are struggling with going from 2.x to 4.x because we have to argue that the next release will be breakthrough enough to merit such a major version change.  If we keep the same 3 digit versioning system, we'll run into this same rut for the next version we jump to.  If we move to the 2 digit version (4.1, 4.2, 5.0, ...) then we won't have to feel like there must be an earth shattering change that merits a major release version update.  This would better represent Sakai's true development cycle of incremental changes that, when added together, equals a large step forward, as opposed to giants leaps following by minor changes, which our current versioning suggests."  -Bryan Holladay


On Mon, Sep 9, 2013 at 10:03 AM, Mark J. Norton <[hidden email]> wrote:
As strange as it is for me to agree with anything Chuck says, I agree with him.  It's time to reboot Sakai and take a stab at some of those really big issues.  Technology marches on and it's easy to be left behind. 

Jira is full of good suggestions, so there is no lack of things to tackle.  Still, I'd like to see some architectural review done.  Perhaps we should build support for TinCan into the kernel.  We might consider support for a database that isn't owned by Oracle.  Sakai runs okay in a cloud environment, but what could we do to make it SCREAM there?  There are issues that came up in Sakai 0.5 that have NEVER been addressed (like full back button support, for example).  We should move up to Java 7, too.

Yeah, it's a time to consider incremental improvements, too, but let's think big.  Let's think about what it will take to put Sakai back on the CIO radar and bring back the buzz of the early days.

- Mark Norton


On 9/9/2013 9:50 AM, Charles Severance wrote:
I think that Noah is wrong and disagree with Beth below.

We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.

To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.

I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  

Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".

If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:


This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.

We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.

It time to move on.

/Chuck

On Sep 9, 2013, at 8:32 AM, Beth Kirschner <[hidden email]> wrote:

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

BTW, I like 4, 5 just as well as 2.10, 4. Cue the culture shift!

Thanks,
-Noah


P.S., Start yesterday; failing that, today.

On Sep 9, 2013, at 10:12 AM, Bryan Holladay wrote:

Please no more 2.x minor releases!  2.10 is confusing in general, plus, as Chuck said, 2.9 itself doesn't even look anything like 2.0 and shouldn't have been considered a maintenance release in its own.  4.0 doesn't just have to be a feature improvement release (which there are plenty of new features).  It's also showing how the Sakai community is changing and how we handle our releases.  We need to get rid of the 2nd decimal point in the releases and move to just single: 4.0, 4.1, 4.2, 5.0, 5.1, 5.2; otherwise, we'll get stuck in release 4.x like we did in 2.x.  I'd like to quote someone on this:

"We are struggling with going from 2.x to 4.x because we have to argue that the next release will be breakthrough enough to merit such a major version change.  If we keep the same 3 digit versioning system, we'll run into this same rut for the next version we jump to.  If we move to the 2 digit version (4.1, 4.2, 5.0, ...) then we won't have to feel like there must be an earth shattering change that merits a major release version update.  This would better represent Sakai's true development cycle of incremental changes that, when added together, equals a large step forward, as opposed to giants leaps following by minor changes, which our current versioning suggests."  -Bryan Holladay


On Mon, Sep 9, 2013 at 10:03 AM, Mark J. Norton <[hidden email]> wrote:
As strange as it is for me to agree with anything Chuck says, I agree with him.  It's time to reboot Sakai and take a stab at some of those really big issues.  Technology marches on and it's easy to be left behind. 

Jira is full of good suggestions, so there is no lack of things to tackle.  Still, I'd like to see some architectural review done.  Perhaps we should build support for TinCan into the kernel.  We might consider support for a database that isn't owned by Oracle.  Sakai runs okay in a cloud environment, but what could we do to make it SCREAM there?  There are issues that came up in Sakai 0.5 that have NEVER been addressed (like full back button support, for example).  We should move up to Java 7, too.

Yeah, it's a time to consider incremental improvements, too, but let's think big.  Let's think about what it will take to put Sakai back on the CIO radar and bring back the buzz of the early days.

- Mark Norton


On 9/9/2013 9:50 AM, Charles Severance wrote:
I think that Noah is wrong and disagree with Beth below.

We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.

To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.

I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  

Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".

If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:


This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.

We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.

It time to move on.

/Chuck

On Sep 9, 2013, at 8:32 AM, Beth Kirschner <[hidden email]> wrote:

It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.

- Beth



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
12