Andrew Beekhof wrote:
> On 7/17/07, Alan Robertson <[EMAIL PROTECTED]> wrote:
>> Andrew Beekhof wrote:
>> > On 7/17/07, DAIKI MATSUDA <[EMAIL PROTECTED]> wrote:
>> >> Hello, All.
>> >>
>> >> I tested Heartbeat dev tree(fb46aeb2b784) and found a bug on ocf
>> >> scripts files, e.g. drbd.
>> >>
>> >> drbd[9174]: 2007/07/17_14:02:45 DEBUG: drbd0: Command output:
>> >> /usr/lib/ocf/resource.d//heartbeat/drbd: line 148: /crm_master: No
>> >> such file or directory
>> >> lrmd[8888]: 2007/07/17_14:02:45 info: RA output:
>> >> (drbd0:0:notify:stdout) /usr/lib/ocf/resource.d//heartbeat/drbd: line
>> >> 148: /crm_master: No such file or directory
>> >
>> > Fixed in http://hg.beekhof.net/lha/crm-dev/rev/4d4a65a685a4
>>
>> Is this a patch you want to have considered for inclusion in the
>> upcoming release?
>
> That would seem like a good idea.
> I don't generally make a habit of making changes I don't want included
> in the next release.
OK. At this point, there is a process for selecting changes to put in
the next release, since it's now locked down. Lars approved of the
procedure - and you didn't object to it, so I assumed that you were OK
with this procedure.
Let me see if I can find it and reproduce it here...
> Here are the proposed rules of engagement for this one week period:
> - Each additional changeset will have a bugzilla for it, and will be
> linked to by the bugzilla, and the changeset on 'dev'
> will link to the bugzilla entry.
> - Every proposed bug fix will be announced on the -dev mailing list
> - Every proposed changeset will be inspected by myself and the
> community before being accepted.
> - Each accepted changeset will be announced on the -dev list
> right after it has been pushed to the 'test' repository
> - I have final authority on whether a given fix will go in
> during this time.
>
> Here are some of the criteria I will use to decide if a fix will go in:
> - Does it fix a regression?
> Fixes that fix regressions will be given priority
> - Does it fix something that would cause data damage?
> Fixes that fix data damage will be given high priority.
> - Is the patch "obviously harmless"? - like a documentation
> or release description change, or comments, or similar.
> - Will it require starting our long-running tests over?
> Things which will require this will likely have to wait for
> the next release, unless they are likely to destroy data.
> - Is it something that our long-running CTS tests don't test for?
> If so, then we won't have to start tests over.
> For example, if it's a *BSD-only fix, or a GUI fix, and
> if it's early enough to get reasonable manual testing, then
> I may take it.
>
> These are not exhaustive, but indicative of the criteria I will use.
>
> If we find too many regressions or probable data damage fixes (which is
> unlikely), then we would likely have to delay the release.
During this week, I need to be asked specifically to include a change -
and there has to be a bugzilla for it, and the change has to be in
'dev', and the bugzilla and the patch should point at each other.
This is very similar to previously approved project procedure.
And, I would like to add to this:
To ensure I don't somehow overlook a bug fix, it when announcing it on
the 'dev' list for inclusion in the release, please CC [EMAIL PROTECTED]
Although I'm trying to read the list, this will provide a bit of extra
insurance that I don't miss something during this critical period.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
