← Back to branch summary

~jocave/checkbox/hybrid-amd-gpu-mods

« back to all changes in this revision

Viewing changes to cep/CEP-3.txt

  • Committer: Zygmunt Krynicki
  • Date: 2014-12-19 12:11:52 UTC
  • mto: This revision was merged to the branch mainline in revision 3516.
  • Revision ID: zygmunt.krynicki@canonical.com-20141219121152-y9vtxajhrd6e1c3l
cep: merge CEPs in to trunk

This patch merges CEPs (aka Checkbox Enhancement Proposals) into trunk.
Those lived on separately for a while as lp:checkbox/cep but in
retrospective nobody knows about them and this should give them some
more exposure. In addition, the move allows new features to land a CEP
document along, making review of complex new features easier to make as
their specification can be seen alongside the patches that implement it.

Due to bazaar limitations in merging separate repositories together I've
discarded history entries (not that there were many) and just added
those files in directly.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

Show diffs side-by-side

added added

removed removed

Lines of Context:
cep/CEP-3.txt
 
1
 
 
2
Rationale
 
3
=========
 
4
 
 
5
Current efforts to make plainbox, checkbox and various job providers
 
6
translatable are affected by the fact that we abuse JobDefinition.name as both
 
7
english-like constant identifier and user-visible name. I would like to
 
8
decouple those roles.
 
9
 
 
10
Proposal
 
11
========
 
12
 
 
13
1. I would like to propose that the on-disk format field ``name`` be deprecated
 
14
   and not used anymore.
 
15
2. If the field ``name`` is used, it will be transparently mapped to ``id`` and
 
16
   used to define the new job attribute ``JobDefinition.id``. All uses of
 
17
   ``name`` will cause warnings to be logged. After a while we can remove that
 
18
   feature and rejects the ``name`` field (for another period, after which we
 
19
   could reuse it).
 
20
3. A new field ``summary`` is defined and mandatory for all jobs. The summary
 
21
   field must be one line, short (capped to some reasonable amount) and should
 
22
   be derived from the current name field in a meaningful way (manually, one
 
23
   time transition process).
 
24
4. The ``summary`` field will be translatable
 
25
5. PlainBox will resort to ``JobDefinition.summary`` instead of ``.id``
 
26
   whenever the job needs to be displayed or converted to a string.
 
27
 
 
28
Impact
 
29
======
 
30
 
 
31
This proposal would need to see forked job definitions *or* add support for
 
32
``summary`` in the old checkbox. The level of required support is minimal, only
 
33
to the point where current functionality does not regress
 
34