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

[Maciej Kisielewski]

>
> I think the original idea of this user story (the documentation one)
> was to move everything to Checkbox.
>
> Has the scope changed?


More like my understanding of 'everything' required time to ripen.

On Mon, Aug 29, 2016 at 2:58 PM, Ara Pulido <ara.pulido at canonical.com>
wrote:

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



-- 
Have a good one,
Maciek