| Message ID | 222125290.1094501.1505817563211@poczta.nazwa.pl |
|---|---|
| Headers | show |
| Series | Month names in alternative grammatical case | expand |
Ping - anyone? 0: https://sourceware.org/ml/libc-alpha/2017-09/msg00711.html 1: https://sourceware.org/ml/libc-alpha/2017-09/msg00712.html 2: https://sourceware.org/ml/libc-alpha/2017-09/msg00713.html 3: skipped 4: https://sourceware.org/ml/libc-alpha/2017-09/msg00714.html 5: skipped 6: https://sourceware.org/ml/libc-alpha/2017-09/msg00715.html All patches and the full story: https://sourceware.org/bugzilla/show_bug.cgi?id=10871 Regards, Rafal
26.09.2017 12:45 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > > > Ping - anyone? > > 0: https://sourceware.org/ml/libc-alpha/2017-09/msg00711.html > 1: https://sourceware.org/ml/libc-alpha/2017-09/msg00712.html > 2: https://sourceware.org/ml/libc-alpha/2017-09/msg00713.html > 3: skipped > 4: https://sourceware.org/ml/libc-alpha/2017-09/msg00714.html > 5: skipped > 6: https://sourceware.org/ml/libc-alpha/2017-09/msg00715.html > > All patches and the full story: > https://sourceware.org/bugzilla/show_bug.cgi?id=10871 > > Regards, > > Rafal PING^2 - anyone? BTW, I have updated my github fork, useful for convenient browsing: https://github.com/rluzynski/glibc (Please ignore those commits which will not be pushed, this means the backward compatibility part.) Regards, Rafal
3.10.2017 01:43 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > > > 26.09.2017 12:45 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > > > > > > Ping - anyone? > > > > 0: https://sourceware.org/ml/libc-alpha/2017-09/msg00711.html > > 1: https://sourceware.org/ml/libc-alpha/2017-09/msg00712.html > > 2: https://sourceware.org/ml/libc-alpha/2017-09/msg00713.html > > 3: skipped > > 4: https://sourceware.org/ml/libc-alpha/2017-09/msg00714.html > > 5: skipped > > 6: https://sourceware.org/ml/libc-alpha/2017-09/msg00715.html > > > > All patches and the full story: > > https://sourceware.org/bugzilla/show_bug.cgi?id=10871 > > > > Regards, > > > > Rafal > > PING^2 - anyone? > > BTW, I have updated my github fork, useful for convenient browsing: > > https://github.com/rluzynski/glibc > > (Please ignore those commits which will not be pushed, this means > the backward compatibility part.) PING^3? BTW, my copr repo with pre-built binaries is mostly up-to-date: https://copr.fedorainfracloud.org/coprs/rluzynski/genitive and my github repo became outdated with time but it can be updated easily. Regards, Rafal
On Tue, Oct 10, 2017 at 6:30 AM, Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > 3.10.2017 01:43 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: >> 26.09.2017 12:45 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: >> > >> > Ping - anyone? I plan to review this carefully, and perhaps go ahead and merge it, next week if no one else gets to it first. zw
11.10.2017 19:47 Zack Weinberg <zackw@panix.com> wrote: > > > On Tue, Oct 10, 2017 at 6:30 AM, Rafal Luzynski > <digitalfreak@lingonborough.com> wrote: > > 3.10.2017 01:43 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > >> 26.09.2017 12:45 Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > >> > > >> > Ping - anyone? > > I plan to review this carefully, and perhaps go ahead and merge it, > next week if no one else gets to it first. > > zw I'm not sure if I understood you correctly. Should I wait for your review and then go ahead and merge? Then here is my ping. Or maybe did you mean that I should go ahead and merge even if you don't have time to review? In this case I'd rather not merge without another review because at least two things are not clear to me: 1. You asked me to write a documentation but I'm not sure which documentation you meant. I updated NEWS, ChangeLog and some files in the manual directory. But I'm not sure if this is sufficient, also I'd like to see at least one review. 2. You asked me not to send the generated file locfile-kw.h to this list [2] so I have not sent it anymore. But this file still needs to be pushed to git. The patches are still available in bugzilla [3] and my github repo. [4] Should I merge them after the review and before pushing to master? BTW, I have updated my github repo but not other places where these patches are stored (bugzilla, Fedora COPR, this list). With the glibc development moving fast forward it's difficult to keep the patches up-to-date. Regards, Rafal [1] https://sourceware.org/ml/libc-alpha/2017-07/msg00031.html [2] https://sourceware.org/ml/libc-alpha/2017-07/msg00032.html [3] https://sourceware.org/bugzilla/show_bug.cgi?id=10871 [4] https://github.com/rluzynski/glibc
On Wed, Oct 25, 2017 at 6:50 AM, Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > 11.10.2017 19:47 Zack Weinberg <zackw@panix.com> wrote: >> I plan to review this carefully, and perhaps go ahead and merge it, >> next week if no one else gets to it first. > > I'm not sure if I understood you correctly. Should I wait for your > review and then go ahead and merge? Then here is my ping. Yes, I meant you should wait for my review, which I'm doing now. Sorry for not getting to it "next week" as previously promised. > 1. You asked me to write a documentation but I'm not sure which > documentation you meant. I updated NEWS, ChangeLog and some files > in the manual directory. But I'm not sure if this is sufficient, also > I'd like to see at least one review. I'll address this in replies to individual patches. > 2. You asked me not to send the generated file locfile-kw.h to this list [2] > so I have not sent it anymore. But this file still needs to be pushed > to git. The patches are still available in bugzilla [3] and my github > repo. [4] Should I merge them after the review and before pushing to master? What you should do is drop the separate patches that regenerate generated files from the patch series you send for review, but then, right before pushing, for each patch, regenerate any generated-but-checked-in files that will be altered by that patch and check them in *as part of that commit*. I sense that you are confused by both the request to not send generated-but-checked-in files for review, and the desired procedure for handling them in the commits that actually get pushed, so let me explain why we do it this way: First, we want generated-but-checked-in files always to be up to date in the commit history, so that "git bisect" works reliably. So we want the regenerated file to be checked in in the *same commit* that changes what the generated file will be, always. You can think of this as mimicking how it would work if the file wasn't checked in: it would get generated during the build in a state matching the actual source code. Second, we don't review generated files, we review the code that generates them, and generated files are often very long and tedious to wade through, so we don't want them cluttering up the emails we get. (But we *do* want them to be mentioned in your ChangeLog entries so that we have the reminder right there that generated-but -checked-in files are involved. "* x/y/foo: Regenerate." is enough.) Some day we won't have any generated files checked into version control, but until then this is the best compromise procedure we can think of. You might actually find it easier to edit the generated files out of the output of "git format-patch" after the fact. zw
Zack, Thank you for your review and I'm sorry for my delayed response. I'm currently applying your suggestions. Please see my answers inline: 27.10.2017 17:14 Zack Weinberg <zackw@panix.com> wrote: > [...] > I sense that you are confused by both the request to not send > generated-but-checked-in files for review, and the desired procedure > for handling them in the commits that actually get pushed, Yes, first of all I thought that once the patch is reviewed and accepted for commit it should be committed without changing a single bit because any change may potentially introduce bugs. Now I understand that some reasonable changes are possible and even desired. > so let me > explain why we do it this way: [...] > [ cut detailed explanation ] Thank you for this detailed explanation. I believe it's very valuable. That's off-topic, but don't you mind if I copy it (with minor edits) to the Contribution Checklist wiki article [1] so it will be easier to find for the potential new contributors (and old ones, too)? Regards, Rafal
On Mon, Nov 6, 2017 at 4:18 PM, Rafal Luzynski <digitalfreak@lingonborough.com> wrote: > > Thank you for this detailed explanation. I believe it's very valuable. > That's off-topic, but don't you mind if I copy it (with minor edits) > to the Contribution Checklist wiki article [1] so it will be easier > to find for the potential new contributors (and old ones, too)? Yes, please do!