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

[Ara Pulido]

On Mon, Aug 29, 2016 at 2:11 PM, Maciej Kisielewski
<maciej.kisielewski at canonical.com> wrote:
>>
>> 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.

You said it: theoretically :)
But, in practise, the duality confuses people.

I think it could be totally OK to say in the Plainbox docs: "Plainbox
documentation is available at checkbox.readthedocs.org, the main
application that uses the Plainbox library".

I think the original idea of this user story (the documentation one)
was to move everything to Checkbox.

Has the scope changed?

Thanks!
Ara.

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