checkbox-dev team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

On 14-02-17 02:42 PM, Zygmunt Krynicki wrote:
> 
> 
> 
> On Mon, Feb 17, 2014 at 8:40 PM, Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx
> <mailto:daniel.manrique@xxxxxxxxxxxxx>> wrote:
> 
>     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).

A new thought on this item. How rigid will we be with the capping? since summary
is meant to be translated, I'm thinking about the case where we restrict to say
50 characters and some language's translation turns out to be 100 chars.

Maybe just logging a warning if a translation exceeds X size, but still trying
to display it. If things look bad due to it being too long, we will get bug
reports and we can ask for the translations to be shortened.

My main point is that a hard cap would be undesirable for the above reasons
(i.e. rejecting job definitions as invalid would be too strict), but we still
would want to encourage translators (and test developers) to keep summaries short.

>     > 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?
> 
> 
> I was hoping that we could do one-time s/name:/id:/g across all jobs and just
> teach checkbox to use that. The reason to block name for a while is to cope with
> cases where someone has jobs that were not transitioned and still wants to use
> them. I think we should support that use case for as long as possible.

This sounds OK, we'd also need to track down documentation mentioning use of
"name" and update that.


> Alternatively we could just stick with name, and although confusing, it could work.

Not needed, a wholesale transition with support for the old version makes sense.


> 
> Thanks
> ZK
>