Yocto 1.3 Features: Difference between revisions
No edit summary |
|||
Line 174: | Line 174: | ||
|milestone=1.3 | |milestone=1.3 | ||
|severity=enhancement | |severity=enhancement | ||
}} | |||
{{#bugzilla: | |||
|columns=id,from,summary,milestone,whiteboard,to,status,url | |||
|status=NEW,ACCEPTED,REOPENED,NEEDINFO,WaitForUpstream | |||
|milestone=1.3 | |||
|severity=normal | |||
}} | }} |
Revision as of 22:37, 30 April 2012
Potential Yocto Project 1.3 Features
Yocto Project 1.3 - Target release = Oct. 2012
Yocto Project 1.3 Themes
The Yocto Project 1.3 Themes include:
Continuity / Refresh
The usual keeping up to date with various upstream project, continue to work on the quality of the metadata and keeping up to date with bug fixing.
Stabilization & Adoption
We've introduced a lot of changes. I think now may be a good time to catch our breath so to speak and ensure everything is complete, functional, well tested and has the right level of polish.
We also need to encourage adoption of the project by OSV and Silicon Vendors and look at ways we can advance and integrate Shoeleather-type board labs (from semis and OSVs).
Usability
Introduce WebHob? Continue improving error messages Reserve time to jump on usability issues as they come up
Process for Entering New Feature Requests
- Open a bug in the Yocto bugzilla setting the type of bug to be an "enhancement" request. The detail about the request should be included in the bugzilla report.
- Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
- Suggestion: start by copying an existing request as a template
- Give the feature a short, descriptive name
- Set the priority as appropriate (see the legend below)
- Set the Status to "Review"
- In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
- In the Comments / Bugzilla field, provide any additional information for the request includind a link to a bugzilla entry
- Preview your Entry to make sure it looks ok and then save it
Legend
Priority: 1 = Must have, 2 = Nice to have but wouldn't block a release, 3 = Lower priority, desired, defined plan, 4 = Worthwhile ideas, no defined plan
Status: Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
Sample Table
This is a sample table to show how to submit features.
Feature Name | Priority | Status | Source | Comments / Bugzilla Links |
Placeholder feature name | 1, 2, 3 or 4 | Review | Name | Comment + Link |
Core/Bitbake
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
Core Meta Data
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
Other Layer Meta Data
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
Infrastructure
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
Kernel
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
BSPs
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
ADT / Tools and Support
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
QA Items
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |
Documentation
Feature Name | Description | Priority | Status | Source | Owner | Due | Comments / Bugzilla Links |