On Wed, Jul 3, 2024 at 5:37 PM Dave Marion <dmario...@gmail.com> wrote: > > Comments inline. > > On Wed, Jul 3, 2024 at 4:33 PM Christopher <ctubb...@apache.org> wrote: > > > 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? > > > Yes, although I'm not proposing it's a great solution, just that it's an > alternate one > that may not have been considered. It gets us the same functionality that > we have > today with a little more work. >
I definitely didn't consider this option before, so thank you for suggesting it. I think I just see the amount of work here being a lot more than "a little", and wouldn't want to do it. > > > 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. > > > > I agree it's not ideal. I think the triage that would need to happen would > be about the > same as happens today for the issues and PRs that don't get assigned to a > milestone. > > > > 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. > > > It might be a little more work than remembering to select the projects > associated > with an issue or PR. But, it's not an obscene amount of more work. > > > > 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? > > > > It's a little more work that everyone would need to do for their issues and > PRs. > Just like remembering to assign the milestones that we do today. When they > are missed, someone has to go back and clean them all up. Speaking as somebody who often does this (and tries to remind others to do it), I can say that this isn't actually that much work... it's usually just: glance at the ticket and select from the drop-down. GitHub's search features make it very easy to go back and find unmarked issues, but usually, I just review all new issues that have had any activity, and glance to the right column to see if it's been marked. It's actually very easy. I think that it would be a lot more work compared to what I do now to triage and clean up after what was missed. I'd have to find the issue first to get the number, then I'd have to edit the checklist in markdown. That feels like at least an order of magnitude more difficult than what I do now by itself. Plus, there's no tooling to easily search any missed ones. You'd have to expand the collapsed comment and do a Ctrl+F search in your browser to see if each item is listed. But before you do that, you have to know all the ticket numbers you're looking for, because you won't be able to just search for "all tickets without a milestone" like you could today. I appreciate the suggestion for doing things in a way I hadn't considered, but I really would not want to do any of this. > > > > 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. > > > > > > > > > > >
