I think filtering MR's based on the target branch (e.g. release/20.04)
should work here, as the releases are (as far as I am aware) then
generated from these branches.
For issues, this would only work if we also made "Releases" (the GitLab
feature) based on the git tag. I am not sure if this is productive,
because it would be an additional effort required for every release.
Best regards,
Julian
(Aside: It appears to me that I'm too young to use mailing lists
correctly... It has now happened twice that I responded to a single
person instead of the whole list - sincere apologies and one day I'll
figure out this arcane technology.)
On 21.04.20 23:27, Albert Astals Cid wrote:
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
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
