I think you are proposing a single "2.1.3" issue, for example, whose body somewhere (top comment, perhaps) is manually updated as one big massive list of links to all the issues/PRs for that release? That sounds like a nightmare to maintain, impossible to enforce consistent use, and extremely unlikely to ever be audited/reviewed for accuracy. I'm not even sure it'd be very good for triage... although everything would be in one place, I think GitHub collapses long posts and we'd have to expand it to see what is still on the list.
Even if it were done perfectly by every developer every time (very unlikely), it still sounds like more work than dealing with the limitations of the single milestone feature to me.... more similar to the days when there was a manual CHANGELOG to keep up to date. I'd much prefer to occasionally have to read the comments for an issue, or cross-reference the release schedule, or answer the occasional user question about "hey, was this fixed in X version?" than deal with manually updating one or more massive lists every time any issue is updated with milestone information. Am I thinking about this wrong and it's not as bad as I imagine? That said, I do think that using checklists in an issue can help some narrow situations, like when you want to relate several PRs for different branch implementations for the same bugfix, or if you have a few related sub-tasks but creating a new Project would be overkill. I just don't think it's a great option for milestone tracking. On Wed, Jul 3, 2024 at 2:15 PM Dave Marion <dmario...@gmail.com> wrote: > > Another option would be to do it manually by creating an issue where the > top comment is a checklist of all the related items in that release. Much > like the post-vote release checklist[1] issues that we have. Yes, this > means that the developer is going to have to update some other number of > tickets when creating a ticket or PR. But, I think it might give us back > the functionality that we had. > > [1] https://github.com/apache/accumulo/issues/3714 > > On Wed, Jul 3, 2024 at 12:21 PM Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > > > No objections from me, I am +1 for going with the single milestone approach > > as it seems like the best way for now unless Github makes improvements. > > > > On Tue, Jul 2, 2024 at 7:05 PM Christopher <ctubb...@apache.org> wrote: > > > > > Hi Accumulo Devs, > > > > > > I wanted to bring to everybody's attention that GitHub is sunsetting > > > their classic "Projects" interfaces and will very soon forcibly > > > migrate all of them to the new Projects. See > > > https://github.blog/changelog/2024-05-23-sunset-notice-projects-classic/ > > > > > > There are two ways we use projects: > > > > > > 1. To track groups of related topics under a single theme of effort, and > > > 2. Basic milestone tracking ("fix versions") > > > > > > For the first use, the new projects will still be suitable, though > > > they behave differently, with some key differences that we all need to > > > be aware of. We've already been using two of them, named "Accumulo > > > Elasticity" and "Accumulo Observability". > > > > > > For the second use, the new projects are a huge hassle and very > > > bloated for what we need. What we need here is very basic milestone > > > tracking. In JIRA, we had the "fixVersion" field, in which you could > > > specify multiple versions in which we released a fix for a given > > > issue. In GitHub, we have "milestones". However, GitHub will only let > > > you specify a single milestone. So, it's harder to specify something > > > complex, like "this bug is fixed in versions 2.1.1 and 3.0.5" like we > > > could easily do in JIRA. As a workaround, we considered using labels. > > > However, labels have the problem of being around forever... and it's > > > very hard to manage them (closing ones that are old) because all you > > > can do is delete them (which removes the label from every issue it was > > > on). Labels are suitable for a discrete set of states like "blocker" > > > or "critical" or "question" or "wontfix" or "good first issue", but > > > not for things like versions, where new ones are constantly created > > > and old ones need to be archived. So, we had been using the "classic" > > > GitHub Projects for this. However, the recent change forces us to > > > reconsider this use case. > > > > > > Here's a couple of things to consider about new projects and how they > > > differ from the classic ones: > > > > > > 1. New projects are scoped to the GitHub organization > > > (github.com/orgs/apache) not to an individual project > > > (github.com/apache/accumulo) like classic projects. This is convenient > > > for the first use case (because they can track issues across repos), > > > but are not desired for milestone tracking for a single repo. > > > 2. New projects use a common namespace. Our current projects use > > > versions like "2.1.3" and "3.1.0". We would have to change all of them > > > to "Accumulo 2.1.3" or "accumulo-2.1.3" to not get lost in the larger > > > common namespace. > > > 3. New projects have complex permissions that we need to make sure we > > > set properly. These permissions depend heavily on ASF's INFRA team > > > maintaining per-project committers (sync'd with LDAP) or rely on us to > > > actively maintain permissions on every project. For example, when a > > > new project is created, we have to make sure it is set to "Public" > > > instead of "Private" which is the default, set the default permissions > > > from "Write" to "Read", and then add the "accumulo-committers" team > > > (which INFRA should be keeping synched to LDAP and GitBox) to the > > > project with "Admin" permissions, so all the committers can share in > > > its maintenance (by default, only the user that created it has > > > "Admin"). When I looked today, none of our projects had these set > > > correctly (though I have requested their creators fix them, so they > > > should be good soon). If any of these permissions are set improperly, > > > then users will not be able to see the projects labeled on issues, or > > > will have too much permission and will be able to make changes that > > > interfere with our community's project planning. > > > 4. New projects must be manually "linked" to the repository to be > > > easily found when tagging issues, or in one's personal "Recent" list. > > > If they aren't and you can't remember the name, you have to scroll > > > through hundreds of projects in the organization to find it (assuming > > > you have permission to see it, which regular users and outside > > > contributors would not have). > > > > > > Milestones still have the limitation of being able to have only one, > > > but this could be mitigated by having a consistent way we use them. > > > For example, for something like "fixed in versions 2.1.3 and 3.1.0", > > > we could just set 2.1.3 as the milestone, and users can infer that any > > > version released chronologically after that would include the fix. > > > Alternatively, we could create separate tickets for backporting, like > > > label issue number 1234 as "fixed in 3.1.0" with a milestone of 3.1.0, > > > but then create a new issue that says "Backport #1234 to 2.1" and has > > > a milestone of "2.1.3". However, my concern about that is the bloating > > > of redundant tickets, which makes it hard to follow the lifecycle of > > > an issue. I think simply marking the oldest fixed version and > > > inferring the newer releases is the better way to go. However, that > > > does have two downsides: > > > > > > 1. You might need to cross-reference release dates to see if a fix in > > > 2.1.3 was in 3.1.0, for example, because you're not sure if 3.1.0 was > > > released before or after 2.1.3, and > > > 2. There may be some special situations where a fix version didn't > > > apply to a newer branch, was not merged to it because a different fix > > > was required in the newer branch, was reverted in the newer branch, or > > > the timeline doesn't match up because voting took longer for the older > > > branch, or some other special circumstance. > > > > > > I think that neither of these two are substantial concerns, though. I > > > think they can be clarified via the comments in the issues/PRs, if it > > > comes up. > > > > > > So, my proposal would be to switch to using single milestones. We can > > > mark the oldest milestone that a fix is applied to. If we backport to > > > an earlier branch without creating a new issue, we can just update the > > > milestone to the older version. If a new issue is created, we can > > > leave the original milestone alone, and describe the new issue/PR as a > > > backport and put the milestone appropriate for the backport. If there > > > are any special circumstances, we can just describe them in the > > > comments. > > > > > > > > > In August, the classic projects will all be forcibly migrated to the > > > new projects. I'm not sure about the details of what happens if > > > there's a name collision, or what happens to closed projects, or if > > > only open projects will be migrated. I'm also not sure what > > > permissions will be set on the new projects for the migration. So, > > > there's a lot of unknowns. What I would like to do is make a decision > > > quickly to use milestones as I've described above, and then I can > > > manually go in and convert our existing projects over to using > > > milestones and update the links in the website. Once that is done, I > > > can manually convert any old projects that were not milestone > > > tracking, but instead correspond to the first use case I described > > > above. For those, I'll make sure they have a name starting with > > > "Accumulo" so they can be easily found, make sure they are linked to > > > our repo, and have the proper permissions on them. I would prefer not > > > to rely on the automatic migration from classic to new projects > > > because there are too many unknowns and too many things can go wrong. > > > > > > So, are there any objections to going with the single milestone > > > approach I've described? > > > Or perhaps you feel strongly that the new projects *are* best for > > > milestone tracking (I really hope not, because I'm really strongly > > > against using them for this)? > > > Or perhaps there's a better suggestion? > > > (Or best yet, do you know somebody at GitHub who can implement > > > multiple milestones prior to the sunsetting of the classic projects? > > > *long-shot*) > > > > > > Thanks for your attention to this issue, > > > > > > Christopher > > > > > > P.S. We are already unable to create any new classic projects, since > > > GitHub already disabled that. So, once 2.1.3 is released, we're going > > > to need to have a decision made so we can track the 2.1.4 tickets that > > > got bumped off 2.1.3. We can always do something temporary in the > > > meantime (using a label, milestone, or new project), if we have to, > > > but I'd prefer to make a decision than stick to temporary workarounds > > > without one. > > > > >
