Arctos: How should we release new code?

[Jegelewicz]

I'm not complaining, I'm begging for guidance! How should we release, especially when it's something critical (like what I'm waiting on now)?

add a milestone

That mostly works for me, I already use them heavily, but someone somehow would need to clean them up.

_Originally posted by @dustymc in https://github.com/ArctosDB/arctos/issues/2686#issuecomment-642755432_

[dustymc]

I want to do one of two things:

• change your new milestone to something like 'implemented' so it can work for things that will be in the next release, and also things that I've patched into production and which need tested (which will hopefully be very rare after we get over this initial period of adjustment)

• add another milestone for things like https://github.com/ArctosDB/arctos/issues/2768, where I just patched a function back into production.

I sorta want (1) because its simpler and direct patches should be rare, but (2) is perhaps more explicit. Thoughts?

[campmlc]

"implemented in production for next release" "implemented in test, requires
testing"?

On Thu, Jun 11, 2020 at 10:16 AM dustymc [e-mail] wrote:

• [EXTERNAL]*

I want to do one of two things:

-

change your new milestone to something like 'implemented' so it can
work for things that will be in the next release, and also things that I've
patched into production and which need tested (which will hopefully be very
rare after we get over this initial period of adjustment)
-

add another milestone for things like #2768
https://github.com/ArctosDB/arctos/issues/2768, where I just patched
a function back into production.

I sorta want (1) because its simpler and direct patches should be rare,
but (2) is perhaps more explicit. Thoughts?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2769#issuecomment-642783353,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBC23LH3VMRXEAEZ2LLRWD7OBANCNFSM4N3REN2A
.

[Jegelewicz]

1. "implemented in test, next release"
2. "implemented in production"

Also suggest we add "implemented in test, requires testing" because we will need that too.

[dustymc]

"implemented in test, requires testing"

ALL "implemented in test," should be tested. At best, I'm maybe-sorta-decent at predicting what's going to cause problems.

[Jegelewicz]

But once we have tested, "implemented in test, next release" seems appropriate....

[Jegelewicz]

Like, we have tested and think it's good to go.

[dustymc]

Ah - that's "correct" but I'm not sure how realistic it is. We don't have a QA team, most things just don't get much testing, except by me. Even when we had a dedicated QA stack that just never happened - eventually things would pile up enough I'd be forced to push QA to prod so I could reset something in test. Given our resources, I think the cycle is

• implemented in test and available for testing
• nobody complained, push to prod

If we inject a 'tested in test' requirement in there, I suspect we'll just never get anything back out of test.

[Jegelewicz]

Well, we could change and with a little help from a facilitator (me), we can try to encourage testing of stuff that we know needs testing in test.

[campmlc]

Yes, part of our problem had been a way to flag things that need testing
and clearly explain what needs to be done.

On Fri, Jun 12, 2020, 10:50 AM Teresa Mayfield-Meyer <
[email protected]> wrote:

• [EXTERNAL]*

Well, we could change and with a little help from a facilitator (me), we
can try to encourage testing of stuff that we know needs testing in test.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2769#issuecomment-643379933,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBC2SN56KJYGE2JIBRTRWJMERANCNFSM4N3REN2A
.

[dustymc]

OK, I'll try to remember to add a short description of what I've done and what I think it might break when I use the new milestone.

[dustymc]

See https://github.com/ArctosDB/arctos/issues/2776

There was a minor (but important) fix - what should we do? Eg should we push lots of small patches out, wait for some accumulation and periodically push bigger groups out, ????

[campmlc]

If these are priority critical and impeding work, push out in smaller
batches. Save less critical for less frequent?

On Fri, Jun 12, 2020, 1:17 PM dustymc [e-mail] wrote:

• [EXTERNAL]*

See #2776 https://github.com/ArctosDB/arctos/issues/2776

There was a minor (but important) fix - what should we do? Eg should we
push lots of small patches out, wait for some accumulation and periodically
push bigger groups out, ????

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2769#issuecomment-643442402,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBALBTVDIC4LJHWRJDTRWJ5KXANCNFSM4N3REN2A
.

[dustymc]

I stripped the scary/stupid parts out of production, so the fix is more like "show me what's wrong instead of just throwing errors" at this point.

I think I'm generally in favor of smaller, more-frequent releases, but that usually doesn't matter too much from here either.

I should probably add an intended version number to my "In next release" notes as well.

[campmlc]

We should also let folks know what the actual time frame is "for next
release". For priority critical, same day functionality would be nice,
when possible. Regardless, saying "within an hour, within 24 hrs", "after
next AWG meeting" helps people plan their tasks and workflow.

On Fri, Jun 12, 2020 at 1:32 PM dustymc [e-mail] wrote:

• [EXTERNAL]*

I stripped the scary/stupid parts out of production, so the fix is more
like "show me what's wrong instead of just throwing errors" at this point.

I think I'm generally in favor of smaller, more-frequent releases, but
that usually doesn't matter too much from here either.

I should probably add an intended version number to my "In next release"
notes as well.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2769#issuecomment-643448996,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBBECZJKR6IMEU5SECLRWJ7F7ANCNFSM4N3REN2A
.

[mkoo]

I like this discussion. We already have 12 milestones, a few sorta fit the proposed ones.
In next release
could be renamed "Implemented in Test, next release"

It sounds like a new milestone of "In Development for immediate release" or something like that for priority bugs and other critical functions

The others we could clean up (eg. Wont Fix and Abandoned seemed the same to me and should be the one bin) Two milestones have never been used and should be trashed as well.

Clean up?

[dustymc]

Wont Fix and Abandoned seemed the same

Wont Fix==this doesn't make sense to me, I don't think I can do anything about it

Abandoned==this has been around a while, does anyone still care?

Clean up?

Yes! Maybe start by adding all no-milestone issues to Abandoned?

[dustymc]

I use three milestones

• next task==I think I know how to do this
• active development==I'm working on this
• in next release==it's implemented in test, and testing is appreciated

I'm not sure how "in next release" get closed - I get them when I see them, I think @Jegelewicz has some magic but not sure.

I only incidentally see anything without a "next task" milestone - I try to keep up, but also need Community help in moving things to that stage.

I will try to comment when I change milestones; changing milestone alone does not send notifications.

[dustymc]

Can/should we adopt some/all of https://www.tdwg.org/standards/vms/?