Plans for documentation and positioning of the development release
Although the "rolling release" discussions from last cycle didn't actually result in a plan to institute a rolling release, they did leave several questions outstanding. As well as implementing an easy way to perpetually stay on the development release (by way of a symlink or similar), it would be helpful to discuss such things as how/where to document running the development release, who it's for, how to market it, and so on.
Blueprint information
- Status:
- Not started
- Approver:
- Steve Langasek
- Priority:
- Undefined
- Drafter:
- Colin Watson
- Direction:
- Needs approval
- Assignee:
- Colin Watson
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
This is expected to be fairly easy technically. The messaging is important.
Things we could do to encourage folks to track dev releases (outside of improving quality and providing a devel suite symlink):
* software-properties option to always stick to development release (make sure that switching back works!); only show this on people already on the devel release though
* website messaging?
* uploader support for uploading to current
Might have to fix various pieces to be able to install from this symlink
Would uploads be directed at the devel symlink? Not sure whether this is contentious or not; probably minor
Some developers are concerned by the number of releases they have to target; one of the reasons is that the uploader is kept open as to support commercial projects/PPAs
market to app developers: developer.
Implementation:
Arrange for there to be a symlink from something like 'devel' 'current' or similar to the current development release. This would be made via a small patch to launchpad. We would want to be able to install from this as well.
For developing on 'devel' releases, all the build artifacts would need to know about it: sbuild, schroot, chdist, etc.
Also what about d/changelogs? Would they name the current release or 'devel'? If the latter, it would be more difficult to know when the package was uploaded for. == was covered above ("uploads directed at the devel symlink"); need to decide whether we want that on e.g. ubuntu-devel@ or such
It is unclear when 'current' should move from raring to saucy in the cycle. We nominally say that the release is not ready for use until we have uploaded the rcompilers etc at the beginning of the cycle, ie. till when it comes out of pre-release-freeze at the beginning. We might want to hold the move until that kind of level of readiness before we move it over.
Some discussion on making sure the name helps to reinforce the SLA we are driving at. xorg-edgers put up as a good example. We must avoid any name from debian (which kills testing and unstable).
Would want to allow reverting back to the current devel release and stick to it; probably in software properties too
* name less English idiomatic than "edgers", stable or testing
* current, development, latest, tip, head, master
* names that are out because other distros testing/unstable, rawhide, factory, freebsd
Candidate names:
* development
* current
* tip
* latest
* head
* master
* devel
* trunk
* rolling
* bikeshed :)
* next
* nonameyet
Excluded:
* sid, testing, unstable or other Debian names
* rawhide
* factory
[rick-rickspencer3] I took the action to choose a name for the sym link and follow up with the techboard about the whole proposal. I am open to input, but I am going to go with "rolling" unless someone has a better idea.
Work Items
Work items:
[rick-rickspencer3] pick a name for the release and bring to TB: TODO
[rick-rickspencer3] follow up with the community team on this: DONE
[cjwatson] chase someone to implement software-properties changes: TODO
[cjwatson] talk to Kubuntu guys about equivalent Qt version: TODO
