-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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'.
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. :) 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. 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. Sorry for top-posting. I didn't see a way to do proper replies in K-9. On January 12, 2016 10:13:39 AM PST, Ulrich Mueller <u...@gentoo.org> wrote: >In its last meeting the council has accepted an extension of the >news item format which allows EAPI=5 style package dependency >specifications. This has triggered a discussion if this change is >backwards or forwards compatible, and what should be the new format's >version number [1]. Also it is not entirely clear if the term >"backwards-compatible" used in GLEP 42 correctly describes what was >originally intended [2]. > >In any case, both portage [3] and paludis [4] will have to be updated >for the new format because the change is not forwards-compatible. > >Therefore, we could use the opportunity to add some other features. >So far, this includes: > >1. Display-If-Installed: Allow EAPI=5 style package dependency > specifications (see above). > >2. Display-If-Profile: Allow wildcards like default-linux/* [5]. > >3. Title: Increase maximum length. In the past, devs repeatedly > struggled with the current 44 character limit. (Can anyone > enlighten me where this originates from? I cannot find anything in > the discussions around the time when GLEP 42 was submitted.) > The eselect news reader could still display a 51 character title > in one line for the "list" and "read" commands, on an 80 character > wide terminal. > I suggest we round this down to a maximum length of 50 characters, > which (together with the 72 character limit for the body) would > nicely agree with the limits recommended for git commit messages. > >4. Content-Type: Only one value is allowed for this header, namely > text/plain. We might as well drop it, because any changes there > will require an increment of the News-Item-Format. > >If these changes find agreement, I would prepare a new GLEP for news >item format 2.0. > >Ulrich > > >[1] https://bugs.gentoo.org/show_bug.cgi?id=568068#c4 >[2] >https://archives.gentoo.org/gentoo-dev/message/d30de011db9067ae3cc298de2b4ee1b2 >[3] >https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/news.py?id=7c94014a32d173ae61919b762140ac1c32d3b522#n273 >[4] >http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/e_repository_news.cc?id=1684b446715907515359cd310c1e7bd93bad5a2e#n326 >[5] https://bugs.gentoo.org/show_bug.cgi?id=290038 - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -----BEGIN PGP SIGNATURE----- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAlaVkQkACgkQASQOlFA54XAYuQ/9F0qt4BaPTan+rMBd MkbjA1A4EeaLgGT0BAlv5oKhfR5VC4fNoWcfCB+Z11Bkyi+8DRGLWoEqF1KvFKsb CLu8a8Q/+T34JuvKznCJrHfnkFYwARVXpOVX70t3Sr50BSpe5lvmQ4PQ8PpOFTnJ O4bo9GjxKTujVvu1LxYSv3CLJ6AV9HANsl5rkBQ+TKi4qrwqBTWK4VGNTCon/DFt EUTRuz7TXlpE6quMTTk7Wx8yldRgC7mL2SwYsH0KosrBaMTv5yVWipZMdEP6oPRp ovYhPNgPYPrct8DuiOOXvNJms8Ll5oS/m07w5MUr7KzWAoWjFluQAVR+HOACfXuk 7YiSk9FbH+a3t6aEGNrEX7VRcG8A2UG6nDsc5GNXLc+ObPvfsykXZs6vchfC8J+j wJp8R/dXecAyw9HmjQ6cx3N3lw65YG+3I1cK883GuvGGb7P9BOeWuloouhqEfOc5 OaptMrWWJM9T8FNzgZVXc8tJmrCexw1HFKUfjhcJinIffHfRoeIjmSJcTtKliW/k 0VHtmhjr4OkBr+wcjf5uZEAstq/4/Jp1ArS3URaXtDEBuY0xKaR/WLMPtcuu4X1K fFkah8qS/jR8qqE9KecULE25c8C47im6EJGk6Wgzb/8MNx3J4iZ8P0PHS+kLEZFq uyrSyEwwvx2ES92sDb+EaXW0B08= =7A0/ -----END PGP SIGNATURE-----
