|
Session Title:
*Conveners: Robert J. Berger & Sean P. Kane
Participants:
Summary of discussions:
Notes from R. berger (Not complete, please add any you have)
The process of sharing and using is problematic
More generic way to use lwrp for tweaking cookbooks ala apache configs
- Group/ mailing list per cookbook
- Domain area collaboration to create and update related cookbooks
- Feedback in a way that can also go to all the people involved
- Track view source code from github bitbucket etc
- Cookbook maturity and other code and history
- Wish list tie into roadmap
- Get better way to download
- Librarian can be the backbone of a new workflow
- Share cookbook development environments along with cookbooks via Vagrant (Ex. freight-cooking)
- Network diagram lineage
- Tighter integration with Jira
- Oficially supported cookbooks (by anyone)
- Allow way to tell maintainer of a correction
- Use tickets to track who is working on what new or old cookbook
- irc logs searchable mineable
- Virtual hack days to improve a cookbook at a time
- Better "human-readable" version scheme that allows local version changes that do not conflict with the upstream providers versioning.
- I.E. Let providers use the first 3 values of a 4 value version number "i.e. 1.3.2.0" and allow end-users to increment the 4th number as much as needed to track there own internal changes, that are not re-shared upstream.
What will we do now? What needs to happen next?
|
|