@mariogrip said in semantic versioning for UT:

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

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 rc to 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.

@diogo said in Gettogether in Brussels:

Thursday the 20th of September, on the Brewdog

I plan to be there.

Why "5 minute" tasks?

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:

Five minute tasks (TODO)

1. Add items to "5 minute tasks" list

Five minute tasks (DONE)

1. Create a "5 minute tasks" 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:

1. Would the non-profit foundation be in a position to enter into a contract with them? On what basis?
2. How would we approach staffing this project?
   2.1. Employing a team people? (Presumably from the community?)
   2.2. Or contracting pieces of work out? (Including management of that?)

Hi @Andreas-Pokorny, I know you've made some progress updating the hybris/android platform. Could you post an update?

@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

@doniks said in Proposal: The Edge channel:

Did I miss anything?

Not really. I raise two typical developer questions:

1. is there a good reason for supporting this channel?
2. is one extra channel really sufficient?

(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?

• devel/libhybris
• devel/Mir
• devel/Unity8
• devel/caf
• devel/halium

(From the sidelines as I'm content to run stable and await released versions.)

@Diogo coincidentally Canonical is getting some developers together in Brussels in September. That means I (and the Mir team) will be around September 17-21 does that week work for you?