AssetSync has moved / revamp

Question

AssetSync has moved / revamp

davidjrice opened this issue 9 years ago · 18 comments

So, AssetSync has moved. Apologies for the tumbleweeds and lack of response on issues of late. The community has been doing a good job of keeping on top of things with plenty of network activity. Thanks for that.

I hope to personally put in a good bit of time in the coming weeks updating, refactoring, documenting and pulling in a lot of the suggestions and pull requests.
Have recently returned to freelance work, just wondering if people are cool if I were to setup something like gittip? I dunno. Just an idea to hopefully inspire me to do more, through increased guilt, or something. lol.
Also want to invite anyone who has ever contributed a pull request, to fire me a message. I'll review and potentially give commit bits to a few of those people, to help get things moving even more.

Anything else I should be doing? Let me know.

Best,
Dave

Answer 1 · 2015-10-06T00:57:46.000Z

Thank you @davidjrice ... I'd definitely contribute to a gittip or alike to keep on supporting asset_sync!

Answer 2 · 2015-10-07T22:16:35.000Z

👍 happy to see this picked up 💃

Answer 3 · 2015-10-08T16:41:30.000Z

Thanks folks :) Don’t worry. I’ll hopefully get a chance to get stuck in to some things next week.

Answer 4 · 2015-11-13T22:26:39.000Z

@paulrnash may be interested

Answer 5 · 2015-12-14T23:57:55.000Z

What does it mean that AssetSync is "moved"? Does it mean this repo isn't the authoritative version anymore? What's the public gem version drawn from? As of this writing, the last commits to master were over a year ago, so it seems it has completely stalled. The gzip compression can be merged (or at least some feedback about it), it works and solves the problem => #310

Answer 6 · 2016-02-25T01:42:07.000Z

Any plan on adding some collaborators?

Answer 7 · 2016-02-25T19:44:59.000Z

Yep. If anyone is volunteering! I will consider adding them. So far no-one!

Sorry I still haven't got to restarting this. I'm really not sure the direction to take, I've been waiting till an opportunity to work on a project with asset_sync installed comes up to address these things as pretty much all the projects I'm working on at present, that pay the bills, do not have any assets served from rails.

Answer 8 · 2016-02-26T01:15:27.000Z

I can volunteer to review some easy to understand Pull Requests like #315
But that's all I can do with my time

I still got to maintain i18n-js (I am the only collaborator there :S)

I guess a "test project" should be created for debugging some issues
What bills need to be payed ?_?

Answer 9 · 2016-02-26T14:09:55.000Z

Well then, just added the first contributor. Welcome @PikachuEXE

Feel free to start preparing a new release in a branch if you want help reviewing.

There is a test project or two somewhere for older rails versions. Plus a good bit of tests in the repo however yeah, some sort of better integration test would be good.

Oh, just those pesky personal bills o.O

Answer 10 · 2016-02-26T23:23:51.000Z

Should I commit/merge things into master or another branch?
Also what would be the release process? (now that the project got collborators)

Answer 11 · 2016-02-26T23:40:53.000Z

Yeah. Branch would be great. I can help review then easily. Should add
contib guidelines too, yep

On Friday, 26 February 2016, PikachuEXE notifications@github.com wrote:

Should I commit/merge things into master or another branch?
Also what would be the release process? (now that the project got
collborators)

—
Reply to this email directly or view it on GitHub
#316 (comment)
.

Answer 12 · 2016-02-27T00:02:29.000Z

What about Pull Requests?
Should I pull them myself?

Release should also prepared by branch + PR?

Answer 13 · 2016-02-27T00:10:52.000Z

Not sure what to do best long term, tho preparing pull request into a branch for testing prior to merging is always a good idea! Feel free to prepare anything into individual testing branches and and/or collate those testing branches into a release branch, that’s generally how I’d do it.

Answer 14 · 2016-03-08T06:05:05.000Z

@davidjrice
I just saw #324 and I am thinking it would be a good example (since it's small) to know what actually should be done.

For my own gems, I will merge it into master by pressing the merge button (after it's reviewed)
And that's the default behaviour for starting Pull Request

But you mentioned that "preparing pull request into a branch for testing prior to merging is always a good idea!" and I don't understand what it means.
Maybe you can explain more with that example?

Answer 15 · 2016-03-10T13:33:23.000Z

@davidjrice @davidjrice As we're going to use in production, I'm interessed too. I'm committed to support further Rails versions and minor changes like #300 #294 etc..

Answer 16 · 2016-03-10T19:14:32.000Z

I think the recommendation is to stop using gems like this and switch to site-based CDN, cloudfront can now pull edge assets from a server of your choosing (i.e. your rails app), and automatically gzip them. That's what i'm doing, which of course has the benefit of speeding up deployments by a fair amount, and not using S3 to store assets that exist on your server anyway.

Better!!

Answer 17 · 2016-03-11T01:35:39.000Z

@mbhnyc
I guess the point of using this gem is to ensure the old assets are still available for a long time
e.g. images in old emails

Some applications require it, some don't
So it depends

Answer 18 · 2016-03-22T06:22:47.000Z

@davidjrice
I guess the fastest way for us to learn the process is to demonstrate how you you do it.
Any thoughts or schedule?