mnapoli / phpBeanstalkdAdmin

[UNMAINTAINED] Beanstalkd admin interface
http://mnapoli.github.com/phpBeanstalkdAdmin/
Other
132 stars 15 forks source link

Willing to maintain #13

Open sagikazarmark opened 9 years ago

sagikazarmark commented 9 years ago

Hey, are you still offering this?

I was planning something similar.

Would you allow me to do some rewrite? I would use a microframework instead of zend.

I am also thinking about writting a REST api.

mnapoli commented 9 years ago

Hey great news, yes this all seems really a good idea. Here is what I suggest:

I've written that 3 years ago I don't think there's anything left to save ;)

mnapoli commented 9 years ago

Also feel free to do #8 if you want to.

sagikazarmark commented 9 years ago

Sure thing. I also usually keep trying the master branch working.

I can imagine a possible teamup with pheanstalk. The main client, a monitor and possibly a console application to interact with beanstalk.

sagikazarmark commented 9 years ago

One thing I am not completely sure about is committing the vendor directory into the repo. For that case, I would rather create a ZIP and upload it when releasing the version. WDYT?

judgej commented 9 years ago

No, you don't commit the vendor directory. That is fetched by the developer or installer. You commit the composer.lock file, which contains the information needed to fetch known versions of everything into the vendor directory. You also commit composer.json that lists all the dependencies and ranges on versions of packages that composer will fetch.

sagikazarmark commented 9 years ago

@judgej you are right, this is how composer usually works. However @mnapoli wants that the user just downloads the ZIP file and it works without messing with composer. While this is an acceptable requirement, I don't think it should be done for the branch archives too.

Instead I would tag new releases regularly and create custom archives with installed dependencies.

judgej commented 9 years ago

It was certainly handy when you used to be able to upload arbitrary zip files to the release mechanism, then you could put together a complete build and release that.

Bur certainly keeping the repository reserved just for the source that is used to create the builds, will pay dividends when developing.

mnapoli commented 9 years ago

Regarding the vendor/ directory my POV is that as long that it's easy to download the latest zip containing everything ready to go we don't have to commit the dependencies. But that requires extra work, as you said either uploading manually the release every time, or setting up a release process with Travis to generate it (we've done it for Couscous, a little bit of work but it works fine).

sagikazarmark commented 9 years ago

My plan is to create a build script which builds a ZIP and a TAR archive which can be easily uploaded for releases. I would rather not automatize it as building process might differ from simply running composer install. For example assets (bootstrap, jquery) are going to be handled by Puli which supports symlinking files, while they must be copied for the archive.

It depends on our release cycle: if we plan regular releases, we might want to automatize it. If not, I have no problem with doing it manually.