checkbox-dev team mailing list archive

[Ara Pulido <ara.pulido@xxxxxxxxxxxxx>]

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.

> 
>> 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.

> 
>> We are very close to having that minimum working test runner, and that's
>> fantastic, so we should be focusing next in having a good set of tests.
>> The test runner is just a tool, what it really provides value are the
>> tests themselves.
> 
> I don't disagree with that.
> 
>> 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.

> 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?

Thanks,
Ara.

> 
> Thanks
> ZK
>