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
Been thinking ... a list of PR is not interesting for the end user:
What user is interested in is, for instance, if he will be able to mount secrets into a che workspace in 7.16.0 ... not the 3 or 4 PR that are dispatched in different repos ... where is the documentation if any? etc ... So a GH issue for a new feature. a PR for a fix is ok. I don't know how that could be automated, it is something humans (the dev or product owner) that needs to tell another human (the end user) what a release would include.
It may be interesting to have something like what is in the Eclipse Desktop IDE: the news and noteworthy page. For instance, https://www.eclipse.org/eclipse/news/4.12/jdt.php

Sun Tan

Senior Software Engineer

Eclipse Che - CodeReady Workspaces @ Red Hat

also Paris JUG Leader

Red Hat Paris

sutan@xxxxxxxxxx    
M: +33621024173    




On Wed, Jul 22, 2020 at 10:30 PM Sun Tan <sutan@xxxxxxxxxx> wrote:

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?

Without pain for you, who is the consumer, not producer of these issues, I might add ;-) But on a serious note: let's not add more manual process to creating a release: we're trying to make it as automated as possible. If we think having these "release notes" is important, let's invest in the technology to do it right and let's invest now.

I don't know why you call it "pain" but for once I had finished ... It took me less than 30 sec and 2% of my brain CPU to add my PR to the description of the release issue: https://github.com/eclipse/che/issues/17436#issue-660695018 as a producer ... Again I am not against automation but I would like that we have an alternative that is not too painful and that works until we have an automated process.

Back to the top