Skip to main content
[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

IMPORTANT When will this poll be over?
@Sun please make clear until when people are able to answer before you close the poll. I have some bad memories :-)
 
 Haha :) will do if we start a poll, but I don't feel like swimming in the pool now :p

Is that about the roadmap or the release notes?
What's the problem we want to solve? Find out issues included in future releases (roadmap) OR issues fixed in a past release (release notes)? Because both are important but the solution will differ.

For the roadmap we don't have other choices than using issues and I am +1 to use milestones (point n.2) and on one unique repository (eclipse/che).

For building release notes I agree with Thomas that we should use PRs (or even commits) and a script that retrieves commits included in a release from different repos and publish it in the GH release page. That's the only way to be sure that we include everything without the need to enforce one issue per PR rule. Deploy team has been using conventional commits for chectl that help setting a convention on commit messages and I am curious about their feedback.

It is to have release notes that are tracked by GH. It could be PR, but also 1 issue that would consist of PR in different repos (theia, che-theia, che-server, etc ...)
I am OK to have it automated, but what if we want to tell the users that a Che release includes a fix in upstream Theia? or would we also include all the PR in Theia? that works for me.

Now we don't have that automated ... and we don't know how much time it will take to do that. So I am +1 to manually add a PR/issue to the `kind/release` notes that should work without too much pain starting tomorrow. And we can create an epic for the mid/long road to make it automated. WDYT?
 
On Tue, Jul 21, 2020 at 2:39 PM Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:

What is the z-stream process?
How do I nominate a PR/issue for z-stream?
How does it get approved?
Do you require a separate PR for the branch?
Is it a rare occasion enough that just adding a z-stream tag to a PR is enough ?
--
Gorkem

On Tue, Jul 21, 2020 at 8:03 AM Thomas Mäder <tmader@xxxxxxxxxx> wrote:

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.


On Tue, Jul 21, 2020 at 10:27 AM Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:
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&noteworthy 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.




On Tue, Jul 21, 2020 at 2:50 AM Michal Vala <mvala@xxxxxxxxxx> wrote:
+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
_______________________________________________
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

Back to the top