next-update-travis icon indicating copy to clipboard operation
next-update-travis copied to clipboard

opportunity to collaborate?

Open travi opened this issue 8 years ago • 5 comments

i stumbled across your project today and through it would be worth reaching out.

i am the maintainer of greenkeeper-keeper and have built it with motivations that are similar to some of those that you have mentioned, especially:

finally can take the human out of the loop

i recently gave a talk about the process that i have introduced to my team and have found to be very successful: https://presentations.travi.org/continuous-deployment-dsmjs-june-2017/

i'm curious about your thoughts around this approach and if it handles some of your concerns and what parts still concerning to you.

travi avatar Jul 06 '17 04:07 travi

Hi @travi

Let me take a look at your presentation, ok? Sounds interesting

bahmutov avatar Jul 07 '17 14:07 bahmutov

sure thing. since there's no video, there's plenty of detail not captured there. happy to fill in any gaps that would be helpful to you

travi avatar Jul 07 '17 15:07 travi

I love it nonetheless. I have done a lot of presentations on upgrading dependencies (https://slides.com/bahmutov/self-improving-software-node-week) and have thought about it for a while (https://glebbahmutov.com/blog/tags/modular-development/). I also have tools for modular development, testing, semantic release, etc (dont-break, next-update are my personal favorite together with its extension next-update-travis).

What I would really like to do is to make a commercial project that helps with keep dependencies chugging along without falling behind for enterprise. And make it simpler to write individual modules than monorepos!

bahmutov avatar Jul 11 '17 17:07 bahmutov

finally can take the human out of the loop

I wanted to jump in here and say that I too would love to create workflows that remove the tedious tasks associated with maintaining a project (and it's repository) in the fast moving world of JavaScript. That includes the tasks we all go through to give ourselves confidence our code is ready to be shipped to downstream consumers.

And make it simpler to write individual modules than monorepos!

In my own experience I've seen a shift back to monorepos because of the difficultly teams have with maintaining the release process for multiple repositories. They also find it frustrating to spend time maintaining existing code through tedious, repetitive, tasks, instead of adding value and solving problems.

hutson avatar Jul 18 '17 14:07 hutson

I realized today that I lost track of the notifications for this thread and dropped the ball on following up.

Thanks for sharing the links to specific thoughts on the topic. I've seen a number of your projects and how closely they align to my goals, but those links helped me find a few more that I'll have to try out when I have a chance.

The problems in this area present such a big opportunity for improvement, but it can be incredibly difficult to know how to piece the tools together to do better. I hope to be part of improving that situation for anyone that I can influence in some way.

As you pointed out, the major symptom of the problem beyond complaints of fatigue, etc., is the trend of projects moving to monorepos. It's hard to fault them for wanting to avoid some of the complexity around managing separate repos, but I'm definitely on the side of separation being the better goal if some of the major pain-points can be removed. Plus, even if a monorepo improves maintainability, I've felt a lot of pain trying to provide any value as an outside contributor to that type of project. Understanding or contributing to a single package is never straight forward and trying to file an issue in a sane way is even difficult (plus, dont get me started on the abuse of packaging principles through the insistence of releasing every package from a monorepo at the same time in order to keep the version numbers in sync, for whatever reason...).

My intent with opening this thread was the gauge interest in sharing thoughts across projects somehow. There are various ways these problems can be tackled, but I think it would be valuable to have some way to share goals and learnings, even if we aren't building the same projects. I'm not sure what the best avenue for collaborating around this would be, but if there is interest, I'm sure we can figure something out.

travi avatar Sep 10 '17 04:09 travi