Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.6
I think this is confusing. I prefer the Debian scheme where 1.5.6~rc1 -> 1.5.6
A software developer who has delivered many successful projects.
His current challenge (sponsored by Canonical): Mir.
In the ideal, Agile, world software should always be in a releasable state and the timing of releases should be determined by user readiness and the cost of releasing (not dates or feature completion).
The costs of releasing here are administrative time and bandwidth. Correct me if I'm wrong, but I don't think either is a reason to block "release faster".
I think I can speak for all the users here and say: we are always ready to receive the latest working version.
The difference between this ideal world is that we can't be sure that things are in a releasable state just because the automated tests pass. Not all the projects that make up UT have adequate automated tests to guarantee their correctness and we don't have test coverage that everything works together on every device.
So, I'm all for "release fast" and trying to mitigate any issues that throws up...
Having a couple of days to identify critical issues on
devel before moving to
rc sounds sensible to me.
The criteria for moving from
stable needs to be clearer or stricter. I suggest that any new issues on
rc (i.e. ones that don't also exist on stable) should default to
critical-rc unless there is an explicit group decision otherwise.
Also, I think we have enthusiasts around that will happily try
rc. Maybe there could be a place where they can sign off that they have "used it for 24 hours on XXX device" to feed into the release-to-stable decision? Delaying a day (or two) for better empirical testing shouldn't affect the cadence too much.
On telegram @wayneoutthere asked for people to contribute 5 minutes a day to help progress the project.
I don't think I'm alone in not knowing what to spend 5 minutes on, so I created a list:
This is purely hypothetical, but the scenario is likely of interest to many of us.
Suppose a company approached UBports about getting commercial support for their device:
@nikalon you have to "trick" Unity8 into allowing the application to connect. I have not tried it recently, but something like this... https://lists.ubuntu.com/archives/mir-devel/2015-September/001267.html
Did I miss anything?
Not really. I raise two typical developer questions:
(There are three numbers in computing 0, 1 and many.)
This sounds odd, because what you're proposing for
edge is what
devel has been described as (and is for a lot of projects). It would be reasonable to take the attitude people running
devel were warned, and chose to accept the risk that
devel is not guaranteed to be stable.
To create a new channel because you worry that some people expect something without good reason seems excessive.
However, convenience for developers is another story. Having an easy way to install experimental versions is important. Does a single channel cover this need? Would it be better to have the facility for multiple sub-channels?
(From the sidelines as I'm content to run
stable and await released versions.)
Looks like your connection to UBports Forum was lost, please wait while we try to reconnect.