1 |
On 18 April 2016 at 23:44, Jonas Jelten <jj@××××××.net> wrote: |
2 |
> especially to dump bugzilla. |
3 |
|
4 |
Dumping bugzilla at this time would be a regression really. "Lets just |
5 |
discard millions of bugs and their history and important context" is |
6 |
not really an option for a web accessible opensource project with lots |
7 |
of inbound links, some of which are stashed in git commit messages, |
8 |
and are essentially unfixable. |
9 |
|
10 |
> It provides a tightly coupled set of project management tools. https://phacility.com/phabricator/ |
11 |
|
12 |
I tend to find "tightly coupled" a synonym for "fragile" and "Inflexible". |
13 |
|
14 |
If there was a way for somebody to informally set up a phabricator |
15 |
instance in a non-committal manner |
16 |
that could be used merely for review purposes, that'd be nice. |
17 |
|
18 |
But "lets change to this cool new thing because its cool" is something |
19 |
that doesn't resonate with me. |
20 |
|
21 |
To 'Change' It has to be _proven_ useful for our usecases, and |
22 |
_proven_ to be _better_ than what we have, not dubious, tenuous and |
23 |
relatively unknown. |
24 |
|
25 |
I'd want to be personally comfortable with using it before I ever |
26 |
voted in favour of gentoo changing to it. |
27 |
|
28 |
And I'd expect all other devs to require that same high standard. |
29 |
|
30 |
Also: I Hold defacto reservations about anything written in PHP, due |
31 |
to both personal history with PHP, and the significant number of PHP |
32 |
projects with both atrocious code and glaring security defects. |
33 |
|
34 |
So I would want to be sure that not only is it better than what we |
35 |
have, but it is _at least_ as secure as what we have, and I'd want to |
36 |
be assured that the development team of Phabricator are competent and |
37 |
its not just yet-another-fly-by-night product. |
38 |
|
39 |
|
40 |
> Migrating would contradict the apparent goal of integrating github more tightly, |
41 |
|
42 |
I have no idea where this "apparent goal" came from: "tight" github |
43 |
integration is not and has never been "on the table". |
44 |
|
45 |
Github is purely a voluntary auxiliary process intended to allow |
46 |
people to augment their workflow in semi-useful ways, and then, some |
47 |
of the things github provides is harmful ( Githubs inability to handle |
48 |
rebased pulls makes people do horrible long merge commits ) |
49 |
|
50 |
Its been repeatedly stated that Github must never be "Relied upon" in |
51 |
a mandatory way, because it is inherently proprietary and usurps all |
52 |
the authority that Gentoo infra have, and puts the Gentoo organisation |
53 |
at Githubs mercy, and this would be entirely unconscionable as the |
54 |
"only pathway". |
55 |
|
56 |
-- |
57 |
Kent |
58 |
|
59 |
KENTNL - https://metacpan.org/author/KENTNL |