Phabricator: All repositories registered - upcoming workflow changes

[Francis Herne]

On Thu, 2 Feb 2017 07:45:15 +1300
Ben Cooksley <bcooksley at kde.org> wrote:
[snip]
> 
> I think that we need some cleanup on the old reviews (Albert Astal Cid
> started
> some time ago) and more important strongly tell new users (and old
> users) to use Phabricator. I don't think that anyone wants to lose
> the work, but if a review has not been touched in a few months maybe
> it's time to see it is still
> interesting.
> If we start doing this now (or yesterday), the flow of new patches in
> reviewboard should decrease quickly.
> 
> 
> Getting everyone to shift over was the whole point of this thread. No
> new reviews should be opened on ReviewBoard, and existing ones
> shouldnt take more than a few weeks to clear.
> 
> Anything older than that usually won't apply to the code anymore.
> 
[snip]
> 
> Regards,
> Ben

Not every project is Plasma!

The churn rate in most projects is very low - as an arbitrary
statistic, the mean age of lines in kdevplatform is about 6 years. [1]

Almost every review since the KF5 port at least is semantically
meaningful, even when a few lines have been changed that prevent the
patch from applying.

----

Completely aside from open reviews, the history of comments and
revisions to committed ones is indispensable.

I don't know if you've seen my IRC comments, but in many cases the
reviewboard comments are the only record of why things are done in a
particular way. There's much more information in them than the commit
history, especially when the commit message or code comment says
 "see <reviewboard url>".

As a relative newcomer to the project, reading the reviews has saved me
literally hours compared to reverse-engineering the author's thought
process, and I'm one user out of dozens (hundreds?).


From another of your messages:
> There won't be any auto-forwarding - we'll be removing the subdomains
> completely.

Given the poor quality of KDE's mail indexing, this will make finding
comments for a given review somewhere between painful and impossible.

The logged update emails don't include the actual diffs *at all*, which
will make most comments meaningless in any case.

If you go ahead with this, we will lose years of accumulated knowledge
about the project, and it will cost many (many!) hours of developers'
time. I really did mean it when I wrote 'catastrophic'.

-Francis



[1]
`for file in $(git ls-files); do git blame --line-porcelain "$file"
| grep author-time; done | awk '{ total += ($2 /86400) } END { print
total/NR }'`
* 86400, to readable date, comes out as 22 May 2011.