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 <bcot...@redhat.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org/message/GUYCGNJUZCBOFL2R7BFTG6RWCJKSGDHA/ > -- Adam Šamalík --------------------------- Software Engineer Red Hat
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
