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

Reply via email to