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