| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 23/04/13 03:11 PM, Rich Freeman wrote: |
| 5 |
> On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <mattst88@g.o> |
| 6 |
> wrote: |
| 7 |
>> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <rich0@g.o> |
| 8 |
>> wrote: |
| 9 |
>>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers |
| 10 |
>>> <jer@g.o> wrote: |
| 11 |
>>>> Er, you can't be seriously suggesting we will drop repoman |
| 12 |
>>>> checks with the migration to git? I don't see how that would |
| 13 |
>>>> benefit anyone. |
| 14 |
>>>> |
| 15 |
>>> |
| 16 |
>>> Interesting point. One thing to keep in mind with git is that |
| 17 |
>>> commits don't affect the "central repository." Pushes are what |
| 18 |
>>> impacts the repository. |
| 19 |
>>> |
| 20 |
>>> If I spend six months working on a bunch of coordinated |
| 21 |
>>> package changes, nobody will see a thing until I push those |
| 22 |
>>> commits and 500 ebuilds all change atomically (not that I'm |
| 23 |
>>> suggesting that lack of communication is to be encouraged). A |
| 24 |
>>> repoman check on a commit may not reflect its impact six months |
| 25 |
>>> later when it actually hits the main tree. |
| 26 |
>> |
| 27 |
>> ... if you're squashing 6 months of work into a single commit |
| 28 |
>> before pushing. |
| 29 |
>> |
| 30 |
>> I don't think we want to do that, do we? Maybe bisecting isn't |
| 31 |
>> particularly interesting for the portage tree. |
| 32 |
> |
| 33 |
> I never said that I was squashing 6 months of work into a single |
| 34 |
> commit, only that I was pushing 6 months worth of commits in a |
| 35 |
> single operation. |
| 36 |
> |
| 37 |
> Any repoman checks done at the time of each commit are essentially |
| 38 |
> worthless. Consider this example: |
| 39 |
> |
| 40 |
> 1. Create app-misc/foo-1.2 which depends on app-misc/bar. |
| 41 |
> Repoman checks this and it is fine. 2. Do 500 other commits. 3. |
| 42 |
> Push it all to the tree six months later. 4. Get bug report that |
| 43 |
> app-misc/bar was renamed two months back. |
| 44 |
> |
| 45 |
> Repoman is about checking changes to the main repository. What |
| 46 |
> matters isn't how the change you made impacts your clone of the |
| 47 |
> repository, but how that change impacts the main repository when |
| 48 |
> it eventually makes its way back. |
| 49 |
> |
| 50 |
> Unless your workflow is to pull, commit, and push with no |
| 51 |
> intervening commits by other contributors, the repoman check needs |
| 52 |
> to be done before the push, not the commit. |
| 53 |
> |
| 54 |
> Rich |
| 55 |
> |
| 56 |
|
| 57 |
|
| 58 |
This makes a lot of sense to me too -- repoman checks that are |
| 59 |
absolutely -needed- are those run at push time, specifically when |
| 60 |
pushing to master. 'git commit' time doesn't have an equivalent in |
| 61 |
cvs, but to me the checks that should be done at this time would be |
| 62 |
covered by the 'repoman -d full' checks we're already supposed to do, |
| 63 |
and I don't think those need to be enforced. |
| 64 |
|
| 65 |
Alternatively, we could enforce repoman checks on any commit or push |
| 66 |
operation in master, and leave branches to their own devices. Of |
| 67 |
course, I haven't seen (or looked for, tbh) how tree development will |
| 68 |
be implemented/suggested to be done in git so I've no idea what role |
| 69 |
branches might play.. |
| 70 |
|
| 71 |
|
| 72 |
|
| 73 |
|
| 74 |
-----BEGIN PGP SIGNATURE----- |
| 75 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 76 |
|
| 77 |
iF4EAREIAAYFAlF24C0ACgkQ2ugaI38ACPASUQD/VqYe+f28wPGByWjcCicWiF5e |
| 78 |
84vjyyrMxS3IF1qLeisA/jzfePn7pID8RsUqLYUtdSF+xo6dZDhLJgQARelS4yMx |
| 79 |
=bywE |
| 80 |
-----END PGP SIGNATURE----- |
Archives