Re: Patch queue triage
| От | Pavan Deolasee |
|---|---|
| Тема | Re: Patch queue triage |
| Дата | |
| Msg-id | 2e78013d0705012308x4ca37071tbb1458a6dfa1e655@mail.gmail.com обсуждение исходный текст |
| Ответ на | Patch queue triage (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Patch queue triage
|
| Список | pgsql-hackers |
On 5/2/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Sure, we can do that. I actually did that when I posted the
incremental versions of the HOT-patch, each version implementing
the next big chunk of the code. I can reverse engineer that again.
When I do that, should I just break the patch into logical pieces without
worrying about whether each piece alone builds/works correcttly ?
Or should I try to make each piece complete ? I know the second
would be a preferred way, but it would be more work. But if that can
considerably ease review process, I would do that by all means.
In any case, there will be dependecies amongst the patches.
I am on leave today, so would start on this tomorrow.
Thanks,
Pavan
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought.
Sure, we can do that. I actually did that when I posted the
incremental versions of the HOT-patch, each version implementing
the next big chunk of the code. I can reverse engineer that again.
When I do that, should I just break the patch into logical pieces without
worrying about whether each piece alone builds/works correcttly ?
Or should I try to make each piece complete ? I know the second
would be a preferred way, but it would be more work. But if that can
considerably ease review process, I would do that by all means.
In any case, there will be dependecies amongst the patches.
I am on leave today, so would start on this tomorrow.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: