Re: How protect bash history file, do audit alike in server

[Les Mikesell <lesmikesell@xxxxxxxxx>]

On Wed, Aug 8, 2012 at 4:33 PM,  <m.roth@xxxxxxxxx> 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.

-- 
  Les Mikesell
    lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos