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 <https://help.github.com/en/github/building-a-strong-community/limiting-interactions-in-your-organization>, but those limits are intended for short-term use and expire after 24 hours. A cron job and the API <https://developer.github.com/v3/interactions/repos/> 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 On Sunday, May 3, 2020 at 2:06:15 PM UTC-4, Tatu Saloranta wrote: > > 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 +- > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/867147c3-290d-4cb5-9745-a8970ebc2f57%40googlegroups.com.
