Right, nothing changes for the projects that are unrelated to release milestones. This discussion and decision was about the release-milestones (the projects that track release versions).
However, once the transition to milestones is done, we could create a milestone for the elasticity work (tentatively, 4.0.0) and the things in the Elasticity project can be marked with that milestone. You'd have the option at that point to remove things from the Elasticity project that are 4.0.0-milestone related, but really "Elasticity" related but merely happened in the elasticity branch (like bumping versions of dependencies, or GitHub Actions changes, etc.). That would be entirely optional, but it could help reduce noise and help keep the Elasticity project focused on elasticity-related work, while still tracking those unrelated changes as targeting 4.0.0. Also, since we still have a couple of legacy projects that are not tracking release milestones, but other things (like the slf4j transition, no-chop merges, etc.), I will review those and probably manually convert them to the new project types, so that they get set up with the correct permissions and things, rather than trust the automated process that GitHub will do later. But those transitions should be relatively simple, and Elasticity is already a new project, not a classic one, so it wouldn't be affected by that. On Wed, Jul 10, 2024 at 2:14 PM Dave Marion <dmario...@gmail.com> wrote: > > 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. > > > > > > >
