ubuntu-phone team mailing list archive

[Oliver Grawert <ogra@xxxxxxxxxx>]

hi,
Am Samstag, den 22.02.2014, 07:15 -0300 schrieb Roberto Alsina:
> Ok, looks like I jumped the gun there asking for the removal. In which
> case, oops, my bad, let's revert.
> 
> 
> On Sat, Feb 22, 2014 at 6:46 AM, Sebastien Bacher 
>         
>         Indeed it's not, can we revert that dropping? Who decided to
>         drop the current UI before having the new one in place?
>         
so this exposes quite a flaw between the CI Train and package handling
(I noticed this issue before with other packages but there the landings
finally happened in time due to sheer luck). To roll back the change I
need to actually roll back changes that are sitting with a different
(higher) version in a different silo already.

How do we plan to handle that different versions of the same package
might sit in different silos and actually enter the archive in a
different order than the changes in the package reflect. I.e. if the
same package has three different stacked changes in three silos that
were added to the branch/package in the order of silo 1,2 and 3 but only
silo 3 can land and silo 1 actually gets fully reverted while silo 2
will land in two days, the package will ship the changes from the first
two silos ahead of time (or in case of the dropped silo 1 even ship
completely unwanted changes). 

The owner of a package or branch can not know in advance if the changes
he approved for silo 1 and 2 will ever land but since they have to be
added to the branch/package in succession the landing of silo 3 will
drag all three of them into the archive unless they get reverted before
the actual landing happens.

for this particular landing I will have to actually roll back the seed
branch two revisions so that the change gets properly reverted in the
archive without going completely out of sync with reality and then will
have to apply the silo specific changes on top and re-upload the change
to the silo ... 

This puts a high penalty on package/branch maintainers for packages that
can span across different changes (like the meta packages and seeds) to
actually keep an eye on the landings and move backwards through changes
and upload/approve them in reverse order to the different silos to not
mess up the order of landing changes in the archive.

Does anyone see any solution to this ? I expect us to run into this
issue more frequently as soon as the landing frequency rises over time.

ciao
	oli

Attachment: signature.asc
Description: This is a digitally signed message part