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 (tenta
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 wrote:
> So, it sounds like everybody who weighed in was okay with my proposed
> approach. Dave suggested an alternate one to cons
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
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 wrote:
>
> Using milestones and selecting the earliest release where an issue will
> land sounds good to me. For planning purposes we generall
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
On Wed, Jul 3, 2024 at 5:37 PM Dave Marion wrote:
>
> Comments inline.
>
> On Wed, Jul 3, 2024 at 4:33 PM Christopher wrote:
>
> > I think you are proposing a single "2.1.3" issue, for example, whose
> > body somewhere (top comment, perhaps) is manually updated as one big
> > massive list of link
Comments inline.
On Wed, Jul 3, 2024 at 4:33 PM Christopher wrote:
> I think you are proposing a single "2.1.3" issue, for example, whose
> body somewhere (top comment, perhaps) is manually updated as one big
> massive list of links to all the issues/PRs for that release?
Yes, although I'm not
I think you are proposing a single "2.1.3" issue, for example, whose
body somewhere (top comment, perhaps) is manually updated as one big
massive list of links to all the issues/PRs for that release? That
sounds like a nightmare to maintain, impossible to enforce consistent
use, and extremely unlik
Another option would be to do it manually by creating an issue where the
top comment is a checklist of all the related items in that release. Much
like the post-vote release checklist[1] issues that we have. Yes, this
means that the developer is going to have to update some other number of
tickets
No objections from me, I am +1 for going with the single milestone approach
as it seems like the best way for now unless Github makes improvements.
On Tue, Jul 2, 2024 at 7:05 PM Christopher wrote:
> Hi Accumulo Devs,
>
> I wanted to bring to everybody's attention that GitHub is sunsetting
> the
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 pr
11 matches
Mail list logo
