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
_______________________________________________