On Fri, Sep 26, 2014 at 9:58 AM, Ara Pulido <[email protected]> wrote: > > > On 26/09/14 09:50, Zygmunt Krynicki wrote: >> On Fri, Sep 26, 2014 at 9:42 AM, Ara Pulido <[email protected]> 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 -- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
