Given the impending GitLab transition, it might make more sense to just
use GitLab's tags/labels feature, yeah. That solves the problem of
people forgetting to use the keyword before committing since it can
always be added later, and it makes it easy for promo people to find the
relevant commits using the web interface so they don't have to check out
every repo and use a script.
Nate
On 4/19/20 2:34 AM, XYQuadrat 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?
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
