bileto-announce team mailing list archive

[Robert Park <robert.park@xxxxxxxxxxxxx>]

On Wed, Aug 31, 2016 at 11:46 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> Thanks Robert for this! That was indeed one of the annoying things and
> it's great to see that it's gone!

You're welcome! Happy to see people appreciate my work!


> My second biggest issue (if you are accepting feature requests :-) ) is
> this one: sometimes builds stop working because of tests starting to
> fail (for instance, it happened with the new Qt 5.6 for a couple of
> packages of mine), or sometimes tests were always flaky and we suddenly
> decided to fix them for good.
>
> In other words, it happens quite often to me to propose merges which
> affects tests only (no code changes to any installed files), and getting
> these changes in is IMHO unnecessarily hard.
>
> Would it be possible for landers to set a flag on a silo, meaning "this
> brings no changes to the resulting packages" which lets us bypass any QA
> (both human and automatic, as Britney can also takes some several days
> to complete)?
>
> Of course, this involves some trust, but it's also easy to find cases
> where this flag was abused and we should be able to correct the
> misbehaviour.
>
> WDYT?

So, Bileto is a tool for making releases into Ubuntu. If your change
doesn't affect the end product in any user-visible way, why are you
even using bileto for that? If you are completely, 100% positive that
you're just doing "test fixes" and they don't require QA and they
won't have any impact whatsoever on users, why not just commit those
directly to trunk? They will then be released next time you have
"meaty" changes to make that do require QA.

I'm generally not convinced it would be a good idea to add to bileto a
giant user-settable flag that says "hey just ignore this silo and skip
all the QA".

Another thing to consider is that nothing blocks on britney failures,
those are just advisory. So really you could make a ticket and build
it and ask QA "hey can you just skip this, it's trivial", and then
publish without QA or britney. But generally if your fixes are so
trivial I'd like to see those just committed directly to your trunk
and then released later once you have enough fixes collected to make a
release worthwhile.

-- 
robru