[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [che-dev] How we track issues/PR that are part of a release
|
I think it would make sense to track PR's, not issues for the
finding out what's in a release. That way there would be a unique
item for every release and work item. We could even automate this
without setting an explicit milestone: if we can track all the
PR's merged into a particular branch between the last release (tag
on the branch) and the current one, we'd be home free.
The question then remains how to find the issue related to the
PR, but I'm sure we can find a way to do that, maybe block PR's
from being merged if we can't determine a corresponding issue.
/Thomas
On 21/07/2020 10:38, Florent Benoit
wrote:
Hi Gorkem,
How do you solve the issue on .Z stream releases ?
Because on github, issues can't have more than one
milestone.
Let's say, how do you know which issue is fixed in 7.16.1
?
Are you using PR everywhere ? (no cherry-pick to a branch
without a PR) ? because for now I'm not sure I'm seeing PR
everywhere for backport branches.
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
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev