Check for milestone and change log connection #19596
Comments
|
I like the idea of having the milestones giving a clearer roadmap, but TBF I don't think we have the resources to promise (or even suggest) anything about when PRs will get merged. We currently don't make setting milestones mandatory, and yet just prior to every release, a significant number of milestoned PRs get re-milestoned (i.e. postponed) because we don't have the bandwidth to merge them on time. Some PRs have been re-milestoned for years. If we make milestones mandatory, we'll have to re-milestone even more PRs at each release, and this might be impractical IMHO. It would also make the milestone tagging effectively meaningless, as we wouldn't be able to stick to the labels anyway. |
|
@NicolasHug thanks for your answer, you are totally right. I have myself removed from milestones a lot of pull requests, but not remilestoned them, because after postponing four times it is clear that people didn't find the energy to work on them. In my opinion enforcing milestones is a gently push in a direction of defining priorities: if a pull request is milestoned for, let's say, 1.5.2 , I really need it there, I will find a way to make it done, delegating other activities. Often pull requests are in a milestone just because they have been automatically moved before a release, not because someone actually decides to give it priority. For bugfixes, it will help in managing backporting the change log for bugfix releases. Anyway, if people are interested in playing the milestone game this could perhaps help in changing habits and improving the long term point of view, otherwise, this is really just an RFC. :) |
|
I'm not yet convinced by this idea. My comment that is referenced here was
talking about always requiring the latest version's change log to be
updated, except in the case where a milestone has been tagged.
I think this conversation necessarily needs to be framed in terms of "what
are milestones used/useful for". So far we have used them, I think, for the
following purposes:
1. Designate a change as belonging to a bug fix release, i.e. in need of
backport to a previous release branch, and perhaps also blocking that
release. This label also supports change log management.
2. Designate a change as intended for the upcoming release, i.e. you may or
may not want to block on it, but it's seen as a feasible and priority
target for inclusion in that release if possible.
3. Leave a reminder that something should be fixed in the upcoming release,
or the subsequent release if it is not feasible to target for the upcoming
release.
4. Designate an issue as "far off" or backwards incompatible by consigning
it to a major version.
5. Legacy odds and ends that were once added to a milestone for one of the
above reasons or through a different understanding of the use of
milestones, and have since then been remilestoned.
We don't currently use milestones heavily for roadmapping. The main time
they are used is to support releasing by treating the milestone as a check
list for functions 1-3 above.
Making milestones mandatory makes them less useful as a checklist. It might
support change log management better because we can check that changing a
milestone tag is reflected in the change log location. What other purposes
would it serve? What current functions would it hinder?
|
And I'm ok with that but I'm also trying to avoid duplicated entries in the changelog, with the less possible human intervention. I'm not happy with the current behavior of the check, and would like to check all the changelogs and then the last one, if the milestone is not present, to notify if the entry has been duplicated (this already happened in some pull requests opened for a long time). Pushing on that direction I opened this issue to ask if it could be a better idea to directly enforce milestones, as I can directly implement the check on the correspondent changelog rather than the last one.
Thanks for this list: if you don't mind I will add it to the wiki about how to use labels (then milestones ... :) ), because it helps triaging people to better understand how things work in the issue tracker.
I can understand this if the release is a 'lonely single maintainer effort' concentrated in the last month (or week) before the deadline. I personally don't particularly like the 'last minute rush' situations (but I think this is just a matter of taste): in my opinion almost mandatory milestones force to use the checklist during all the ~six months before the release and not only at the end. The release manager will not need to recheck all PRs badly milestoned just before the release because the effort has been diluted by all the maintainers during the previous months ... perhaps it asks for some trust in other people work ... You will tell me that the release manager will do it anyway and you are right: I hope it will take less time, as critical decisions would already be taken.
From my naive point of view,
|
Uh oh!
There was an error while loading. Please reload this page.
Follow-up of @jnothman comment.
I would like to propose to enforce milestones in pull requests.
That means:
I believe it is helpful in anticipating breaking changes, and could give a more long-term vision on the library developments. It is also helpful for contributors, as they will have a better understanding of how much their pull request is awaited.
This approach is used for example by the Astropy project: no milestoned pull requests will still have their place anyway, they are long term feature implementations or code reformatting.
The text was updated successfully, but these errors were encountered: