| 1 |
On 04/05/2016 11:37 AM, Alexis Ballier wrote: |
| 2 |
> On Sunday, April 3, 2016 8:07:13 PM CEST, Ulrich Mueller wrote: |
| 3 |
>>> In two weeks from now, the council will meet again. This is the time |
| 4 |
>>> to raise and prepare items that the council should put on the agenda |
| 5 |
>>> to discuss or vote on. |
| 6 |
>> |
| 7 |
>> I would like the council to follow up on the results of robbat2's |
| 8 |
>> portage repo usage survey: |
| 9 |
>> https://archives.gentoo.org/gentoo-project/message/c2ffa62837fd4cbdd42945bf57b09b25 |
| 10 |
>> |
| 11 |
>> |
| 12 |
>> The following two points should be discussed and possibly be voted on: |
| 13 |
>> |
| 14 |
>> 1. Should we continue providing ChangeLog files in the rsync |
| 15 |
>> distribution? |
| 16 |
> |
| 17 |
> If space is the sole consideration, then, changelogs can be removed |
| 18 |
> from manifests, and $PM default rsync command can exclude |
| 19 |
> '*/*/ChangeLog*' (or, at least, leave the possibility to do it). This |
| 20 |
> solution seems to be what would please everyone since robbat2's survey |
| 21 |
> results can be interpreted in many ways, but for Q2, more than 50% |
| 22 |
> voted "something but only if it were optional". |
| 23 |
> |
| 24 |
> |
| 25 |
> However, I think I recall a nice recap of some infra guy on how much |
| 26 |
> time it took to generate them. IIRC it was bearable at the moment (a |
| 27 |
> few hours) but still slow. Assuming infra hardware stays the same, |
| 28 |
> where will we be in 1, 2 or 5 years wrt to generating changelogs ? Is |
| 29 |
> there something that can be improved on the software side or are we |
| 30 |
> just bound to have slower and slower rsync distribution generation ? |
| 31 |
> If so, how much slower does it get over time ? |
| 32 |
If one had lots of time for fixing up things ... an incremental |
| 33 |
thick-manifest update in lockstep with new commits would be possible. So |
| 34 |
maybe each commit lags by a few seconds to a few minutes (if it's a |
| 35 |
single commit touching lots of files). |
| 36 |
|
| 37 |
But there would always be a thick-manifest copy available that would be |
| 38 |
behind only by a small time window, and could be propagated to rsync |
| 39 |
mirrors easily. The problem with that approach is that someone would |
| 40 |
need to write such code, test it, etc.etc. |
| 41 |
|
| 42 |
|
| 43 |
> What I mean there is that if changelog generation takes 5 days then we |
| 44 |
> don't have much of a choice but dropping them. |
| 45 |
> |
| 46 |
> Alexis. |
| 47 |
> |
| 48 |
Pff. Worst case you throw more hardware at it ;) |
Archives