Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-assign milestones to merged PR's #2203

Open
iloveeclipse opened this issue Aug 1, 2024 · 4 comments
Open

Auto-assign milestones to merged PR's #2203

iloveeclipse opened this issue Aug 1, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@iloveeclipse
Copy link
Member

iloveeclipse commented Aug 1, 2024

Follow up on eclipse-jdt/eclipse.jdt.core#2627

We should automatically assign milestones to merged PR's to simplify our life tracking which release contained which fix etc.

There are various solutions possible, see list below fro what google found:

This should be done for all eclipse SDK projects (Platform, JDT, PDE, Equinox).

Note, differently to Platform, JDT has BETA_JAVA23 milestone that should be excluded from the "automated" process.

Beside this I believe all projects should be very similar in what milestones we have, as they are created from a job during release preparation process AFAIK.

@HannesWell, @laeubi : you seem to have some experience in the github actions area, I would really appreciate if you could help here.

@iloveeclipse iloveeclipse added the enhancement New feature or request label Aug 1, 2024
@HannesWell
Copy link
Member

Sounds good and is probably not too difficult to implement (haven't looked into the examples yet).
I can try to help with that next week (I'm away over the weekend).

@laeubi
Copy link
Contributor

laeubi commented Aug 2, 2024

For Tycho I use is:pr is:merged no:milestone and then batch assign milestones or is:issue no:milestone is:closed.

We should automatically assign milestones to merged PR's to simplify our life tracking which release contained which fix etc.

Github also allows to see what has changed when one creates a release and can generate a list or one can generate it form the Tags created in a repository.

Beside that assigning a milestone to a closed PR is somewhat useless, a Milestones main purpose is to track what works needs to be done (or is planned) see for example https://github.com/eclipse-tycho/tycho/milestones but from my experience no one is really doing such planning, but your BETA_23 is a good example, if there is work that needs to be done until one can declare "finish" of 23 support then a milestone (e.g. Java 23 Support) would be a good choice to let people know what is left.

@iloveeclipse
Copy link
Member Author

Beside that assigning a milestone to a closed PR is somewhat useless

There are JDT & platform committers that don't think so, me including. Also looking on the links, there are projects like theia which are also doing this, so it seem to be not useless also for other projects.

I have almost daily task to identify whether some fix or feature or bug exists / doesn't exit in a specific release. Currently this means to lookup commit in a repo, scroll up/down the history to see in which release / milestone it is included. It is tedious and wastes my time.

Milestones main purpose is to track what works needs to be done

Sure, it is one purpose, and important one. Unfortunately it is hard to "enforce" every contributor to follow every good practice, and people also do mistakes. Since this is a different topic, if you are interested, please open a discussion thread for the planning /milestones use etc.

Let's keep discussion on this ticket focused on the one concrete use case - automatically track which PR is included in which milestone.

@BeckerWdf
Copy link
Contributor

Beside that assigning a milestone to a closed PR is somewhat useless

There are JDT & platform committers that don't think so, me including. Also looking on the links, there are projects like theia which are also doing this, so it seem to be not useless also for other projects.

I have almost daily task to identify whether some fix or feature or bug exists / doesn't exit in a specific release. Currently this means to lookup commit in a repo, scroll up/down the history to see in which release / milestone it is included. It is tedious and wastes my time.

Milestones main purpose is to track what works needs to be done

Sure, it is one purpose, and important one. Unfortunately it is hard to "enforce" every contributor to follow every good practice, and people also do mistakes. Since this is a different topic, if you are interested, please open a discussion thread for the planning /milestones use etc.

Let's keep discussion on this ticket focused on the one concrete use case - automatically track which PR is included in which milestone.

I agree with Andrey. Milestone can be used in two use-cases. Planning (when do want to deliver that PR) and book-keeping (in which release this change was made).

Setting the milestone (if not yet done) after merging sounds reasonable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants