Hi Daiki,
That can be done by the attached patch (though it's a bit ugly).
Since you went to the trouble of writing the code, it's certainly
fine by me. Please go ahead and commit that? --thanks, karl.
Daiki Ueno writes:
> Paul Eggert writes:
>
>> On 11/22/2016 12:58 AM, Daiki Ueno wrote:
>>> Why can't we continue
>>> syncing with the gettext releases, even if one checks in a change into
>>> gnulib directly?
>>
>> I assume this is because Karl's procedure, which he runs periodically,
>> is to
I assume this is because Karl's procedure, which he runs periodically,
Nightly, for the record ... -k
Paul Eggert writes:
> On 11/22/2016 12:58 AM, Daiki Ueno wrote:
>> Why can't we continue
>> syncing with the gettext releases, even if one checks in a change into
>> gnulib directly?
>
> I assume this is because Karl's procedure, which he runs periodically,
> is to grab the latest release from va
On 11/22/2016 12:58 AM, Daiki Ueno wrote:
Why can't we continue
syncing with the gettext releases, even if one checks in a change into
gnulib directly?
I assume this is because Karl's procedure, which he runs periodically,
is to grab the latest release from various sources, and to copy the
re
Karl Berry writes:
> Hi Daiki (and all),
>
> if srclist-update were aware of the serial numbers of the files.
>
> 1) Not all synced files have serial numbers.
>
> 2) It's not clear to me that the decision about syncing
> should, in principle, be based on serial numbers (or timestamps).
>
> 3)
Hi Daiki (and all),
if srclist-update were aware of the serial numbers of the files.
1) Not all synced files have serial numbers.
2) It's not clear to me that the decision about syncing
should, in principle, be based on serial numbers (or timestamps).
3) Nevertheless I have no particular ob
Hello,
Karl Berry writes:
> I can sync against dev, or I can sync against releases, or I can not
> sync at all, or I can quit being responsible for this job entirely and
> someone else can figure out what to do :). I can't go back and forth
> depending on development "periods". [Or gettext could
However, in periods where only small and safe changes are being made,
The problem from my point of view is that I just see a change and can't
(don't want to) guess if it's "small and safe". If I can't blindly sync
the changes I see, that creates an additional burden that I can't (don't
want to
Hi Karl,
Sorry for not having replied to your first mail on this topic.
> gnulib has been synced against gettext releases, not gettext dev.
> This was a change I made at Daiki's suggestion a couple years ago.
I fully support this: the maintainer of a package needs the ability to
have unstable ch
10 matches
Mail list logo
