Re: Idea: let's use Pagure to track Changes
Hi, Ben, On Fri, Aug 24, 2018 at 3:48 PM Ben Cotton wrote: > > 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. > Could you give an example, what kind of metadata is required? When you work with the change as a piece of code (~text in markdown), you can work via pull requests workflow. Thus, at the pre-merge phase while you are working on the proposal you can use tags and metadata on the pull request side. This can help to track Changes which require some work, Changes which were not voted upon and so on. And you don't need to create an issue on that. For the static metadata about the Change you can use the metadata in the Markdown itself. Almost every static generator site allows the metadata to be stored in the file [1]. And additionally the repo layout (folders hierarchy) can also be used for categorization. Both can be then exported in a machine-readable form. For dynamic info on the Change implementation (progress, blocked issues) we already have a Bugzilla tracking issue. And the good thing about Markdown here is that we can easily adjust any of static generators to collect and show info from Bugzilla right there on the Change page. Generally, I think that the Change itself is a content, which requires versioning, review and collaborative editing, and it fits much better to be the source code rather than the issues workflow. [1] http://docs.getpelican.com/en/3.6.3/content.html -- Aleksandra Fedorova bookwar at IRC ___ 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
Re: Idea: let's use Pagure to track Changes
On Fri, Aug 24, 2018 at 6:39 AM, Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Aug 23, 2018 at 11:52:57PM +0200, Miro Hrončok wrote: > > On 23.8.2018 22:43, Ben Cotton wrote: > > >Hi community, > > > > > >We've traditionally used the wiki for Change proposals because it's > > >the tool we had. But, it's not necessarily well-suited to the purpose. > > >But now we have Pagure, which can help address some of the > > >shortcomings of using the wiki: poor scriptability, no reporting, and > > >a lot of copy/paste. > > > > Good idea! > > > > >So I've come up with a plan that would use Pagure instead: > > >https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges > > > > > 6. FESCo votes on change. > > > > On the Pagure ticket with the change or in a separate FESCo Pagure > ticket? > > I think we should vote in the Change bug. I don't see advantages to > opening a new ticket. > > > >You can read the full details on the wiki page above, but the general > > >idea is that we won't change the policy for Changes, just how we store > > >and manipulate them. My intent is to make it nearly seamless for the > > >community while giving us a platform for building on the process in > > >the future. Note that this would run parallel to Bugzilla for a > > >release or two and then replace Bugzilla for Changes tracking. > > > > The good thing about Bugzilla trackers is that they can be used > > as... Bugzilla trackers. I mean you can block/depend other bugs on > > it. > > > > See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 > > and the dependent bugs. Of course, this might be relevant to some > > kind of Changes only, so the Bugzilla tracker can be optional, but > > I'd rather keep it as part of the process. > > I think we might want to make it an optional element. If the Change > needs a tracking bug, create it, otherwise not. I think most Changes > don't do any real tracking in bugzilla, except to change the bug as > "done" at some point. > > > One more thing that I didn't see explicitly mentioned in the proposal > is the fact that Change pages are also documentation, fairly widely > accessed, also long after the Change has been implemented. For this, > the fact that the Change page show no context by default is an advantage. > I wonder if we could request an enhancement to pagure to have a view > where just the main text is shown, without the side bar, comments, > headers, etc. > It'd be great if we could end this practice by having our documentation updated as a part of the change. Consumers of our software shouldn't need to know to check what will feel like "random" wiki pages to many of them for more docs. regards, bex > > Also, it should be clarified if Change owners should edit the original > text. > > Zbyszek > ___ > 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/VSTCNQXOVJWSOJQBE6CXAIJ3XUMKFVDM/ > -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org ___ 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
Re: Idea: let's use Pagure to track Changes
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 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
Re: Idea: let's use Pagure to track Changes
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/
Re: Idea: let's use Pagure to track Changes
On Fri, Aug 24, 2018 at 12:16:09PM +0200, Fabio Valentini wrote:
> On Fri, Aug 24, 2018, 11:38 David Sommerseth wrote:
>
> > On 23/08/18 22:43, Ben Cotton wrote:
> > > Hi community,
> > >
> > > We've traditionally used the wiki for Change proposals because it's
> > > the tool we had. But, it's not necessarily well-suited to the purpose.
> > > But now we have Pagure, which can help address some of the
> > > shortcomings of using the wiki: poor scriptability, no reporting, and
> > > a lot of copy/paste.
> > >
> > > So I've come up with a plan that would use Pagure instead:
> > > https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> > >
> > > You can read the full details on the wiki page above, but the general
> > > idea is that we won't change the policy for Changes, just how we store
> > > and manipulate them. My intent is to make it nearly seamless for the
> > > community while giving us a platform for building on the process in
> > > the future. Note that this would run parallel to Bugzilla for a
> > > release or two and then replace Bugzilla for Changes tracking.
> >
> > Even though I'm not as active here as I would like to be, I generally like
> > this idea.
> >
> > A few things which would be good to sort out are:
> >
> > * Still requires changes be represented in three different Pagure repos
> > * We lose edit history if a change proposal is updated based on feedback
> >
>
> Well, I suppose Changes could be represented as markdown/reStructuredText
> files in a repository instead of issues on pagure? Then edit history is no
> problem (that's what git is for), and proposed changes can be done via pull
> requests.
Hmmm, that'd also solve the issue of having a way to display the changes
in a nice way, that I started discussing in the other part of the thread.
Zbyszek
>
> Off the top of my head I'd suggest using a "fedora-changes" (?) project on
> pagure with folders for different fedora releases.
>
> - Edit history is accessible through git
> - Changes can be submitted and updated with pull requests
> - Postponing a change is as simple as moving a text file from one folder to
> another
> - Rejected or discarded changes can be archived in another folder
>
> (Just thinking out loud here.)
>
> Fabio
>
>
> > From my point of view, those are the most critical ones. The history is
> > good
> > when you want to see if/how things changed - to learn from specific changes
> > which went well or really bad. Not having a history to base it on makes
> > this
> > learning somewhat more difficult - as you don't know exactly how a change
> > proposal did develop, just the final result.
> >
> > Also having changes represented in three different repos sounds a bit too
> > bureaucratic to me. Processes are good to have, but in the moment they get
> > too complicated people will generally try to avoid them. If it is really
> > needed to involve three repos, then a decent tooling on top of it is
> > needed at
> > launch time; to hide this bureaucratic process a bit.
> >
> > Other than that, I think this idea makes perfect sense. The first time I
> > did
> > a change proposal (not even system-wide), it felt like an odd process ("Is
> > this the right template? In a wiki? Have I filled out all the proper fields
> > correctly? How is this proposal picked up and distributed properly?" are
> > some
> > of the thousands questions which popped up).
> >
> >
> > --
> > kind regards,
> >
> > David Sommerseth
> >
> > ___
> > 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/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
> >
> ___
> 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/R5H22KIXOWYIKUYIRSXZVOZNHINOBVLC/
___
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/6YG7X4THI32J4DSXTJMDSRU2XPSJSNGQ/
Re: Idea: let's use Pagure to track Changes
On Thu, Aug 23, 2018 at 11:52:57PM +0200, Miro Hrončok wrote: > On 23.8.2018 22:43, Ben Cotton wrote: > >Hi community, > > > >We've traditionally used the wiki for Change proposals because it's > >the tool we had. But, it's not necessarily well-suited to the purpose. > >But now we have Pagure, which can help address some of the > >shortcomings of using the wiki: poor scriptability, no reporting, and > >a lot of copy/paste. > > Good idea! > > >So I've come up with a plan that would use Pagure instead: > >https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges > > > 6. FESCo votes on change. > > On the Pagure ticket with the change or in a separate FESCo Pagure ticket? I think we should vote in the Change bug. I don't see advantages to opening a new ticket. > >You can read the full details on the wiki page above, but the general > >idea is that we won't change the policy for Changes, just how we store > >and manipulate them. My intent is to make it nearly seamless for the > >community while giving us a platform for building on the process in > >the future. Note that this would run parallel to Bugzilla for a > >release or two and then replace Bugzilla for Changes tracking. > > The good thing about Bugzilla trackers is that they can be used > as... Bugzilla trackers. I mean you can block/depend other bugs on > it. > > See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 > and the dependent bugs. Of course, this might be relevant to some > kind of Changes only, so the Bugzilla tracker can be optional, but > I'd rather keep it as part of the process. I think we might want to make it an optional element. If the Change needs a tracking bug, create it, otherwise not. I think most Changes don't do any real tracking in bugzilla, except to change the bug as "done" at some point. One more thing that I didn't see explicitly mentioned in the proposal is the fact that Change pages are also documentation, fairly widely accessed, also long after the Change has been implemented. For this, the fact that the Change page show no context by default is an advantage. I wonder if we could request an enhancement to pagure to have a view where just the main text is shown, without the side bar, comments, headers, etc. Also, it should be clarified if Change owners should edit the original text. Zbyszek ___ 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/VSTCNQXOVJWSOJQBE6CXAIJ3XUMKFVDM/
Re: Idea: let's use Pagure to track Changes
On Fri, Aug 24, 2018, 11:38 David Sommerseth wrote:
> On 23/08/18 22:43, Ben Cotton wrote:
> > Hi community,
> >
> > We've traditionally used the wiki for Change proposals because it's
> > the tool we had. But, it's not necessarily well-suited to the purpose.
> > But now we have Pagure, which can help address some of the
> > shortcomings of using the wiki: poor scriptability, no reporting, and
> > a lot of copy/paste.
> >
> > So I've come up with a plan that would use Pagure instead:
> > https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
> >
> > You can read the full details on the wiki page above, but the general
> > idea is that we won't change the policy for Changes, just how we store
> > and manipulate them. My intent is to make it nearly seamless for the
> > community while giving us a platform for building on the process in
> > the future. Note that this would run parallel to Bugzilla for a
> > release or two and then replace Bugzilla for Changes tracking.
>
> Even though I'm not as active here as I would like to be, I generally like
> this idea.
>
> A few things which would be good to sort out are:
>
> * Still requires changes be represented in three different Pagure repos
> * We lose edit history if a change proposal is updated based on feedback
>
Well, I suppose Changes could be represented as markdown/reStructuredText
files in a repository instead of issues on pagure? Then edit history is no
problem (that's what git is for), and proposed changes can be done via pull
requests.
Off the top of my head I'd suggest using a "fedora-changes" (?) project on
pagure with folders for different fedora releases.
- Edit history is accessible through git
- Changes can be submitted and updated with pull requests
- Postponing a change is as simple as moving a text file from one folder to
another
- Rejected or discarded changes can be archived in another folder
(Just thinking out loud here.)
Fabio
> From my point of view, those are the most critical ones. The history is
> good
> when you want to see if/how things changed - to learn from specific changes
> which went well or really bad. Not having a history to base it on makes
> this
> learning somewhat more difficult - as you don't know exactly how a change
> proposal did develop, just the final result.
>
> Also having changes represented in three different repos sounds a bit too
> bureaucratic to me. Processes are good to have, but in the moment they get
> too complicated people will generally try to avoid them. If it is really
> needed to involve three repos, then a decent tooling on top of it is
> needed at
> launch time; to hide this bureaucratic process a bit.
>
> Other than that, I think this idea makes perfect sense. The first time I
> did
> a change proposal (not even system-wide), it felt like an odd process ("Is
> this the right template? In a wiki? Have I filled out all the proper fields
> correctly? How is this proposal picked up and distributed properly?" are
> some
> of the thousands questions which popped up).
>
>
> --
> kind regards,
>
> David Sommerseth
>
> ___
> 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/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
>
___
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/R5H22KIXOWYIKUYIRSXZVOZNHINOBVLC/
Re: Idea: let's use Pagure to track Changes
On 23/08/18 22:43, Ben Cotton wrote:
> Hi community,
>
> We've traditionally used the wiki for Change proposals because it's
> the tool we had. But, it's not necessarily well-suited to the purpose.
> But now we have Pagure, which can help address some of the
> shortcomings of using the wiki: poor scriptability, no reporting, and
> a lot of copy/paste.
>
> So I've come up with a plan that would use Pagure instead:
> https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
>
> You can read the full details on the wiki page above, but the general
> idea is that we won't change the policy for Changes, just how we store
> and manipulate them. My intent is to make it nearly seamless for the
> community while giving us a platform for building on the process in
> the future. Note that this would run parallel to Bugzilla for a
> release or two and then replace Bugzilla for Changes tracking.
Even though I'm not as active here as I would like to be, I generally like
this idea.
A few things which would be good to sort out are:
* Still requires changes be represented in three different Pagure repos
* We lose edit history if a change proposal is updated based on feedback
From my point of view, those are the most critical ones. The history is good
when you want to see if/how things changed - to learn from specific changes
which went well or really bad. Not having a history to base it on makes this
learning somewhat more difficult - as you don't know exactly how a change
proposal did develop, just the final result.
Also having changes represented in three different repos sounds a bit too
bureaucratic to me. Processes are good to have, but in the moment they get
too complicated people will generally try to avoid them. If it is really
needed to involve three repos, then a decent tooling on top of it is needed at
launch time; to hide this bureaucratic process a bit.
Other than that, I think this idea makes perfect sense. The first time I did
a change proposal (not even system-wide), it felt like an odd process ("Is
this the right template? In a wiki? Have I filled out all the proper fields
correctly? How is this proposal picked up and distributed properly?" are some
of the thousands questions which popped up).
--
kind regards,
David Sommerseth
signature.asc
Description: OpenPGP digital signature
___
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/JS64TGXC3LBM4XZY2HOSFWL4BHJ5QSYO/
Re: Idea: let's use Pagure to track Changes
Sounds like a great idea to me. I'm in favor... kevin signature.asc Description: OpenPGP digital signature ___ 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/YXHL2P7F6WWHA6RZAROSUH5PFYLOVKLD/
Re: Idea: let's use Pagure to track Changes
Could you please show us example of such change proposal? I somehow cannot imagine the real benefit. V. Dne 23.8.2018 v 22:43 Ben Cotton napsal(a): > Hi community, > > We've traditionally used the wiki for Change proposals because it's > the tool we had. But, it's not necessarily well-suited to the purpose. > But now we have Pagure, which can help address some of the > shortcomings of using the wiki: poor scriptability, no reporting, and > a lot of copy/paste. > > So I've come up with a plan that would use Pagure instead: > https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges > > You can read the full details on the wiki page above, but the general > idea is that we won't change the policy for Changes, just how we store > and manipulate them. My intent is to make it nearly seamless for the > community while giving us a platform for building on the process in > the future. Note that this would run parallel to Bugzilla for a > release or two and then replace Bugzilla for Changes tracking. > > Because we're already moving with changes for Fedora 30 and because a > few Pagure features would make it smoother (primarily allowing issue > submitters to edit metadata), I'd like to implement this for Fedora > 31. Before that, I'd like the community's feedback. > ___ 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/IVURLPA523CQJSONM5MOW2U7KCSWAKNY/
Re: Idea: let's use Pagure to track Changes
On 23.8.2018 22:43, Ben Cotton wrote: Hi community, We've traditionally used the wiki for Change proposals because it's the tool we had. But, it's not necessarily well-suited to the purpose. But now we have Pagure, which can help address some of the shortcomings of using the wiki: poor scriptability, no reporting, and a lot of copy/paste. Good idea! So I've come up with a plan that would use Pagure instead: https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges > 6. FESCo votes on change. On the Pagure ticket with the change or in a separate FESCo Pagure ticket? You can read the full details on the wiki page above, but the general idea is that we won't change the policy for Changes, just how we store and manipulate them. My intent is to make it nearly seamless for the community while giving us a platform for building on the process in the future. Note that this would run parallel to Bugzilla for a release or two and then replace Bugzilla for Changes tracking. The good thing about Bugzilla trackers is that they can be used as... Bugzilla trackers. I mean you can block/depend other bugs on it. See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 and the dependent bugs. Of course, this might be relevant to some kind of Changes only, so the Bugzilla tracker can be optional, but I'd rather keep it as part of the process. Because we're already moving with changes for Fedora 30 and because a few Pagure features would make it smoother (primarily allowing issue submitters to edit metadata), I'd like to implement this for Fedora 31. Before that, I'd like the community's feedback. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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/FQWOCTT4SOFQHWEXUL2G2HEZFTVY4ILA/
Idea: let's use Pagure to track Changes
Hi community, We've traditionally used the wiki for Change proposals because it's the tool we had. But, it's not necessarily well-suited to the purpose. But now we have Pagure, which can help address some of the shortcomings of using the wiki: poor scriptability, no reporting, and a lot of copy/paste. So I've come up with a plan that would use Pagure instead: https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges You can read the full details on the wiki page above, but the general idea is that we won't change the policy for Changes, just how we store and manipulate them. My intent is to make it nearly seamless for the community while giving us a platform for building on the process in the future. Note that this would run parallel to Bugzilla for a release or two and then replace Bugzilla for Changes tracking. Because we're already moving with changes for Fedora 30 and because a few Pagure features would make it smoother (primarily allowing issue submitters to edit metadata), I'd like to implement this for Fedora 31. Before that, I'd like the community's feedback. -- 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/UXKUPP4WYMKZKAWZO66GZIKH5ALTSH77/
