linaro-infrastructure-stakeholders team mailing list archive

[Mattias Backman <mattias.backman@xxxxxxxxxx>]

On Mon, May 30, 2011 at 11:30 AM, Alexander Sack <asac@xxxxxxxxxx> wrote:
> On Mon, May 30, 2011 at 11:19 AM, Mattias Backman
> <mattias.backman@xxxxxxxxxx> wrote:
>> On Fri, May 27, 2011 at 2:55 PM, Loïc Minier <lool@xxxxxxxx> wrote:
>>>        Hey
>>>
>>>  The Android support in Linaro Image Tools feels like a second class
>>>  citizen; it was a bit rushed in, and to my knowledge didn't get the
>>>  chance to be architectured properly into linaro-image-tools so that it
>>>  would be on equal footing with the Ubuntu-based images.
>>>
>>>  It would be nice to chance this so that it's clearly owned and well
>>>  supported; how do we get this ball rolling?
>>>
>>>  AFAIK, the only spec on linaro-image-tools for next cycle is hwpackv2
>>>  which is kind of unrelated.  Who would be interested in discussing
>>>  evolutions to the design of the Android support in Linaro Image Tools
>>>  and who would be interested in participating in the implementation?
>>
>> I would be interested in both aspects and I agree that something needs
>> to be done so the two scripts don't diverge entirely. Whether it's a
>> good idea that I spend time on this is of course up to James.
>
> How bad is the maintainability for the android script for the time
> being? e.g. how urgent is it?

It's not terribly urgent, in my view it's more the fact that the
Android script reuses some parts of l-m-c and overrides others and is
pretty unknown to me. But how changes are to be handled has to be
discussed since there already are uncertainty about what the scripts
should support, for instance using the android script to create images
or not. There are also four separate ways to handle partitions
(android vs ubuntu based and image/mmc for both) which to me looks
hard to maintain and possibly could be made easier by changing to the
image/dd approach and stop partitioning mmc:s directly. For that kind
of changes in l-i-t we need to consider both scripts so we don't end
up with two entirely separate tracks.

>
> With the info that we might change what artifacts we provide/install
> in a 1-2 month timeframe, would a cleanup now still make sense in your
> opinion?

I don't think it is a reason to postpone changes, at least not if the
partition layout will remain the same or similar. The code that
assumes that the artifacts are those three tarballs is really minimal.
The major parts is concerning partitioning. Will we build a system.img
instead of a system tarball etc, or will the artifacts be something
else entirely do you think?