Closed craigbox closed 1 year ago
We cannot do this, ebcause dividing into N 1-7 or 1-10 is to keep file size below GitHub limit allowing to show it in UI. If you do this by letters, you will still (eventually) hit that limit. We can consider this, but this won't solve the issue, PRs for this are supposed to be small to medium, not huge.... For huge batch-like PRs I suggest sending update data in some CSV file and create an issue for this, then I'll process it manually or maybe come with some special process for such big batch updates.
I was saying have N=26; hopefully you're not making it any worse than you have now. I just hate giving you work to do the hard way is all! You tell me how it's easiest to do updates. Feel free to close if you prefer.
I see your point, well I can consider, but rather as a low priority (sorry) - can only work on this on Friday or next Monday and already have other tasks related to gitdm/devstats/velocity reports and then I have winter holidays 2 weeks... so I may come back to this later.
No rush at all my friend. A suggestion only if it makes your life easier. You don't have to do everything random open source issue openers request 😁
On Thu, Feb 2, 2023 at 8:00 PM Łukasz Gryglicki @.***> wrote:
I see your point, well I can consider, but rather as a low priority (sorry) - can only work on this on Friday or next Monday and already have other tasks related to gitdm/devstats/velocity reports and then I have winter holidays 2 weeks... so I may come back to this later.
— Reply to this email directly, view it on GitHub https://github.com/cncf/gitdm/issues/1347#issuecomment-1413242281, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABALHSLEUA5ZQ4RSIRIUF3WVNLSPANCNFSM6AAAAAAUOOX7DU . You are receiving this because you authored the thread.Message ID: @.***>
Thanks, regarding:
You don't have to do everything random open source issue openers request
I usually try - just because people's feedback is important for me.
It can be hard to send a PR against this repo given the
developers_affilations
files can change substantially when merged and rebalanced: hundreds of records move from the bottom of one file to the top of another.Would it make sense to move away from developers_affilations1-7 and move instead to developers_affilations_a-z files?