I think the easiest would be to use the GitLab tags. Hopefully, we will soon use Gitlab for everything and then it won't be a problem.
For example, promo will just need to go to these two links to find all the information we need: * https://invent.kde.org/groups/kde/-/issues?label_name%5B%5D=Noteworthy * https://invent.kde.org/groups/kde/-/merge_requests?label_name%5B%5D=Noteworthy Carl ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le dimanche, avril 19, 2020 9:15 AM, Ben Cooksley <bcooks...@kde.org> a écrit : > On Sun, Apr 19, 2020 at 8:34 PM XYQuadrat m...@xyquadrat.ch wrote: > > > If we implement such a system (that is, just resurrect what is already > > present), I definitely think it would be sensible to make guidelines on > > what commits we are interested in publicly available. > > The thing I'm not sure about is how easy it'd be to automate grabbing > > all the CHANGELOG commits from a given date range - can someone more > > experienced with our git/repo infrastructure shed some light here? > > That depends on whether you have local, up to date, clones of the > repositories in question. > If you have them locally it should be reasonably trivial with a bit of > scripting to get a list of commits and the repositories to which they > belong. > > If you don't, then the only other option you would have would be > Gitlab's APIs but that isn't ideal from an infrastructural point of > view. > > > Best regards, > > Julian / xyquadrat > > Cheers, > Ben > > > On 17.04.20 01:19, Johannes Zarl-Zierl wrote: > > > > > On Donnerstag, 16. April 2020 23:15:18 CEST Nate Graham wrote: > > > > > > > On 4/16/20 2:38 PM, Albert Astals Cid wrote: > > > > > > > > > It may make sense to highlight them a bit more somehow, suggestions > > > > > welcome i guess. > > > > > The promo people just need a list of all CHANGELOG entries in a > > > > > release > > > > > so they can rewrite it in more human-friendly terms. Right now this is > > > > > done manually by me and others by looking through commit logs and blog > > > > > posts and adding the equivalent of CHANGELOG text into an > > > > > etherpad/share.kde.org document. Automating that somehow would be > > > > > nice. > > > > > From a developer point of view, a tag in the commit itself seems like > > > > > a nice > > > > > interface. One thing I fear, though, is that people like me forget to > > > > > actually > > > > > add it to the commit before pushing, so maybe something that can be > > > > > added > > > > > later would definitely have its advantages. > > > > > > Personally, I'd like to have some clear guidelines from the promo team > > > on what > > > kind of features they are looking for. That way it's way easier for me to > > > match those expectations ;-) > > > Btw. isn't the DIGEST keyword as documented in the standard commit > > > template > > > basically the same idea? > > > Cheers, > > > Johannes
publickey - carl@carlschwan.eu - 0x7F564CB5.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
