From: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug tracker tool we need |
Date: | 2012-04-18 19:50:28 |
Message-ID: | CAFNqd5VCec6kXych2fUQ+tV7WjrS_fb85NvH9Jj8gKQUVDy7Vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 18, 2012 at 1:48 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> The problem I've found with most tools is that they work reasonably
> well if you let them control the entire workflow. But when you want to
> do things your own way, and it doesn't match up with what they were
> originally designed to do, it all comes falling down quickly...
That's pretty much characteristic of the average SAP R/3 project.
If you can change the organization's business processes to follow
SAP's defined "best practices," then it's easy to install and use R/3.
But that normally not being the case, every "SAP project" winds up
having hideous customization costs to kludge the practices towards one
another.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-04-18 20:09:45 | buffer locking fix for lazy_scan_heap |
Previous Message | Andrew Dunstan | 2012-04-18 19:21:16 | Re: Bug tracker tool we need |