I never delete messages from the files; I just comment them out. The CMP
files being the extreme example.
I'll start rejecting any PRs I see that delete messages that were in
.Final releases; I suggest all mergers should do the same.
On 7/4/13 5:12 AM, Darran Lofthouse wrote:
+1 - Similar to schema versions being 'protected' once
included in a
.Final tag we should maintain a record of the IDs as each release is tagged.
If a message is deleted in the middle of the range its reuse should be
easy to spot in subsequent pull requests but if the last message was
deleted its reuse would not be detectable.
Regards,
Darran Lofthouse.
On 04/07/13 08:47, Carlo de Wolf wrote:
> We actually need a report (/guard) that goes across multiple versions
> (including EAP).
>
> Carlo
>
> On 07/04/2013 02:35 AM, James R. Perkins wrote:
>>
>> On 07/03/2013 07:42 AM, Kabir Khan wrote:
>>> I also had a vague thought about this. Perhaps the logging annotation
processor could be changed to dump a target/logging-ids.txt file for each subsystem, which
we could then use to do a check at the end of the build.
>>> On 3 Jul 2013, at 15:19, Jaikiran Pai wrote:
>> There is actually LOGTOOL JIRA (
>>
https://issues.jboss.org/browse/LOGTOOL-74) to generate reports of the
>> log id and message. I haven't done anything with it yet, but a simple
>> text file would be easy enough. My initial thought was to feed a
>> format in since it would essentially become a table of some sort.
>>>> I wonder, if we could somehow integrate these checks and maintaining of
>>>> the range, within the build. I _think_ it should be possible to do it,
>>>> but I haven't thought much about it yet.
>>>>
>>>> -Jaikiran
>>>> On Wednesday 03 July 2013 07:47 PM, Brian Stansberry wrote:
>>>>> On 7/3/13 4:56 AM, Darran Lofthouse wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Recently we have had some issues reported where logging IDs are
>>>>>> suspected to be duplicates.
>>>>>>
>>>>>> Can I suggest that one thing we do need is to update the page
tracking
>>>>>> the reserved ID's to make it easier to identify what block is
available
>>>>>> next?
>>>>>>
>>>>>>
https://community.jboss.org/wiki/LoggingIds
>>>>>>
>>>>>> Would it would be easier if the ranges column was sequential, if
a
>>>>>> subsystem takes multiple allocations then it should just appear
in the
>>>>>> list more than once.
>>>>> If I understand what you're saying correctly, what you describe
is the
>>>>> way it's meant to be. A quick scan shows it follows that pattern,
except
>>>>> for CMP which didn't have multiple lines in the table. I fixed
that. If
>>>>> there are others that don't follow the pattern they should be
fixed.
>>>>>
>>>>>> At the moment to find a free block you need to
>>>>>> scan up and down the page to check the subsequent allocations.
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> ---------------------------------------
>>> Kabir Khan
>>> Prinicipal Software Engineer
>>> JBoss by Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> James R. Perkins
>> Red Hat JBoss Middleware
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev