El dijous, 16 d’abril de 2020, a les 0:44:50 CEST, Nate Graham va escriure:
> On 4/15/20 3:40 PM, Albert Astals Cid wrote:
> > El dimecres, 15 d’abril de 2020, a les 16:04:53 CEST, Nate Graham va 
> > escriure:
> >> I support a standardized tag/keyword/whatever to attract promo attention
> >> to something. However if we use a GitLab tag, then we won't be capturing
> >> information from Phabricator patches during the time before we've fully
> >> transitioned to GitLab. Should we instead use a new NOTEWORTHY: Bugzilla
> >> keyword (like BUG: or FEATURE:) or wait do do this until after the
> >> GitLab migration is complete?
> > 
> > You mean something like CHANGELOG ;)
> > 
> > We already have it documented at 
> > https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages
> > 
> > People (me included) just sadly don't use it.
> 
> Oh man, look at that.
> 
> Sounds like we already have exactly what we need, we just need to start 
> using it! I can start doing that for reviews I participate in.
> 
> What would be the workflow for the promo folks being able to collect a 
> list of all commits with this keyword? grep through git logs?

Kind of yeah. Or use the "raw" changelogs we create for the releases, though 
depending on when the features are needed and when the changelogs are created 
may not give much time for writing the features.

For the release service releases we already parse CHANGELOG

https://cgit.kde.org/sysadmin/release-tools.git/tree/create_log.py#n135

But the only thing we do right now is use that text for the changelog file 
instead of the first line of the commit.

It may make sense to highlight them a bit more somehow, suggestions welcome i 
guess.

Not sure if the scripts used for Frameworks or Plasma (yes, we're silly like 
that and have different sets of scripts for changelog parsing) look for 
CHANGELOG but i guess it wouldn't be that hard.

Cheers,
  Albert

> 
> Nate
> 
> 




Reply via email to