ubuntu-phone team mailing list archive

[Łukasz 'sil2100' Zemczak <lukasz.zemczak@xxxxxxxxxxxxx>]

Hi Colin!

Thanks for going forward and starting this discussion.

On 15.07.2014 18:54, Colin Watson wrote:
> For the plan to deliver the phone RTM from a derived "ubuntu-rtm"
> distribution, we'll need to use a different set of silo PPAs, since PPAs
> are attached to a particular distribution (which is clearer now that the
> PPA URL format has been changed to include the distribution name).
> Although there are a few remaining bits, Launchpad has mostly now been
> extended to cope with non-Ubuntu PPAs, and it's time to think about how
> we're going to handle this in CI Train.
> 
> We probably just want to create another 20 silos for ubuntu-rtm once it
> exists.  The open questions are how to refer to them, and how to arrange
> to land things in them.  In the remainder of this mail I will refer to
> PPAs consistently using their new ~OWNER/DISTRIBUTION/NAME scheme in an
> attempt to minimise confusion.
> 
> Note that Didier indicated in
> https://lists.ubuntu.com/archives/ubuntu-release/2014-June/002898.html
> that he thought the changes to cupstream2distro itself would be pretty
> straightforward.  I agree, for what it's worth.
> 
>  * Names?  The current scheme is
>    ~ci-train-ppa-service/ubuntu/landing-{000..020}, with 000 being a
>    test silo.  We could use
>    ~ci-train-ppa-service/ubuntu-rtm/landing-{021..040} to avoid having
>    to invent a new naming scheme.  However, this is sort of non-obvious
>    to the uninitiated, it doesn't give us a nice space for a test silo,
>    and it cuts off further expansion of the ubuntu silos in case we need
>    that.  Could we use
>    ~ci-train-ppa-service/ubuntu-rtm/landing-{000..020}?  Launchpad will
>    permit this (PPAs are unique up to owner/distribution/name), so the
>    only question is whether this is clear enough.

Yeah, so personally I would indeed prefer the
~ci-train-ppa-service/ubuntu-rtm/landing-{000..020} approach, as it
makes it all clear from the first glimpse if it's an RTM silo or not.

>  * How do we refer to these informally?  Right now people say "silo 1"
>    etc.  Perhaps "silo RTM-1"?  I think it ought to be made clear when
>    you're landing something in the more tightly-controlled RTM archive.
> 
>  * How will we handle this in the spreadsheet?  My only thought so far
>    is that we should have a column for whether you're targeting RTM or
>    not.  But I guess at the moment we have a destination series in the
>    "Assign to silo" menu entry, which is used for trusty builds - I
>    guess maybe that could be extended to include a distribution?  Seems
>    a bit easy to make a mistake that way though.

I guess an explicit mandatory column for 'target' in every landing row
would be good, and even useful in overall. We could use this column to
determine not only what distribution you are targetting (Ubuntu/Ubuntu
RTM) but also if it's a trusty SRU or similar. Right now we have to do
that in the landing description, so having an explicit column for both
would be great.

We could then simply extend the spreadsheet to include 20 additional
sheets, each named landing-rtm-001 etc. - no additional philosophy.
Doing that and changing the fields to include a 'distribution' field are
easy. It would make the spreadsheet less readable, yes, but I always
preferred thinking of it as the 'database', not the presentation layer -
especially since we've got Robert's dashboard now.

>  * Presumably the backend and the dashboard would both need to be
>    extended.  I'm not familiar with the details here and would welcome
>    commentary from those who are.

The backend would need the additional jobs to handle the new silos, but
that's not a big problem. I'll check if we're ready for copies to a
'different' distribution, but I'm pretty sure we are or it's just a
quick change required.

Let me make sure we're ready when the time comes.

>  * Anything else?
> 
> Thanks,
> 

Anyway, this way wouldn't be the cleanest, but at least we wouldn't
waste time on reimplementing things for the CI Train which, I hope, will
anyway not live for too much longer.

Best regards,

-- 
Łukasz 'sil2100' Zemczak
 lukasz.zemczak@xxxxxxxxxxxxx
 www.canonical.com