On Wed, Aug 8, 2012 at 4:33 PM, m.roth@5-cent.us wrote:
If you want to force your team to wait for your change, fine - and sometimes it is even a good idea, but the tool should not make that decision for you.
Yes, I do want to force them to wait for what one person's working on - it's not like everyone else isn't working on *other* things. And each should be independent - changing an interface; that is, the parameters a function (sorry, "messages that a method) is expecting is always a big deal.
Interface/protocol changes aren't particularly tied to a single file or even a single project. If you are going to make changes that affect other things either everyone else needs to know what to expect or you need to be working on a branch that is kept isolated until everything else matches. It doesn't really matter if the file was locked when you make that change or not.
OK, both QA and operations should agree - QA as to whether a version can be released and operations as to when it happens.
Absolutely, though in a small shop, that tends to be developers and admin. Not that many places, unfortunately, have one or more folks who are only q/a.
Or worse, the developer may also change hats and be the admin... But developers should be doing new, experimental things and admins should insist on testing before going to production.