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.
