Notes from afternoon discussion, part I of Maintenance and Minor Release discussion
Branch management tracking
Patching is for a bug, not a feature
info required on testing already achieved and where it is running
...
Maintenance Release:
Propose to community that some technical governance group QA+Branch Mgmt will review
No decision yet on functional releases (minor releases).
Talking about minor risk is in part documenting what we are already doing.
New topics: technical governance of functional
decoupling general tool releases from functional additions
Notes from afternoon discussion, part II of Maintenance and Minor Release discussion
...
and Provisional/Contrib/Core
The group began discussion about minor releases (2.6 2.7, ect) by considering whether it is a good idea to introduce new features and how to do this in a more rapid succession.
Concerns that motivated this idea are
- Features are all introduced at the same time. When we decide to release, there's a large scope for QA which takes a lot of resources
- Long wait times to introduce user requested features.
- Taking on the burden of more local maintenance
Jason framed some thoughts with question about 2 major stakeholders-
Q: Do existing deployers care about new features? Jason isn't sure
Q: Do adopters care about new features? Jason believes yes.
Essentially, we are trying to discover how we get back to the benefits of the 6 month release cycle without a 6 month cycle?
Seth pointed out that we might be biting off more than we can chew. Not only will we have 2.5 maintenance releases, but we'll also have folks in the 2.6 vein that will also start clammoring for maintenance releases. This lead into discussion of the ability of projects to manage there own releases. Some projects (ie Samig) are successfully doing this; however most are not. Someone poised the question "is QA the responsibility of the project teams?" There was speculation about whether teams would follow though on this. Megan pointed out that minor releases were an opportunity to enforce the requirement for unit/integration tests.
Problem with current QA process. Testing is getting harder and harder with more and more coming into the release. Further, we are not effectively communicating out what changes are occurring. For example, Davis was surprised at the work in the 2. gradebook
----
Core - Provisional - Contrib
The core-provisional-contrib model does not accurately convey the meaning of quality in Sakai.
- Tool Score Cards: quality review of components.
- There are tools outside of core that meet quality standards. We do have a basis for the Contrib to Provisional status and a draft for Provisional to core.
This isn't to determine what goes into the release this is about documenting the status of the
Who's going to execute it and how do we go about doing it?
This can be done a couple ways
1) Project teams - self reporting
2) 3rd Party - pick someone that you trust
3) Have someway of empirically proving it
From a security perspective - Anthony wants to ensure the XSS doesn't occur.
Let's assume we have criteria and methods to get community rating. Now what? What goes into the release?
- Right now you can get something into trunk and abandon it. Quality assessment should be up to date and meet certain standards. If not there
1) In the release or out of the release
2) licensing -
Talk about different types of packaging of the product.
- Sakai Core: tools very well tested
- Sakai Evaluation: tools that come from trunk or contrib and that have clean licensing.
Thought experiment
Oliver suggested we take a look at Section Info. UCB did the development on the tool and is largely focused on other work at this time. What would happen with that tool? Would it be dropped?
Stephen Marquard - discussed in great deal that we have to take a hard line on tools that are not up to snuff. First analysis of the current state needs to be performed and the community determines a baseline.
Who defines Sakai as a project? Jess noted that we were discussing Sakai in terms of two attribute
- accountability
- value judgment
Discussion of inter dependencies between modules. It's very hard to decouple some of theses tools. Perhaps we should be working toward modularity and flexibility so that there are more opportunities. For example, we can't build Sakai without sections, assignments and gradebook!
As to determining what is in the release
- People around the block doesn't need release, they need the a fore mentioned rating.
- People that need to evaluate Sakai are the ones that really need the release.
Q: Who handles choosing what is in the 'Evaluation' release? Michael proposed the Foundation does by performing market analysis/ competitive analysis. The group was in agreement about the to the idea of distribution of Sakai evaluation to the Foundation that was not a criteria base decision.
Q: Can we drop stuff from the evaluation release? Yes - is like a showcase.
Thumbs up to scraping the Core-Provisional Contrib!
Proposal
- Establishing a WG to define a set of criteria (ie score card). This WG will work from the existing set of provisional criteria.
- 2-3 months before the release of 2.6 folks need to fill out the scores card.