MRE for juju-core/juju-mongodb

James Page james.page at ubuntu.com
Mon Apr 14 11:44:39 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Martin

On 09/04/14 17:58, Martin Pitt wrote:
> James Page [2014-04-07 17:05 +0100]:
>> When we discussed this a vUDS many moons ago I think the
>> rationale for this was if we hit a critical or security bug which
>> could not be backported to the stable release on MongoDB, based
>> on complexity and associated risk, rather than generally as and
>> when.
>> 
>> I guess we would deal with that as an exceptional SRU rather
>> than requiring a blanket 'you can do major release upgrades' from
>> the TB. It would require deeper testing than a regular point
>> release anyway.
>> 
>> Does that sound like a more sensible approach?
> 
> Yes, it does from my POV. Before we grant blanket MREs we usually 
> require some good record of successful MREs in actual SRUs; as the 
> go-ified juju is still rather new and hasn't really seen SRUs, I
> think it's too early to talk about MREs.
> 
> Ordinarily I trust the SRU team to decide whether a new
> microrelease with a couple of bug fixes fits the normal SRU
> criteria; if there is a case where there are tons of changes, or
> new features, I'd rather bring this up again as a concrete case.

Are you suggesting that we should push some micro releases for
juju-core and juju-mongodb through the SRU process and then review if
a formal MRE is required?  For example:

https://bugs.launchpad.net/ubuntu/saucy/+source/juju-core/+bug/1277526

is being worked on - in your opinion, do the fixes being included meet
the requirements for a normal SRU?

- -- 
James Page
Ubuntu and Debian Developer
james.page at ubuntu.com
jamespage at debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTS8onAAoJEL/srsug59jDe/MQAIRYO3GRrGZE2Hk512uJFaa4
qL0wXbvMICV0ZFcFpqwO4JDuhgkXHycX5YgrOS9P+E1zsUEDIethlk8AfKBhKw5T
7JW8XYaATbybgRhLF5W/YYlsGB2vQPZPUErULbFOw2BMAiobsw1mYZvqtg86A70E
V29GvwaegNKFvWwAlGjpp5HHKMsSlqRUHW4yaWGUxiU9X6tsxYh6izohwUsSTmFI
uYxj2CaRKPGRSnBbC374HNsH/LBy49CPd4DNU5QkIBvcsucxx508ROZNhZXUAfA9
oI1BjvOal8MbZ/nv9g4ZhFdZJkeIk/NCEQckgV/Ge3RNV1IulfYAt7aF4PlnoP3p
IJrGvQdaZe39559kec8JbDpYlPKyvWQPGuLVMbRmphkUEJHeh8J984xNr93Q7cta
zvYLjprMb47umnW7wQTCMdpGdDwRtOhYW2weRLrsdW8Ph1XvM4oyZmWcubf2cCfs
Cz8IstcCdz/vO9QA3tByBTi9tWX2EbqlOrbvQpWKnTQXWaZCHUOfUFif+7agrOhF
HFs3h2gcfdTJic/GLjKFmkduNNFFtXy3pDylkCtNJWDvtiN+qOXobe1VDduSWoLi
wChgKWDoa8LnuZYXodOuP6DXDshX0VQA2bGH8UT0esPul1omBzOcS4yo+Bhzjt6y
n2fsutunKREMNTK/cPyi
=zwbd
-----END PGP SIGNATURE-----



More information about the technical-board mailing list