checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

On Fri, Sep 26, 2014 at 9:58 AM, Ara Pulido <ara.pulido@xxxxxxxxxxxxx> wrote:
>
>
> On 26/09/14 09:50, Zygmunt Krynicki wrote:
>> On Fri, Sep 26, 2014 at 9:42 AM, Ara Pulido <ara.pulido@xxxxxxxxxxxxx> wrote:
>>
>>
>>> Having checkbox-touch working on 12.04 and 14.04 won't be enough,
>>> checkbox-gui has some features that are not in checkbox-touch (checking
>>> logs during the run, rerun tests, submit to C3, ...)
>>
>> That's true but we cannot even attempt feature parity unless we run on 12.04.
>
> 12.04 is not that necessary, really. We are about to finish all projects
> using 12.04. The only thing we will run on 12.04 once all pre-install
> projects with 12.04 are done and we finish 12.04.5 testing is SRU
> testing, and that doesn't use checkbox-gui.

That's very good to know, thanks. This means we need to get 14.04+
which is already in our scope.

>>> I don't think that our priorities should be adding those missing
>>> features to checkbox-touch, but having a good set of tests for phones
>>> and tablets and a minimum working test runner for phone and tablets.
>>
>> Our priorities should never focus only on the next short-term goal.
>> There lies checkbox-legacy. We should keep the stack maintainable and
>> supportable. We must not overlook the growing pile of stuff that is a
>> maintenance problem.
>
> I know, but this is not a short-term goal, it is a long term one (having
> a test suite we can run).
>
> Also, that's why we are investing in Plainbox.

And this is why I wrote this. Plainbox is tied to maintaining those
APIs, see below

>>> We could discuss whether we should fork checkbox-touch from the main
>>> branch (or the other way round) if we want to have a repository that is
>>> cleaner and shows what we really want to achieve going forward, but I
>>> don't think that working in adding more and more features to the touch
>>> interface for checkbox would help us achieve our goals.
>>
>> Checkbox touch is not the problem here. The true problem is in
>> plainbox and all the numerous APIs that are frozen just because we
>> have checkbox-gui. Moving the code to another repo won't solve that.
>
> I didn't mean moving checkbox-touch only, I meant forking the whole repo.

I think that's something we can consider but I would call it the most
extreme option. Keeping the non-future and future repo in sync would
be a pain.

>> The only way to solve that is to be able to evolve both our
>> applications and our back-end. We cannot evolve checkbox-gui without
>> spending a lot of time on something we ultimately want to get rid of
>> and replace with checkbox touch, as a single converged application.
>
> What do we want to evolve in checkbox-gui?

We need to evolve the APIs it's based on to keep them maintainable.
There's a lot of stuff in plainbox and checkbox-ng right now that is
only there because we have checkbox-gui and porting that to something
else is a pain. With checkbox-touch we just don't have that problem as
changing a few calls in python is trivial compared to changing the
DBus layer and the C++ layer and testing that (and the whole
architecture there is hostile to any change).

Thanks
ZK