I would definitely love that!
Having the ability to list all changes at a single place, comment, and even organise them by tags seems like a way forward.
BTW I know that Pagure stores issues in git, so that could solve the history problem, although I don't know how exactly is that implemented.
On Fri, Aug 24, 2018 at 3:50 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
Thanks for the feedback so far. Some of the responses are fairly
similar, so I'll try to clump them together:
> Vote in the Change ticket or a FESCo ticket?
The intent, for now, is to still have FESCo vote in a separate ticket,
mostly for their visibility. Alternatively, I could tag all FESCo
members in the change ticket. This part of the process is no different
from what we do now, so I'd leave it to FESCo to decide where they
would want to vote.
> Three repos is too many repos
Yes! As with the above, one option would be to have the Docs team use
the Changes repo for release notes tracking as well. Again, the issue
is visibility, but if they're open to using the Changes repo as the
single source of truth, I think that works out better for everyone.
> Changes as Markdown files
This does address the history, but it loses the metadata aspect that
makes the current process clunky. Being able to script against the
metadata fields eliminates trying to parse the wiki text and hope
nothing too unusual is in there. One option would be to change it so
that the markdown file is submitted as a PR, but then the change is
submitted as an issue that points to the PR. It's a little bit
clunkier, but it would give us both edit history and some enforced
structure. The downside means that if I were to automate, e.g.,
sending the announcement email, the script would have to find the PR
from the issue and then find the appropriate file from the PR.
The proposal isn't what I'd come up with if time and resources were no
concern, but it's what I can come up with that stands a chance of
being implemented. I'm really intrigued by the idea of using markdown
files both from an easier-for-submission standpoint and also from a
"here's the entire history of our changes" standpoint. I'm just
concerned that it will make all of the backend processing more
cumbersome. If there's something I'm missing on this, I'd love to
explore the idea some more.
> But what about Bugzilla?
I agree that the ability to link other BZ issues to the Changes is
helpful, but in my limited experience so far, it's not a common use
case.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/GUYCGNJUZCBOFL2R7BFTG6RWCJKSGDHA/
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
