Docs overhaul follow up - c-box, p-box duality

[Sylvain Pineau]

On 29/08/2016 12:32, Ara Pulido wrote:
> On Mon, Aug 29, 2016 at 12:28 PM, Maciej Kisielewski
> <maciej.kisielewski at canonical.com> wrote:
>> Hey folks!
>>
>> As I spent some time improving the docs, some concerns/question came to my
>> mind.
>> I would like to discuss them, and probably reforge them into future stories.
>> It all boils down to Checkbox / Plainbox duality.
>>
>> Checkbox and Checkbox-Converged have practically the same functionality.
>> Anyone using launchers knows they're running Checkbox. Yet, Plainbox is not
>> only known to end-users, but it's also required, to run some scenarios,
>> like:
>> - starting a provider
>> - running one, particular job
>> - listing units
>>
>> As a result, end-users, or devs starting to hack something in Checkbox*,
>> are getting perplexed.
>>
>> Then there's the naming issue. There are plainbox units, providers, and so
>> on. Perplexity intensifies.
>>
>> I know that renaming stuff to be checkbox * would be a small revolution, so
>> first I would like to move all Plainbox functionality (as in $ plainbox
>> invocation) to Checkbox (-cli).
>> This way no one will be recommended to run plainbox at any point.
> I think this is a great idea
>
> +1
I also like this idea. Currently checkbox-cli unique option is a 
launcher definition file.
But there's no plainbox guacamole ingredient to inherit all pure 
plainbox commands.
I'd start with such new ingredient as combining guacamole + legacy 
argparse commands
in checkbox-cli could quickly become messy.
>> Second step would be to transplant/copy Plainbox docs chapters related to
>> units syntax (and all else not dev-related) to Checkbox docs.
> I think this can be done as the first step. I think we should move all
> docs to checkbox, and keep the plainbox docs to just a pointer to the
> checkbox ones.
>
> I don't think it is really needed to have both.
>
> What do you think?
>
> Thanks for starting this!
> Ara.
>
>> Third, the aforementioned revolution of renaming stuff, which might not be
>> worth one's while.
>>
>> I understand why Checkbox / Plainbox separation came to be, but those two
>> Checkbox are the only two real Plainbox applications, so I would like to
>> make them easier to use for all clients and stakeholders.
>>
>> Oh, and BTW, internally I still want the split of core and app, as it is
>> today.
>>
>> Any thoughts?
>>
>> --
>> Have a good one,
>> Maciek
>> --
>> Checkbox-devel mailing list
>> Checkbox-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/checkbox-devel