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

[Maciej Kisielewski]

>
> I think this can be done as the first step.

I just thought having everything in code-wise, before starting pulling the
documentation and making references, would be optimal.
But yeah, iterating on the docs is a lighter work time-wise, than the code.

I don't think it is really needed to have both.

Theoretically Plainbox should still be self-sustainable. Having it point to
Checkbox docs is IMHO wrong, this is why I proposed having both.

I'd start with such new ingredient as combining guacamole + legacy argparse
> commands
> in checkbox-cli could quickly become messy.
>
+1. There's this quest of pulling the plug on legacy stuff :-)

On Mon, Aug 29, 2016 at 1:12 PM, Sylvain Pineau <
sylvain.pineau at canonical.com> wrote:

> 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/mailm
>>> an/listinfo/checkbox-devel
>>>
>>
>
>
> --
> Checkbox-devel mailing list
> Checkbox-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/checkbox-devel
>



-- 
Have a good one,
Maciek