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
Candidate names:
* development
* current
* tip
* latest
* head
* master
* devel
* trunk
* rolling
* bikeshed
* next
* nonameyet
Excluded:
* sid, testing, unstable or other Debian names
* rawhide
* factory
Work Items:
[rick-rickspencer3] pick a name for the release and bring to TB
[rick-rickspencer3] follow up with the community team on this
[cjwatson] chase someone to implement software-properties changes
[cjwatson] talk to Kubuntu guys about equivalent Qt version