Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
On 2018-12-20 10:42, Michael Orlitzky wrote: > On 12/20/18 10:25 AM, YUE Daian wrote: >> >> Did anyone ever considered using GitLab? >> Its community edition is quiet enough I think. >> > > Yes, but there's a small problem: we would need to run our own instance > of Gitlab to prevent some of the same problems that exist with Github > (like losing all of our data if they go out of business). > > The "run your own" version of Gitlab is a bit of a nightmare, being > built with Ruby on Rails. It has a million dependencies, many of which > are hard to package because rubygems/bundler are awful and encourage > worst practices. Gitlab upstream expects you to run a version that > bundles everything it uses. > > What's the security strategy for something with a million bundled > libraries? There is none, which makes following their advice pretty > irresponsible, too. > > For all its flaws, BugZilla is pretty stable software that uses stable > libraries in an ecosystem inhabited by adults. Our infra team are all > volunteers, too -- so we need an alternative that isn't way more work > for them to run. That sounds reasonable... I did not notice that "run your own" version of GitLab has so many security issues. I have only configured it in an intranet. I am just concerned that the current gap between official announcement and reality is not good for maintenance of packages.
Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
On 12/20/18 10:25 AM, YUE Daian wrote: Did anyone ever considered using GitLab? Its community edition is quiet enough I think. Yes, but there's a small problem: we would need to run our own instance of Gitlab to prevent some of the same problems that exist with Github (like losing all of our data if they go out of business). The "run your own" version of Gitlab is a bit of a nightmare, being built with Ruby on Rails. It has a million dependencies, many of which are hard to package because rubygems/bundler are awful and encourage worst practices. Gitlab upstream expects you to run a version that bundles everything it uses. What's the security strategy for something with a million bundled libraries? There is none, which makes following their advice pretty irresponsible, too. For all its flaws, BugZilla is pretty stable software that uses stable libraries in an ecosystem inhabited by adults. Our infra team are all volunteers, too -- so we need an alternative that isn't way more work for them to run.
Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
On 2018-12-20 09:18, Michael Orlitzky wrote: > On 12/20/18 6:28 AM, (Nuno Silva) wrote: >>> Well the Gentoo Wiki https://wiki.gentoo.org/wiki/Submitting_ebuilds >>> suggested that new ebuilds should be submitted via Bugzilla. >>> >>> Could you please tell me if it is still the recommended way? >>> If not, IMHO it is better to change Wiki as well to prevent further >>> misunderstanding. >> >> I would like to ask again for a clarification about this. Last month, I >> asked if there was some rule against using bugzilla, but there were no >> replies: >> > > BugZilla is right place. If you open a PR on Github, you'll get an > automated message telling you to open an associated bug on BugZilla. > If Github ever goes away, all of the PR history it contains will be lost > forever. > > Since Github is proprietary, forcing people to use it is against our > social contract, and many developers completely ignore everything you > post there. > > On the other hand, casually reading the contents of a PR is easier on > Github than with patches on BugZilla. For best results, do both. Did anyone ever considered using GitLab? Its community edition is quiet enough I think. Being able to comment directly on ebuilds/patches would be a really nice feature. IMO It makes communication efficiency much higher compared to compared to Bugzilla. Also since the GitLab server is hosted by the community, no Micro$oft get involved...
Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
On Thu, Dec 20, 2018 at 8:39 AM Nils Freydank wrote: > > Am Donnerstag, 20. Dezember 2018, 12:28:17 CET schrieb Nuno Silva: > > On 2018-12-20, YUE Daian wrote: > > > On 2018-12-20 03:50, Nils Freydank wrote: > > > [...] > > >> Additionally bugzilla is seen as too impractical to use for new packages > > >> that many don't get much attention there, only on github.com. > > > > > > Well the Gentoo Wiki https://wiki.gentoo.org/wiki/Submitting_ebuilds > > > suggested that new ebuilds should be submitted via Bugzilla. > > > > > > Could you please tell me if it is still the recommended way? > > > If not, IMHO it is better to change Wiki as well to prevent further > > > misunderstanding. > > from my perspective it seems as only github.com is used and bugs.gentoo.org > is more or less just kept as an official way for ebuild submission to keep > a backup mechanism on the own infrastructure. IMO this is largely the reality of the situation. The people doing the most work on unmaintained packages or proxy-maintained packages prefer the github PR workflow over bugzilla. But, officially Gentoo's social contract can't rely on that as the official mechanism. Probably wouldn't hurt to at least mention the "alternative" in the wiki article though. It is a somewhat contentious issue. But, in the end it boils down to more eyes if you use the unofficial method. Nobody will tell you not to do it the official way. > Maybe in a perfect world someone trustworthy could provide a single-sign-on > service for bugtrackers and a gitlab instance hosted by gentoo or stuff like > that, but the current state is quite confusing, agreed. IMO issue/PR tracking is a bigger unsolved problem than that. I think we really need a truly distributed solution for this, so that every service like github/gitlab/etc isn't reinventing the wheel here. gitlab does have FOSS issue tracking at least. I haven't used it to compare it with bugzilla/etc as to whether it is a viable subsitute. Gitlab.com will offer free hosting to FOSS projects. It has been discussed a bit on the various lists for Gentoo but I think the sense is that it isn't such a huge improvement to be worth a big move. It is more FOSS than Github of course, but of course you can implement the core of github (git itself) as pure FOSS also. FWIW I know somebody who has access to all the gitlab source and I trust him when he says that the FOSS community edition is the core of the enterprise edition. Fixes/etc in general always make their way to the FOSS core, and their hosted gitlab.com solution uses the same FOSS code at its core that anybody can download. I feel like bugzilla being so centralized is a weakness for most of the FOSS world. If somebody denied Gentoo access to infrastructure that would be a really hard part of the complete solution to replace. The git part is easy - you can do a git-based workflow that is completely distributed without much trouble. What you can't do is clone the issues database, work on a few, push your work on issues to Fred, who pushes it to Sally, and then Sally sends her updates to you along with Joe's, with all of that stuff happening in parallel with merge conflicts handled in a sane manner. -- Rich
Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
On 12/20/18 6:28 AM, (Nuno Silva) wrote: Well the Gentoo Wiki https://wiki.gentoo.org/wiki/Submitting_ebuilds suggested that new ebuilds should be submitted via Bugzilla. Could you please tell me if it is still the recommended way? If not, IMHO it is better to change Wiki as well to prevent further misunderstanding. I would like to ask again for a clarification about this. Last month, I asked if there was some rule against using bugzilla, but there were no replies: BugZilla is right place. If you open a PR on Github, you'll get an automated message telling you to open an associated bug on BugZilla. If Github ever goes away, all of the PR history it contains will be lost forever. Since Github is proprietary, forcing people to use it is against our social contract, and many developers completely ignore everything you post there. On the other hand, casually reading the contents of a PR is easier on Github than with patches on BugZilla. For best results, do both.
Re: [gentoo-user] Re: Is it that hard to add a package, or am I doing wrong?
Hi everyone, Am Donnerstag, 20. Dezember 2018, 12:28:17 CET schrieb Nuno Silva: > On 2018-12-20, YUE Daian wrote: > > On 2018-12-20 03:50, Nils Freydank wrote: > > [...] > >> Additionally bugzilla is seen as too impractical to use for new packages > >> that many don't get much attention there, only on github.com. > > > > Well the Gentoo Wiki https://wiki.gentoo.org/wiki/Submitting_ebuilds > > suggested that new ebuilds should be submitted via Bugzilla. > > > > Could you please tell me if it is still the recommended way? > > If not, IMHO it is better to change Wiki as well to prevent further > > misunderstanding. from my perspective it seems as only github.com is used and bugs.gentoo.org is more or less just kept as an official way for ebuild submission to keep a backup mechanism on the own infrastructure. Maybe in a perfect world someone trustworthy could provide a single-sign-on service for bugtrackers and a gitlab instance hosted by gentoo or stuff like that, but the current state is quite confusing, agreed. If you want to take care of your package become a proxied maintainer. If you go a step further later and become a gentoo dev you can also drop some workload from the proxied maintenance team and do you QA yourself and submit directly to the tree. > I would like to ask again for a clarification about this. Last month, I > asked if there was some rule against using bugzilla, but there were no > replies: > [...] No, as far as I know there is now rule, just a not so good usable platform and another one that is proprietary but works far better. A disclaimer in the end: I'm not a Gentoo developer, just another random user who maintains packages. Regards, Nils -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
