El dilluns, 20 d’abril de 2020, a les 13:46:47 CEST, Carl Schwan va escriure: > 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
How do you know in that url what is in one release and what is not? So we don't have the mistake that we announce something is in a release when instead is in the next one? Cheers, Albert > > 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 > >
