[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wikitech-l
Subject:    Re: [Wikitech-l] Open git issues
From:       Platonides <Platonides () gmail ! com>
Date:       2012-03-31 22:39:06
Message-ID: jl812b$ndf$1 () dough ! gmane ! org
[Download RAW message or body]

On 31/03/12 09:56, Antoine Musso wrote:
> On March 30 2012 at 21:25, Platonides wrote:
> <snip>
>> How would you script that if you don't have the files? (as they are
>> pending a merge)
>> Could we have a branch which included all non-abandoned patches? Or
>> maybe all patches whose total feedback is not negative.
> 
> One just have to fetch the non-merged change from Gerrit. Git magic is:
> 
>  # Fetch change 1234
>  $ git fetch gerrit refs/changes/34/1234
> 
>  # Switch to that branch:
>  $ git checkout FETCH_HEAD
> 
> Remember that "refs/changes/34/1234" is just a pointer to some commit
> object exactly like "master". So you can switch to it, run your tests
> and submit their results.

And how do I know that what I need is refs/changes/34/1234 ?
Do you have a way of listing all changes of a certain repository?



> <snip>
>>> We should have less fixme nowadays since we have adopted a pre merge
>>> review, <snip>
>>
>> Can someone measure at CodeReview the number of revisions which went to
>> fixme after having been on ok? gerrit system allowing pre-review doesn't
>> help with the 'false review rate'.
>> There *will* be bugs which get merged into the main repo. Not every
>> master status will be perfectly stable, as we wish it were.
>> Ability to mark the patchsets as fixme is a good tool. If we had a list
>> of follow-ups in gerrit, that would also be useful.
> 
> We already have the fixme feature. That is done by down voting a
> patchset in the codereview field (the infamous : "I would prefer that
> you didn't submit this").
> 
> The follow up we have been abusing is also build in since you usually
> just send a second patch.  A follow up to a previous merge is either a
> new feature or a bug fix, it can still reference the change number but I
> am not sure there is any value in doing so.


Suppose A created a foo module in r12345, this was reviewed by B.

With the old system, if I perform a change:
 Don't leak passwords in the foo module. Follow-up r12345.

Then both A and B get alerted of that change, it is listed in the page,
when C goes to cherry-pick the foo module to production, he notices it
immediatly and also includes the follow-up.



> Whenever someone would need to use followup, he should probably use a
> branch instead. Branch are cheap, use them :-]

This makes no sense.
You're probably thinking on a feature made of revisions linked with
follow-ups, which should have been a branch in svn.
Note however that not having a state with all the code, you don't notice
the changes. And if you don't see them until they are merged, you're
back with the same intermingled revisions.



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[prev in list] [next in list] [prev in thread] [next in thread]