I'm tired of this "they worked hard for that" BS with acqui-hires and shutdowns.
Yeah, sure, they worked hard, but in the end they get a big fat F for the end result.
Services don't last forever, but I'm not gonna congratulate someone who runs around in circles for 3 years purporting to deliver a product of value, and then gives up when offered a better deal for themselves.
They didn't build a product, they built a nothing. It's like reverse vaporware, and I won't respect it.
Yeah this is my main problem with the way "startup culture" seems to work. There's a lot of people in my university really pushing people to start their own businesses, but the general reasoning just seems to be "come up with something, advertise so that you get bought out, take the money". There's no emphasis on actually making anything, just on drumming up hype for an idea and selling that.
They proved that they can build products. That makes them very valuable to companies with more money than time. It's a significant career success, if perhaps not quite a business success. And we can congratulate them for that.
Assuming this was a smart acquisition by Dropbox, they'll be able to create more value now than they were before the acquisition. Unless you're arguing that the acquisition is actually wealth-destroying, it seems pretty selfish to oppose it.
I appreciate your feelings towards the matter, but I don't support your action. An open letter to Drew Houston would have been enough. It's a corporation, we cannot force it to do something we want to. Boycotting them is not a good option.
It's almost like Socialism, where a populist sentiment is tried to be shoved down the throats of the corporations. I don't use dropbox, but I for sure appreciate their creative genius. It's their prerogative to appoint anyone they wish.
You might say it's your privilege to boycott, but then mass boycott is like mob mentality.
I might be acting like a devil's advocate, but don't the metrics reflect user behavior? And it's perfectly fine if they tune their UI for revenue. They are not missionaries, but they are visionaries. They need money to keep the innovation going.
I am not a facebook fan or an affiliate, and I do resent few of their design decisions, but earning money is well within their framework of morality.
In SVN, "merging" is a bad, scary, no good word. In Git/Mercurial it's an everyday operation that happens so seamlessly 90% of the time that you don't even notice. The other 10% of the time, you have great tools (i.e. 3-way merge tools) that make it easy to reconcile conflicting changes.
Agreed. Amazing how much the right tool can change habits - for the extremely better. It has barely occurred to me that people might struggle with merges (at least, small feature merges) anymore.
Switch to git at a minimum, if possible.
Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.
Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?
Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.
So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?
Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...
The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branch in a state to be deployed? are your changes done?".
You are right, that would be the opposite extreme. What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.
My experience has been that maximizing merges works best. If you're constantly merging, hardly any of your merges have any friction. The longer you're separate from the master branch, the more likely you are to get painful merges with conflicts and subtle bugs.
On the Trello Android team we have a similar workflow to the web client and server developers. We merge in to a shared development branch when we have a complete feature or bugfix. With git's --no-ff this allows us to see when a new feature was implemented, and when bugs pop up we have a clear list of intersections where they could have been introduced. Our workflow is roughly based on an excellent post by Vincent Driessen, http://nvie.com/posts/a-successful-git-branching-model/.
We use gradle for building. The actual app is split into two, trello-app and trello-lib. Anything that can be done w/o Android like SQLite caching, API calls, etc., is done in trello-lib which is a plain Java library. It makes the dev cycle much faster since you can write a unit test and run it in a second.
We don't have CI setup yet. For the server we use something custom but will most likely be moving to Buildbot and with that we'll also setup Android CI.
With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.)
With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository.
From the user's perspective, it looks about the same. But the Git merges are safer than the Subversion updates, because if the Subversion update messes up your working copy, you're stuck. But with Git, you always have (1) the commits you made locally, (2) the commits you just pulled from upstream, (3) the merge that was done by "git pull". And (1) and (2) can't get messed up, only (3) can get messed up. But you still have both your version (1) and their version (2) to go back to, so you have lots of chances to fix it.
Think of Git branches and the corresponding merges to be like Subversion updates with backups of the previous local working copy.
I recently switched to this approach and it works very well. No more "I want to push out this quick fix, but I have to wrap up this other thing first so I don't break the build".
With github it is especially nice. I push to a remote branch, which I can see when I go to the project page. When I click merge it shows whether or not the TravisCI build passed. If it looks good, then I click to auto-merge and it's all set. It is possible to even automate away that part as well and have the whole thing merge and deploy on push if the build passes, but I am not quite ready to take the plunge yet with that (too easy to botch a production release IMHO).
That's how my team at work does things as well. It actually speeds things along much more quickly than doing a bunch of fixes in one branch, because if one of your fixes is held up by QA, all the others can still be merged independently.
Yep. My team follows a similar workflow with Github - every feature, bugfix, etc is developed on a branch off of master, then merged back into master via pull request when it is ready for deploying.
It's a nice workflow, changes are very visible to the entire team and well summarized (by the commit history and any comments/discussion on the pull request itself). Making a new branch is a one-line operation (two if you count hooking it up to the remote), so no, I've never personally felt that was a drag. Sometimes it feels a bit silly to create a branch for a one or two line fix, but the visibility to the team is worth it.
I agree. I would pick 1 dirty branch with continuous builds and tests any time over several branches. I have worked with several branches too and it is always messy, lots of confusion and too many overheads (including the Release Manager guy).
I love trello... but I don't like the branching model... :)
What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.
This saves us some merging.
Commit to 1 dirty branch; assume it is broken and let tests prove otherwise. When tests pass, you know it is a working branch, tag and release. I skipped a few steps for simplicity.
Here, merges are an exception, not the rule.
This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?