[coreboot] [RFC] board-status.git growth

[Martin Roth]

It's definitely an issue, and it's actually something that is
currently being looked into.  As always, we just need someone to do
the work.  :)

There's a project listed on the project ideas wiki page about this, so
maybe we'll get an enterprising person to work on it.  If not, we'll
probably continue with git for now, but put a web front-end on it so
that the project doesn't need to be downloaded to add to the database.
Here's a link to it in the wiki:
https://www.coreboot.org/Project_Ideas#coreboot_mainboard_test_suite_reporting

I think we all agree that git isn't the right way to do this, but it
was infrastructure we had in place, so it was an easy way to add what
was needed at the time.  We're reaching a pain point on that, so it's
definitely time to do SOMETHING about it.

Martin


On Wed, Feb 17, 2016 at 2:54 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
> Maybe using git a monotonically increasing entry count is the wrong way
> to go about it. That's beyond the scope, mission, design and goal of git.
>
> I would rethink the entire board-status mechanism to something more
> suited to the task than git.
>
> Yours truly,
> The Devil
>
> On 02/17/2016 01:07 PM, Carl-Daniel Hailfinger wrote:
>> Hi,
>>
>> since various automated systems started submitting board status files,
>> the board-status repository has grown significantly to a point where
>> submitting a new board from scratch requires a download which is bigger
>> than the whole coreboot repository.
>> Once I hook up four more systems in my lab, I expect this growth to
>> accelerate quite a bit. It will get even more extreme once I start
>> testing every commit instead of limiting the tests to one per hour.
>>
>> This poses three problems:
>>
>> 1. Download size for people wanting to submit new logs.
>> Can be solved with shallow git clones of the board-status repository.
>>
>> 2. Download size for people wanting to find out where some breakage
>> happened.
>> Not really solvable unless we commit less reports, and that makes
>> bisection harder.
>>
>> 3. Server load for anything working with the board-status repo.
>> This means gitweb and the wiki, and that's not a problem (yet).
>>
>> Should we just ignore the size until it becomes too large, is size not a
>> problem or should we immediately do something?
>>
>> Regards,
>> Carl-Daniel
>>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot