"Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.
I would argue that this is a good practice with svn as well. You can have a free-for-all dev branch, or even a whole dev trunk, but having someone at the top (some kind of coordinator.. of builds..) makes a lot of sense.
The second method is to set up a server which runs automatic tests on all commits and guarantees at least that the git history remains clean and contributions do not break the build.
Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.
Personally I'm an svn fan, but I think with both it comes down to using it appropriately.
My main argument for svn in the corporate argument over git is that svn is more or less designed around centralized approach whereas with git if you want that (which in a lot of corporate cases you do) it has to be enforced procedurally, but both are perfectly doable.
That sounds like a configuration problem. SVN is seriously one of the better ones in this regard (try ClearCase if you want to see what being limited by bandwidth feels like).
If your workspace itself was on an NFS share, this might be part of it. By default svn creates a tonne of tiny files, which can take forever over NFS due to overhead.
Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
Totally this. As a subversion fanboy who has yet to jump on the git train, I see this as one of the major oversights in svn.
Personally I'm a fan of one developer, one branch. It's a bit of overhead for sure, but everyone having their own branch where they can check in their changes before merging in changes from the main branch is a nice safety net. You just have to learn to reintegrate to the feature branch often to avoid silo effect.
Honestly I think it's way more political than practical.
Tools tend to have use cases that they are more suited to, while having use cases that their competition is more suited to. It's not unheard of to actually fall into your competitors use case while developing a product that competes in some other use case.
Politics however will almost always force you to use your own products when it's an option, even if it's the worst option.
Also I think if I use the words "use case" one more time today I fear I might actually grow a suit and tie.. I feel like I need a shower:(
It's kinda depressing that while just about everyone external got it immediately, people (high up people) seem to have bought into it wholesale (assuming they arn't all in on it).
The joke wasn't all that funny, but yeah, the internal reaction is.
I actually have fond memories of some good April fools jokes.
A internet "radio" station I used to listen to had a great DJ who was known for being a little edgy but had a huge fan following. The day before April fools he went a bit further than usual, so that on April 1'st he could make a heartfelt statement about how he'd gone to far and after discussion with management it had been decided that he would be leaving. I _totally_ bought it (as did la tonne of other people). He played a song while the forums and IRC channel exploded.. then came on a few minutes later with "haha, I'm not going anywhere!". No one even suggested it might be a joke the whole time, he totally sold it... was brilliant.
And the infamous pink ponies (before ponies were cool.. if only we'd known..).
Pages and pages of onion-esq "SCO buys IBM" and "RMS buys a mac" is just tedious.
The satellite cracking scene was actually a frequent topic here back around ~2000, back when DirectTV and others went on the war path.
There was also a story on Christopher Tarnovsky more recently, and actually one of the more interesting things to come out of wired (http://hardware.slashdot.org/story/08/05/31/0013220/satellite-tv-hacker-tells-his-story.. unfortunately the link to the wired article is 404, in case someone actually wanted to RTFA).
Last year was terrible, with most of the stories being along the lines of "lulz, windows announces it's using windows kernel". I don't mind a clever joke, but most of it was just plain stupid.
There was a lot of complaining about it, so I'm assuming they've decided to take it easy this year. Personally I'm grateful.
Modern tires are actually ridiculously complex. Different types of rubber and other materials are fused using different temperatures and pressures, not to mention various steel bands and strengthening fibres.
Assuming you could do all that, there'd be a massive safety concern as well.
I think things like tires will be one of the last things we see printed.
I have to imagine that the climb to that level of 3D printing (assuming we ever get there) will be so gradual that society will have plenty of time to adjust.
The easy and classic way of prioritizing bugs is to count the number of people complaining.
You can throw a severity field in there, but it's always subjective and 10,000 users complaining about a "medium severity" bug is probably going to rise above 2 or 3 complaining about a "ultra high my life is over total showstopper" bug.
This model mostly works but of course falls apart when you've got the high impact to low user count bugs.
I'll give you that this bug carries a tad more weight due to what I would think is a large impact, but the usual "no one is fixing this bug" answers apply:
- do it yourself (I get that this is often not an option, but including for completeness) - convince someone else to do it - pay someone to do it - find some workaround
One of those oh so rare moments in this community, which most days won't agree on anything, can all come together around a unifying understanding that the author is a complete idiot.
Personally (and I get that this isn't universal), I view them more like the rewards PBS gives when people donate. No one donates because they really want that PBS mug, they donate because they want PBS to be a thing, and the mug is a nice bonus.
To me this is like donating to PBS and a week later finding that they've sold the station to TLC. What, you don't want to watch scripted reactions about house decorating all day, too bad, we sent you your mug!
If you view kickstarter as a gamble against getting the promised rewards, then yes, I agree they delivered. I own a dev kit and it's what they promised. But I have to assume at least some backers were buying into the long term goal and not the interim product.
In my view (and I understand this isn't universal), when you buy into a kickstarter it's because you want to see something happen. It's like investing, but instead of expecting money out of it, you expect a thing to become available which otherwise wouldn't (and which you then might have to pay additional money to get). It would be like donating to PBS, receiving your mug, then finding out they'd sold PBS to TLC and were buying an island somewhere.
For those that view buying into a kickstarter as a gamble against getting the promised reward (which I accept as a valid view), then I agree with this argument. Oculus delivered the dev kit, and as someone who owns one, it's what was promised, with the added bonus that it caught on and there is actual software for it.
I can see Facebook thinking that maybe they can make money from the Oculus, and maybe they can, but it's not going to be in a way that I assume most of the original backers thought they were buying into.
But there's no way in hell the Oculus guys think Facebook will carry on their vision and the vision they sold their backers on.
I mean I have no problem when a product flops, assuming the person creating the kickstarter didn't know it would flop. If they make a legitimate effort with the money they get, and they didn't miss-represent themselves, then that's fair in my opinion.
But this is basically them killing off what was a successful project. Maybe it's a reaction to the recent Sony announcement, but even if they thought they were about to lose, to me they still had a duty to the, inappropriately termed I guess, investors.
This almost makes me wonder if kickstarter needs to add some kind of protection against this kinda thing.
Legitimately impressed.
They really sold it. I was convinced it was April fools earlier today, but as it exploded I actually started to buy it. This was very well executed.
I can't help but wonder who wasn't in on it.
"Done right" means you have someone dedicated to the role of "git master" who merges the team's commits into the master repository.
I would argue that this is a good practice with svn as well. You can have a free-for-all dev branch, or even a whole dev trunk, but having someone at the top (some kind of coordinator.. of builds..) makes a lot of sense.
The second method is to set up a server which runs automatic tests on all commits and guarantees at least that the git history remains clean and contributions do not break the build.
Again, this is in no way git specific. Commit hooks are well supported in svn, and tools like hudson and jenkins handle continuous integration with svn just as well as with git.
Personally I'm an svn fan, but I think with both it comes down to using it appropriately.
My main argument for svn in the corporate argument over git is that svn is more or less designed around centralized approach whereas with git if you want that (which in a lot of corporate cases you do) it has to be enforced procedurally, but both are perfectly doable.
That sounds like a configuration problem. SVN is seriously one of the better ones in this regard (try ClearCase if you want to see what being limited by bandwidth feels like).
If your workspace itself was on an NFS share, this might be part of it. By default svn creates a tonne of tiny files, which can take forever over NFS due to overhead.
Compare to something like Subversion. Suppose you have a nice change. It's working properly. Now you svn up. Now you get a bunch of hard-to-resolve conflicts. You say "I don't want to deal with this now; I just want to go back to the state I was in before updating." Too bad, you can't (at least any way I know how). You're screwed, because Subversion has caused you to lose information.
Totally this. As a subversion fanboy who has yet to jump on the git train, I see this as one of the major oversights in svn.
Personally I'm a fan of one developer, one branch. It's a bit of overhead for sure, but everyone having their own branch where they can check in their changes before merging in changes from the main branch is a nice safety net. You just have to learn to reintegrate to the feature branch often to avoid silo effect.
Honestly I think it's way more political than practical.
Tools tend to have use cases that they are more suited to, while having use cases that their competition is more suited to. It's not unheard of to actually fall into your competitors use case while developing a product that competes in some other use case.
Politics however will almost always force you to use your own products when it's an option, even if it's the worst option.
Also I think if I use the words "use case" one more time today I fear I might actually grow a suit and tie.. I feel like I need a shower :(
It's kinda depressing that while just about everyone external got it immediately, people (high up people) seem to have bought into it wholesale (assuming they arn't all in on it).
The joke wasn't all that funny, but yeah, the internal reaction is.
(this is assuming it's not legit of course).
I've got to admit. The discussion going on in that ticket is pretty convincing, leading me to think that either:
a) legit
b) they sucked in a lot of their own people
c) really well thought out
I'm thinking (and hoping) b, with c as an unlikely but possible second.
I actually have fond memories of some good April fools jokes.
A internet "radio" station I used to listen to had a great DJ who was known for being a little edgy but had a huge fan following. The day before April fools he went a bit further than usual, so that on April 1'st he could make a heartfelt statement about how he'd gone to far and after discussion with management it had been decided that he would be leaving. I _totally_ bought it (as did la tonne of other people). He played a song while the forums and IRC channel exploded.. then came on a few minutes later with "haha, I'm not going anywhere!". No one even suggested it might be a joke the whole time, he totally sold it... was brilliant.
And the infamous pink ponies (before ponies were cool.. if only we'd known..).
Pages and pages of onion-esq "SCO buys IBM" and "RMS buys a mac" is just tedious.
<old man voice activated>
The satellite cracking scene was actually a frequent topic here back around ~2000, back when DirectTV and others went on the war path.
There was also a story on Christopher Tarnovsky more recently, and actually one of the more interesting things to come out of wired (http://hardware.slashdot.org/story/08/05/31/0013220/satellite-tv-hacker-tells-his-story .. unfortunately the link to the wired article is 404, in case someone actually wanted to RTFA).
* using linux kernel
Last year was terrible, with most of the stories being along the lines of "lulz, windows announces it's using windows kernel". I don't mind a clever joke, but most of it was just plain stupid.
There was a lot of complaining about it, so I'm assuming they've decided to take it easy this year. Personally I'm grateful.
Modern tires are actually ridiculously complex. Different types of rubber and other materials are fused using different temperatures and pressures, not to mention various steel bands and strengthening fibres.
Assuming you could do all that, there'd be a massive safety concern as well.
I think things like tires will be one of the last things we see printed.
I have to imagine that the climb to that level of 3D printing (assuming we ever get there) will be so gradual that society will have plenty of time to adjust.
The easy and classic way of prioritizing bugs is to count the number of people complaining.
You can throw a severity field in there, but it's always subjective and 10,000 users complaining about a "medium severity" bug is probably going to rise above 2 or 3 complaining about a "ultra high my life is over total showstopper" bug.
This model mostly works but of course falls apart when you've got the high impact to low user count bugs.
I'll give you that this bug carries a tad more weight due to what I would think is a large impact, but the usual "no one is fixing this bug" answers apply:
- do it yourself (I get that this is often not an option, but including for completeness)
- convince someone else to do it
- pay someone to do it
- find some workaround
This kinda reminds me of what AOL became.
Once you were bought and rolled into AOL, it basically meant the coolness had been sucked out. When AOL bought Netscape, we all knew it was over.
One of those oh so rare moments in this community, which most days won't agree on anything, can all come together around a unifying understanding that the author is a complete idiot.
I'd like to know this as well.
Good point.
I'm sure if someone offered me 2 billion to say, chop off my legs, given enough time I'd convince myself that it was a good idea.
Depends on how you view the rewards.
Personally (and I get that this isn't universal), I view them more like the rewards PBS gives when people donate. No one donates because they really want that PBS mug, they donate because they want PBS to be a thing, and the mug is a nice bonus.
To me this is like donating to PBS and a week later finding that they've sold the station to TLC. What, you don't want to watch scripted reactions about house decorating all day, too bad, we sent you your mug!
If you view kickstarter as a gamble against getting the promised rewards, then yes, I agree they delivered. I own a dev kit and it's what they promised. But I have to assume at least some backers were buying into the long term goal and not the interim product.
In my view (and I understand this isn't universal), when you buy into a kickstarter it's because you want to see something happen. It's like investing, but instead of expecting money out of it, you expect a thing to become available which otherwise wouldn't (and which you then might have to pay additional money to get). It would be like donating to PBS, receiving your mug, then finding out they'd sold PBS to TLC and were buying an island somewhere.
For those that view buying into a kickstarter as a gamble against getting the promised reward (which I accept as a valid view), then I agree with this argument. Oculus delivered the dev kit, and as someone who owns one, it's what was promised, with the added bonus that it caught on and there is actual software for it.
I can see Facebook thinking that maybe they can make money from the Oculus, and maybe they can, but it's not going to be in a way that I assume most of the original backers thought they were buying into.
But there's no way in hell the Oculus guys think Facebook will carry on their vision and the vision they sold their backers on.
I propose some kind of portmanteau. Maybe synergy and socialize.
Socialgy?
Syneralize?
Microsoft would probably at least do something with it.
It'll probably just die under Facebook, or be turned into something grotesque.
Yeah, I'd be pretty damn pissed.
I mean I have no problem when a product flops, assuming the person creating the kickstarter didn't know it would flop. If they make a legitimate effort with the money they get, and they didn't miss-represent themselves, then that's fair in my opinion.
But this is basically them killing off what was a successful project. Maybe it's a reaction to the recent Sony announcement, but even if they thought they were about to lose, to me they still had a duty to the, inappropriately termed I guess, investors.
This almost makes me wonder if kickstarter needs to add some kind of protection against this kinda thing.