So, it sounds like everybody who weighed in was okay with my proposed approach. Dave suggested an alternate one to consider, and we discussed that a bit (I'm against it), but I did not hear any opposition with the approach I proposed. So, if Dave is okay with it, and there are no other alternatives to consider or objections, I am happy to start doing the conversion work to create the milestones and switch us over to using those.
On Fri, Jul 5, 2024 at 12:35 PM Dominic Garguilo <domgargu...@apache.org> wrote: > > I am also good with the single milestone approach as it seems like the > best solution given the circumstances. > > On Wed, Jul 3, 2024 at 7:09 PM Keith Turner <ke...@deenlo.com> wrote: > > > > Using milestones and selecting the earliest release where an issue will > > land sounds good to me. For planning purposes we generally want to know > > what is the oldest branch a change should land in and milestones work > > perfectly for this. > > > > For retrospective purposes milestones are not perfect, however the issue > > system can never be fully trusted as the source of truth for what is in a > > release anyway. When creating release notes in the past I have looked > > through all the commits since the last release and found notable commits > > that were not properly tagged in the issue system. > > > > 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. > > >
