checkbox-dev team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

On 14-02-17 02:32 PM, Zygmunt Krynicki wrote:
> 1. I would like to propose that the on-disk format field ``name`` be deprecated
>    and not used anymore.
> 2. If the field ``name`` is used, it will be transparently mapped to ``id`` and
>    used to define the new job attribute ``JobDefinition.id``. All uses of
>    ``name`` will cause warnings to be logged. After a while we can remove that
>    feature and rejects the ``name`` field (for another period, after which we
>    could reuse it).
> 3. A new field ``summary`` is defined and mandatory for all jobs. The summary
>    field must be one line, short (capped to some reasonable amount) and should
>    be derived from the current name field in a meaningful way (manually, one
>    time transition process).
> 4. The ``summary`` field will be translatable
> 5. PlainBox will resort to ``JobDefinition.summary`` instead of ``.id``
>    whenever the job needs to be displayed or converted to a string.
> 
> Impact
> ======
> 
> This proposal would need to see forked job definitions *or* add support for
> ``summary`` in the old checkbox. The level of required support is minimal, only
> to the point where current functionality does not regress

+1 on this, adding support for "summary" to old checkbox should be easy, we just
need to ensure that the submission parser used in c3 doesn't choke on it (I
don't think it will). This was done for estimated_duration and the transition
was pretty smooth.

Anyway this probably will be easier to do and maintain than forking all the job
definitions; this is a part that changes often and keeping them in sync may be
labor-intensive.

Once we remove "name", will we need to start adding "id" to jobs as well?
wouldn't it be equivalent to just add "summary" and use that when the job needs
to be displayed, only using "id" in e.g. whitelists and internally?

- Daniel