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?
Best regards,
Julian / xyquadrat
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
