1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA512 |
3 |
|
4 |
I don't see why backwards compatibility would be a problem. The older news format spec supports fewer features, so the new spec should be much like newer EAPIs and 'just work'. |
5 |
|
6 |
I'm in favor of all the changes you laid out. A good number of us are already familiar with git-style limitations, and they're rather sane to begin with. I could see issues with bigger changes fitting into 50 characters, but I guess that's what creative wording is for. :) |
7 |
|
8 |
It's odd that news items even have the Content-Type attribute. Before removing it, are there any other formats we could feasibly want in the future? I can't think of any formats we'd want to use, but maybe someone else has an idea. |
9 |
|
10 |
In general, though, I'm in favor of the changes if it makes life easier for those writing news. I don't write news items right now, but I may end up doing it in the future. |
11 |
|
12 |
Sorry for top-posting. I didn't see a way to do proper replies in K-9. |
13 |
|
14 |
On January 12, 2016 10:13:39 AM PST, Ulrich Mueller <ulm@g.o> wrote: |
15 |
>In its last meeting the council has accepted an extension of the |
16 |
>news item format which allows EAPI=5 style package dependency |
17 |
>specifications. This has triggered a discussion if this change is |
18 |
>backwards or forwards compatible, and what should be the new format's |
19 |
>version number [1]. Also it is not entirely clear if the term |
20 |
>"backwards-compatible" used in GLEP 42 correctly describes what was |
21 |
>originally intended [2]. |
22 |
> |
23 |
>In any case, both portage [3] and paludis [4] will have to be updated |
24 |
>for the new format because the change is not forwards-compatible. |
25 |
> |
26 |
>Therefore, we could use the opportunity to add some other features. |
27 |
>So far, this includes: |
28 |
> |
29 |
>1. Display-If-Installed: Allow EAPI=5 style package dependency |
30 |
> specifications (see above). |
31 |
> |
32 |
>2. Display-If-Profile: Allow wildcards like default-linux/* [5]. |
33 |
> |
34 |
>3. Title: Increase maximum length. In the past, devs repeatedly |
35 |
> struggled with the current 44 character limit. (Can anyone |
36 |
> enlighten me where this originates from? I cannot find anything in |
37 |
> the discussions around the time when GLEP 42 was submitted.) |
38 |
> The eselect news reader could still display a 51 character title |
39 |
> in one line for the "list" and "read" commands, on an 80 character |
40 |
> wide terminal. |
41 |
> I suggest we round this down to a maximum length of 50 characters, |
42 |
> which (together with the 72 character limit for the body) would |
43 |
> nicely agree with the limits recommended for git commit messages. |
44 |
> |
45 |
>4. Content-Type: Only one value is allowed for this header, namely |
46 |
> text/plain. We might as well drop it, because any changes there |
47 |
> will require an increment of the News-Item-Format. |
48 |
> |
49 |
>If these changes find agreement, I would prepare a new GLEP for news |
50 |
>item format 2.0. |
51 |
> |
52 |
>Ulrich |
53 |
> |
54 |
> |
55 |
>[1] https://bugs.gentoo.org/show_bug.cgi?id=568068#c4 |
56 |
>[2] |
57 |
>https://archives.gentoo.org/gentoo-dev/message/d30de011db9067ae3cc298de2b4ee1b2 |
58 |
>[3] |
59 |
>https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py?id=7c94014a32d173ae61919b762140ac1c32d3b522#n273 |
60 |
>[4] |
61 |
>http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/e_repository_news.cc?id=1684b446715907515359cd310c1e7bd93bad5a2e#n326 |
62 |
>[5] https://bugs.gentoo.org/show_bug.cgi?id=290038 |
63 |
|
64 |
- -- |
65 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
66 |
-----BEGIN PGP SIGNATURE----- |
67 |
|
68 |
iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 |
69 |
bGdAZ2VudG9vLm9yZz4FAlaVkQkACgkQASQOlFA54XAYuQ/9F0qt4BaPTan+rMBd |
70 |
MkbjA1A4EeaLgGT0BAlv5oKhfR5VC4fNoWcfCB+Z11Bkyi+8DRGLWoEqF1KvFKsb |
71 |
CLu8a8Q/+T34JuvKznCJrHfnkFYwARVXpOVX70t3Sr50BSpe5lvmQ4PQ8PpOFTnJ |
72 |
O4bo9GjxKTujVvu1LxYSv3CLJ6AV9HANsl5rkBQ+TKi4qrwqBTWK4VGNTCon/DFt |
73 |
EUTRuz7TXlpE6quMTTk7Wx8yldRgC7mL2SwYsH0KosrBaMTv5yVWipZMdEP6oPRp |
74 |
ovYhPNgPYPrct8DuiOOXvNJms8Ll5oS/m07w5MUr7KzWAoWjFluQAVR+HOACfXuk |
75 |
7YiSk9FbH+a3t6aEGNrEX7VRcG8A2UG6nDsc5GNXLc+ObPvfsykXZs6vchfC8J+j |
76 |
wJp8R/dXecAyw9HmjQ6cx3N3lw65YG+3I1cK883GuvGGb7P9BOeWuloouhqEfOc5 |
77 |
OaptMrWWJM9T8FNzgZVXc8tJmrCexw1HFKUfjhcJinIffHfRoeIjmSJcTtKliW/k |
78 |
0VHtmhjr4OkBr+wcjf5uZEAstq/4/Jp1ArS3URaXtDEBuY0xKaR/WLMPtcuu4X1K |
79 |
fFkah8qS/jR8qqE9KecULE25c8C47im6EJGk6Wgzb/8MNx3J4iZ8P0PHS+kLEZFq |
80 |
uyrSyEwwvx2ES92sDb+EaXW0B08= |
81 |
=7A0/ |
82 |
-----END PGP SIGNATURE----- |