1 |
On Thu, Dec 20, 2018 at 8:39 AM Nils Freydank <nils.freydank@××××××.de> wrote: |
2 |
> |
3 |
> Am Donnerstag, 20. Dezember 2018, 12:28:17 CET schrieb Nuno Silva: |
4 |
> > On 2018-12-20, YUE Daian wrote: |
5 |
> > > On 2018-12-20 03:50, Nils Freydank <nils.freydank@××××××.de> wrote: |
6 |
> > > [...] |
7 |
> > >> Additionally bugzilla is seen as too impractical to use for new packages |
8 |
> > >> that many don't get much attention there, only on github.com. |
9 |
> > > |
10 |
> > > Well the Gentoo Wiki https://wiki.gentoo.org/wiki/Submitting_ebuilds |
11 |
> > > suggested that new ebuilds should be submitted via Bugzilla. |
12 |
> > > |
13 |
> > > Could you please tell me if it is still the recommended way? |
14 |
> > > If not, IMHO it is better to change Wiki as well to prevent further |
15 |
> > > misunderstanding. |
16 |
> |
17 |
> from my perspective it seems as only github.com is used and bugs.gentoo.org |
18 |
> is more or less just kept as an official way for ebuild submission to keep |
19 |
> a backup mechanism on the own infrastructure. |
20 |
|
21 |
IMO this is largely the reality of the situation. The people doing |
22 |
the most work on unmaintained packages or proxy-maintained packages |
23 |
prefer the github PR workflow over bugzilla. But, officially Gentoo's |
24 |
social contract can't rely on that as the official mechanism. |
25 |
Probably wouldn't hurt to at least mention the "alternative" in the |
26 |
wiki article though. |
27 |
|
28 |
It is a somewhat contentious issue. But, in the end it boils down to |
29 |
more eyes if you use the unofficial method. Nobody will tell you not |
30 |
to do it the official way. |
31 |
|
32 |
> Maybe in a perfect world someone trustworthy could provide a single-sign-on |
33 |
> service for bugtrackers and a gitlab instance hosted by gentoo or stuff like |
34 |
> that, but the current state is quite confusing, agreed. |
35 |
|
36 |
IMO issue/PR tracking is a bigger unsolved problem than that. I think |
37 |
we really need a truly distributed solution for this, so that every |
38 |
service like github/gitlab/etc isn't reinventing the wheel here. |
39 |
|
40 |
gitlab does have FOSS issue tracking at least. I haven't used it to |
41 |
compare it with bugzilla/etc as to whether it is a viable subsitute. |
42 |
Gitlab.com will offer free hosting to FOSS projects. It has been |
43 |
discussed a bit on the various lists for Gentoo but I think the sense |
44 |
is that it isn't such a huge improvement to be worth a big move. It |
45 |
is more FOSS than Github of course, but of course you can implement |
46 |
the core of github (git itself) as pure FOSS also. |
47 |
|
48 |
FWIW I know somebody who has access to all the gitlab source and I |
49 |
trust him when he says that the FOSS community edition is the core of |
50 |
the enterprise edition. Fixes/etc in general always make their way to |
51 |
the FOSS core, and their hosted gitlab.com solution uses the same FOSS |
52 |
code at its core that anybody can download. |
53 |
|
54 |
I feel like bugzilla being so centralized is a weakness for most of |
55 |
the FOSS world. If somebody denied Gentoo access to infrastructure |
56 |
that would be a really hard part of the complete solution to replace. |
57 |
The git part is easy - you can do a git-based workflow that is |
58 |
completely distributed without much trouble. What you can't do is |
59 |
clone the issues database, work on a few, push your work on issues to |
60 |
Fred, who pushes it to Sally, and then Sally sends her updates to you |
61 |
along with Joe's, with all of that stuff happening in parallel with |
62 |
merge conflicts handled in a sane manner. |
63 |
|
64 |
-- |
65 |
Rich |