| 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: | Whole Thread | Raw Message | 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 |