Plans for documentation and positioning of the development release

Registered by Colin Watson on 2013-05-08

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

Related branches

Sprints

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.ubuntu.com

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

This blueprint contains Public information 
Everyone can see this information.