You can automate reports if you have structured metadata , if your metadata is trapped inside an issue's markdown it is almost impossible to do anything meaningful with it.
Option 1 is a manual process that will be likely to be neglected and even if it is not neglected the data is not usable for anything else.
I like option 2 because as long as data is there and structured I can create reports that span multiple repos.
Here is a demo [1] of how I follow up with the Eclipse Che project today. Notice that I aggregate PRs from 3 repos on the Open Pull
Requests section of my notebook (there are 53 by the way). You can also see that the report can
be easily used for generating new¬eworthy by combining the milestones with n&n label.
And it is possible to do more as long as data exists. I have for instance another notebook that helps me to follow devfile progress
on odo, che and devfile repos in one place.
I am using this gh notebook vscode extension [2] for this. Once the notebook APIs are available, we will be able to run it with Che as well.
I can send a PR to share the notebook I am using with the repository as well.
+1 for 1.
Github issue tracker is not variable and customizable enough to,
somehow nicely, support the release process of our complexity. So
labels everywhere
https://meme-generator.com/mememe/labels-labels-everywhere/. It is
manual work, hard to maintain and prone to errors, but IMHO it still
works the best on github.
On Mon, Jul 20, 2020 at 8:58 PM Eric Williams <ericwill@xxxxxxxxxx> wrote:
>
> On 7/20/20 12:24 PM, Sun Tan wrote:
> > Hi all,
> > We started to discuss how we could properly track releases. For a user,
> > it would be interested to know in which release(s) a particular issue is
> > part of. Or know what is the content of a release.
> >
> > Here are the proposals:
> >
> > 1. Label `kind/release`, issues like
> > https://github.com/eclipse/che/issues/17428 or
> > https://github.com/eclipse/che/issues/17436.
> > Pros: easier to edit and comment about issues. No need to milestone
> > z-stream release. Cross repo issue or PR friendly.
> > Cons: Would need contributors to manually add issues/PRs to a release issue.
> >
> > 2. Milestones
> > Pros: one way to mark issues when planning or releasing.
> > Cons: may not be available in all the repos (Theia, etc ....), would
> > need to add z-stream release as a milestone. Cannot set 2 milestones for
> > a release. Not possible to track PR through all the repos.
> >
> > 3. use the release tab in github. https://github.com/eclipse/che/releases
> > Pros: available in che github main page.
> > Cons: hard to search and track for issues/PR related
> >
> > AFAIC: +1 for 1.
>
> +1 for option 1), it works best with issues and PR's, in the event that
> the PR doesn't have a corresponding issue.
>
>
> Eric
>
> _______________________________________________
> che-dev mailing list
> che-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
--
Michal Vala
Software Engineer, Eclipse Che
Red Hat Czech
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
