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. > > >
