Release cadence discussion

saysjonathan commented 7 years ago

It been almost 2 months since the last release and there are numerous additions that would be useful to the entire community. Can we get a 1.9.6 release?

cwgem commented 7 years ago

To add on to this, I think the larger issue is that the release process is very code freeze centric, with issues being tagged for release. Unfortunately there only appears to be a single individual that is tied to code review, merges, issue triage, etc. As a pretty heavy user of the project this is concerning. I want to continue work with the AWS batch pull request, but seeing the overall activity it just pulls my motivation away from contributing. That said:

Who are considered maintainers of this project? Is it really only one person?
Is there some kind of best time of day to have folks get together and help out, where pull request reviews etc. can be done in a more dedicated fashion?
How do we got a hold of project members for questions, as the Google Group seems kind of dead?

saysjonathan commented 7 years ago

I would agree with @cwgem's points and I would also add something about release cadence. Can the community be of any help in making that process more frequent?

markpeek commented 7 years ago

Fair questions. This has mainly been maintained by myself and @phobologic. This last period has been one of the times when both of us have been busy with our day jobs. In my case I've been traveling as well which has not helped. Compounding it has been the number of changes coming in from AWS. I have always been open and appreciative to others putting in PR's and doing code reviews. I also thought fewer releases was better (from a user upgrade point of view) but given AWS has been releasing more quickly the need for more rapid troposphere releases is warranted. What I believe I'm hearing is the request from the community to add more maintainers to have more coverage and have them help with this more rapid release cycles. How does the community feel about adding more people? How should they be vetted to maintain quality and stability of the code base? Any nominations?

Also, to the more immediate point, I will put out a new release this weekend.

saysjonathan commented 7 years ago

@markpeek Thank you for taking the time to explain why releases can be slow, for offering solutions, and for cutting the next release :)

I support the idea of additional maintainers if that is what is needed to increase the rate of releases. Weekly or bi-weekly releases, if any changes have been made during that time, could be helpful for preventing too much drift between master and Pypi

I personally do not have any nominations but, if no others are named, I'd be willing to accept the role. Feel free to reach out to me if you'd like to talk.

phobologic commented 7 years ago

Hey folks - just wanted to chime in here as well. Like @markpeek says, I try to help out with the maintenance of troposphere - but things are crazy this time of year (I work at an education startup, and Back to School is our Black Friday - only it lasts for 8 weeks :)). A few thoughts:

totally down for extra maintainers - maybe looking at the top contributors for folks would be a good idea? Heck, at this point @philtay has contributed more than me :) https://github.com/cloudtools/troposphere/graphs/contributors
I think the hardest part of maintaining troposphere is the PRs. A couple of things could help with this:
- Get us to dynamically generating everything from the AWS Cloudformaton schema. @markpeek has done a bunch of work torwards that in the past, but the schema is finicky and has (had?) some issues with naming collisions which were hard to resolve. If someone had time to dive into this, that would help a ton.
- More people in the community could dive into PR reviews - I think that'd help a lot.
Once things are merged, it's usually pretty easy to make a release - but honestly, once things are merged you can use pip to pull the sha you want (or master, master tends to stay stable). I've been doing this more and more in my own projects.

I'm totally down for a regular release schedule, and I'd be up for committing to that. The downside of that is that it means that some features might miss "ship windows" because their PRs aren't reviewed/have issues that need to be resolved. That said, I still believe that getting things reviewed is the hardest part here, not the actual release cycle since it's really easy to work around releases.

Thanks for bringing this up - I'll try to put more of my focus in here and give @markpeek a little less work to do!

craigbruce commented 7 years ago

totally down for extra maintainers - maybe looking at the top contributors for folks would be a good idea?

Oh no I'm the 4th on the list! My commits have only dropped off because I see PRs before I've even read the AWS announcement blogs on new features - a credit to the community and importance of this library. That said I'm more than happy, if needed, to help maintain Troposphere (and awacs) as both are important for my day to day work.

phobologic commented 7 years ago

@craigbruce 4th place you say? Are you gunning for my job? I've got my eye on you. :rofl:

cwgem commented 7 years ago

@phobologic My general thoughts:

PRs are more of an issue due to the need for guidance on the overall architecture. We need documentation on things such as
- How do you validate parameters
- When should you create a new validator
- How are templates tested
- What's the basic structure of a resource
On that note overall documentation could use a face lift
Release cycles I'd probably split into 2 week and 1 month. When AWS is pushing a lot of CloudFormation changes out we should do a 2 week release. If things cool down a 1 month release would be fine.
Instead of attaching a release to specific issues, I think it should be whatever is doable within reason. AWS batch pull request for example looks like it's going to take a lot more time than expected, and I don't want that to hold a release up.
We really need to play catch up. Have a bug hunting day or something where we can go through existing pull requests and just start knocking stuff out. I think it would be fine at this point to close issues/pull requests that aren't getting traction with the expectation that they will be re-opened if it's truly a cause that needs addressing.

saysjonathan commented 7 years ago

Once things are merged, it's usually pretty easy to make a release - but honestly, once things are merged you can use pip to pull the sha you want (or master, master tends to stay stable).

I agree with this personally, especially given the nature of this project. There's relatively little breakage.

That said, working around company mandates is another matter. Only version pinning is a requirement I've seen at some companies.

Juberstine commented 7 years ago

Just to chime in here, I work with @saysjonathan. Is it possible you could make your CI/CD system run the tests and cut the releases for you on a schedule? Might make life easier for everyone.

markpeek commented 7 years ago

BTW, release 1.9.6 has been published.

saysjonathan commented 7 years ago

Thanks for jumping on this so quickly, @markpeek. Since the core of this issue is complete, feel free to resolve this issue as you see fit.

axelpavageau commented 7 years ago

I'll use this opportunity to say a big "thank you" to the core team and all contributors. We use Troposphere daily, and appreciate it a lot.

Cheers !

gkrizek commented 7 years ago

I would throw my hat in the ring if you are still looking for additional maintainers. I'm low on commits to this project, but I'd love to be more involved.

I use AWS all day every day and I never touch anything without going through Troposphere first.

rtkmhart commented 6 years ago

I'm willing to help as well, same boat as others here. I use troposphere daily and don't touch AWS in any meaningful capacity without out. I'd live to see a regular release cadence.

benbridts commented 6 years ago

I'm willing to help out too,

I don't always have a lot of time, but I may be able to help with triaging or reviewing PRs.

jawadst commented 4 years ago

@markpeek Any chance you could do a release? I'd love to be able to use https://github.com/cloudtools/troposphere/commit/707ded0f673f44b31d0762d8210a6b94074200e8

markpeek commented 4 years ago

Heh...teach me for not closing out this issue. :-) :-)

Yes, I was going to make another pass for any missed changes and roll a release this weekend. Thanks for pinging me on it.

jawadst commented 4 years ago

Ha, thanks for your quick answer :)

cloudtools / troposphere

Release cadence discussion #816