Fine by me, however I'm assuming that the Elasticity project (new) will remain as-is for now, right? Thanks Christopher.
On Wed, Jul 10, 2024 at 12:14 PM Christopher <ctubb...@apache.org> wrote: > 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. > > > > >
