| Re: [che-dev] How we track issues/PR that are part of a release |
A couple of things:
*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 :-)
*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
<https://www.conventionalcommits.org/en/v1.0.0/> for chectl that help
setting a convention on commit messages and I am curious about their
feedback.
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¬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