Starting to create Github issues on a Jackson projects for minor/patch releases?
9 views
Skip to first unread message
Tatu Saloranta
May 3, 2020, 2:06:15 PM5/3/20
to jacks...@googlegroups.com
Since there are multiple projects where I am not the active lead
developer (most notably Scala and Kotlin modules), I think that it
might be time to "mature" release process slightly. Specifically,
although I can take care of almost all publishing activities (with
exception of Scala module, possible), I think I need to coordinate
timing little bit better, to make sure there is clean cut-off point
wrt merging of features, updates of dependencies and so on.
While there are many other things that would be great to improve on
(like more automation), this seems like a relatively low-hanging
fruit.
What seems like a simple incremental step would be for me to create a
Github issue for every new release, adding ccs to maintainers, and
wait for some pre-determined time for confirmations/notes from
maintainers.
Only after time has elapsed (or everyone/quorum has +1'd release?) and
no other issues related to the new release have been raised, would I
proceed with publishing.
Does this make sense? Idea is simply to raise awareness, allow
contributors and maintainers to point out possible gaps, dependencies,
but without building significant new processes.
If so, another question is the location. I was first thinking of main
`jackson` repo, but it does not have Issues enabled -- and the reason
is that that tracker, if enabled, tends to get all kinds of misc
assorted issues filed (somewhat understandably, but from practical
standpoint leading unproductive and undesired janitorial work).
Thinking more along these lines, maybe I should simply create a new
repo, `jackson-releases` (or something)? In theory that could even
hold wiki page for releases, but I am not sure it would make sense as
many other links from outside would need to be redirected.
Pointers to how other projects do this might be useful as well; as
well as experiences. So far releases have been a solo effort, and
while I think centralized model has its benefits I would like to open
it up a little bit.
-+ Tatu +-
developer (most notably Scala and Kotlin modules), I think that it
might be time to "mature" release process slightly. Specifically,
although I can take care of almost all publishing activities (with
exception of Scala module, possible), I think I need to coordinate
timing little bit better, to make sure there is clean cut-off point
wrt merging of features, updates of dependencies and so on.
While there are many other things that would be great to improve on
(like more automation), this seems like a relatively low-hanging
fruit.
What seems like a simple incremental step would be for me to create a
Github issue for every new release, adding ccs to maintainers, and
wait for some pre-determined time for confirmations/notes from
maintainers.
Only after time has elapsed (or everyone/quorum has +1'd release?) and
no other issues related to the new release have been raised, would I
proceed with publishing.
Does this make sense? Idea is simply to raise awareness, allow
contributors and maintainers to point out possible gaps, dependencies,
but without building significant new processes.
If so, another question is the location. I was first thinking of main
`jackson` repo, but it does not have Issues enabled -- and the reason
is that that tracker, if enabled, tends to get all kinds of misc
assorted issues filed (somewhat understandably, but from practical
standpoint leading unproductive and undesired janitorial work).
Thinking more along these lines, maybe I should simply create a new
repo, `jackson-releases` (or something)? In theory that could even
hold wiki page for releases, but I am not sure it would make sense as
many other links from outside would need to be redirected.
Pointers to how other projects do this might be useful as well; as
well as experiences. So far releases have been a solo effort, and
while I think centralized model has its benefits I would like to open
it up a little bit.
-+ Tatu +-
Drew Stephens
May 6, 2020, 10:32:55 AM5/6/20
to jackson-dev
I think this would be very good—it seems totally reasonable for
sub-project maintainers to get releases all prepped so you can just
pop in and execute.
Issues on the main Jackson project fit well, but I hear your concerns
about that attracting unwanted questions. GitHub offers the ability to
those limits are intended for short-term use and expire after 24 hours.
A cron job and the API could fix that, but that might be confusing for
people looking to file issues (though, perhaps that's just the push they
need to find the right sub-project).
-Drew
Tatu Saloranta
May 6, 2020, 3:23:15 PM5/6/20
to jacks...@googlegroups.com
On Wed, May 6, 2020 at 7:32 AM Drew Stephens <drewgs...@gmail.com> wrote:
>
> I think this would be very good—it seems totally reasonable for
> sub-project maintainers to get releases all prepped so you can just
> pop in and execute.
>
> Issues on the main Jackson project fit well, but I hear your concerns
> about that attracting unwanted questions. GitHub offers the ability to
> limit interactions with the repository to contributors or maintainers, but
> those limits are intended for short-term use and expire after 24 hours.
> A cron job and the API could fix that, but that might be confusing for
> people looking to file issues (though, perhaps that's just the push they
> need to find the right sub-project).
Interesting.
>
> I think this would be very good—it seems totally reasonable for
> sub-project maintainers to get releases all prepped so you can just
> pop in and execute.
>
> Issues on the main Jackson project fit well, but I hear your concerns
> about that attracting unwanted questions. GitHub offers the ability to
> limit interactions with the repository to contributors or maintainers, but
> those limits are intended for short-term use and expire after 24 hours.
> A cron job and the API could fix that, but that might be confusing for
> people looking to file issues (though, perhaps that's just the push they
> need to find the right sub-project).
Another possible repo to use could be:
https://github.com/FasterXML/jackson-future-ideas/
where I maintain my public TODO list
(https://github.com/FasterXML/jackson-future-ideas/wiki/Jackson-Work-in-Progress)
It has issue tracker, but one with modest volume. It seems like it
could be a reasonable fit.
But of course repositories are dime a dozen so could also just create
a completely new one.
How do others feel about this one? While not a big deal, we might try
to get this as functional as possible upfront.
-+ Tatu +-
> You received this message because you are subscribed to the Google Groups "jackson-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/867147c3-290d-4cb5-9745-a8970ebc2f57%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages