So an interesting thought experiment. What if we made all changes on a
stable series require an associated bug to be able to land the code there.
At least as I understand "blocker" bugs on a given series, it just requires
that the code proposed for landing be associated with one of the current
list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-07-13 07:43 PM, Ian Booth wrote:
> By the definition given
>
> "If a bug must be fixed for the next minor release, it is
> considered a ‘blocker’ and will prevent all landing on that
> branch."
>
> that bug and any other that we say we must i
I think everyone's agreeing here, but maybe the wording just needs to be
clarified somewhere to avoid confusion.
It sounds like "bugs which are assigned to a release do not block commits
unless they are marked blockers". And blockers are determined by "we
wouldn't want *anyone* to upgrade to a v
On 14 July 2015 at 10:02, Nate Finch wrote:
> I don't
> think it's unreasonable to just make such a bug a blocker, just to get it
> addressed ASAP, even if it is not strictly making things worse than an
> earlier version.
FWIW I think that this is overkill. When a bug is a blocker,
all other work
On 14/07/15 23:26, Aaron Bentley wrote:
> On 2015-07-13 07:43 PM, Ian Booth wrote:
>> By the definition given
>
>> "If a bug must be fixed for the next minor release, it is
>> considered a ‘blocker’ and will prevent all landing on that
>> branch."
>
>> that bug and any other that we say we must
[as roger.pe...@canonical.com this time]
On 14 July 2015 at 10:02, Nate Finch wrote:
> I don't
> think it's unreasonable to just make such a bug a blocker, just to get it
> addressed ASAP, even if it is not strictly making things worse than an
> earlier version.
FWIW I think that this is overkil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-07-14 10:02 AM, Nate Finch wrote:
> I agree that if a blocker is found in an earlier minor version,
> that upgrading to a new minor version with the same blocker doesn't
> make anyone any worse off.
I think of this argument as "No use closing
On 14 July 2015 at 15:31, Ian Booth wrote:
>
>
> On 14/07/15 23:26, Aaron Bentley wrote:
>> On 2015-07-13 07:43 PM, Ian Booth wrote:
>>> By the definition given
>>
>>> "If a bug must be fixed for the next minor release, it is
>>> considered a ‘blocker’ and will prevent all landing on that
>>> bran
Hello everybody,
Lately I've been noticing a couple of failures regarding a new testing feature
introduced on windows.
Without going into implementation details too deep the main idea is that
whenever a new suite is created
that inherits from a base suite and a SetUpX function is defined, it ne
Recent commits to master do not pass go vet checks
checking: go vet ...
utils/syslog/config_test.go:159: unrecognized printf flag for verb 's': '#'
Didn't we switch on an option to gate landings to master on go vet?
Don't developers use git pre-commit checks to ensure they don't push bad code i
Could it be related to different go versions? Are we now officially on 1.4?
Sincerely Yours,
Anastasia
On 15/07/15 13:51, Ian Booth wrote:
> Recent commits to master do not pass go vet checks
>
> checking: go vet ...
> utils/syslog/config_test.go:159: unrecognized printf flag for verb 's': '#'
>
11 matches
Mail list logo
