Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 06/12/2013 06:51 PM, Michał Górny wrote: Hello, I'd like to raise another issue I've met again recently. Shortly put, some of our projects are relying too much on their overlays. The net result is that some of their packages in the tree are not well-tested, semi-broken and users end up being hurt by that. The major project where this can be seen is science. [...] Sorry for being very late on this thread, but for science I would like to mention that many scientific packages have severe QA problems (from a Gentoo standpoint). Upstream are usually scientists that often have no idea about how to write a build system. It is very hard to convince upstreams to implement a user selectable ar (e.g. bug 474784) or ranlib (e.g. bug 474788), etc. Some of these very specialized packages have literally 5 users and none of them will depend on being able to use an alternative 'ar'. However, QA enforces that devs come up with solutions to QA problems (at least before stabilization). I often think that it is not worth the effort to fix these kind of things. Now you could argue that with more manpower on the science team we could fix those, but I still think it is a waste. If there were more people on the science team, I would not want them to fix those trivialities. Let me say this clearly: I'm not against QA and I think that it should be enforced in the main tree. My conclusion is that some software naturally belongs in overlays. Making it main tree fit is just not worth the effort. Cheers, Thomas -- Thomas Kahle signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 16 June 2013 08:08, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. +1 This works really well for the Gentoo Chromium team, where we have just hard masked packages and ~arch packages right in the tree. In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that Chromium and co. it not a development library this is a end user application. End user applications should be in tree (except for some testing reasons), if not just ignore this letter. And thanks for your work. -- Alexander
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 6/16/13 12:36 AM, Alexander V Vershilov wrote: In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that Chromium and co. it not a development library this is a end user application. End user applications should be in tree (except for some testing reasons), if not just ignore this letter. And thanks for your work. Nice. :) Note however that v8 and ninja (the build system) are also maintained by the project in the tree. There is also libsrtp... Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. +1 This works really well for the Gentoo Chromium team, where we have just hard masked packages and ~arch packages right in the tree. It helps with earlier detection of problems, especially with ~arch packages. I also know there are developers who are using the hard masked packages (thanks!) and I'd like to make that as easy as possible. Also, because no overlays are needed, we are all on the same page about other packages installed on the system. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 06/13/2013 12:56 AM, Alexander V Vershilov wrote: The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. As a part of gentoo-haskell team, I'd like to say that CVS issue is not strongest one, there are much more meaningful reasons for having much stuff in overlays at least for haskell. IMHO: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. All above is applicable because in overlay we work on programmers libraries, with enduser applications (that are synchronized with portage tree) situation is slightly different. To be clear, I meant that sunrise and gentoo-haskell were good examples of overlays where e.g. subversion and git have made user contributions much easier. I don't agree that up-to-date libraries need to be in an overlay -- why not ~arch or package.mask instead, and leave the platform to stable? -- but I benefit greatly from (and appreciate) the fact that you guys are able to merge my pull requests into the overlay quickly so I can't complain too much.
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On Thu, Jun 13, 2013 at 6:56 AM, Alexander V Vershilov alexander.vershi...@gmail.com wrote: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. Cheers, Dirkjan
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am 13.06.2013 07:44, schrieb Michał Górny: Dnia 2013-06-12, o godz. 13:23:04 Michael Orlitzky mich...@orlitzky.com napisał(a): We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. Sunrise is not that good example. I liked to use it as an example but over time you start to see how degenerated it becomes. It seems that the bond between people is pretty poor there, and many of the packages lack proper maintenance. Some of them simply don't build at all and wait for a random Sunrise user to fix them. Then they lay unmaintained once again, and the story repeats. Then the policies in sunrise need to be more strict: If it is mentioned in the bug, that the version in sunrise does not build anymore, it should be dropped from sunrise if there is no fix in some timeframe [1]. Of course this puts more workload on the sunrise-team as they have to monitor the bugs and respond accordingly. - René [1] Dunno, perhaps two weeks if noone responds will fix it, four weeks else.
Re: TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On Wed, 12 Jun 2013 15:31:57 -0700 Greg Turner g...@malth.us wrote: Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays Actually, this is something I expected to happen soon after we got overlays but for some reason it haven't. I imagine we would not have a single gx86 official tree but rather a bunch of official overlays. For basic installation one would need just the system overlay. Then everypony could add official overlay for KDE, or gnome or whatnot as one desires. I haven't thought this through in any way but it feels like better design.
[gentoo-dev] Over-reliance of Gentoo projects on overlays
Hello, I'd like to raise another issue I've met again recently. Shortly put, some of our projects are relying too much on their overlays. The net result is that some of their packages in the tree are not well-tested, semi-broken and users end up being hurt by that. The major project where this can be seen is science. With no offense intended, but I'm afraid that sometimes the team itself is losing track of what has been committed to the tree and what is in the overlay, and especially which versions are compatible. Another similar project having this problem seems to be lisp. From bug #465864 (which points to many other bugs not fixed in gx86), you can gather: Anybody who intends to use something lisp-related (like maxima) in Gentoo seriously always uses this overlay. There are too few developers in the common-lisp herd, and the main tree remains neglected for years. (by Andrey Grozin) which shortly shows that in some areas the issues are really serious. Teams, what are the main reasons for keeping that much stuff in overlays? What can be done to avoid it? While I can see the benefits of, say, testing extraordinarily experimental stuff in overlays or keeping there stuff that is not intended to land in gx86 at all (like some custom hacks), I feel like just keeping the newer versions of some packages is more of issue breeder to us. Please remember that most of our users doesn't know those rules. If I am looking for a good mathematics package, I take maxima, though I have almost no idea of lisp except for parentheses. The lisp-related flags are confusing to me and ever worse is the fact that the default choice simply doesn't build. Then I try alternate implementations. Expecting users to grep bugzie or some other kind of pages to find that they are supported to install an overlay to properly use package that is in gx86 is not good. The sole existence and use of overlay is causing the gx86 package and/or its deps to be in increasingly worse shape. If the problem is really manpower, I think you should try to work with proxy-maint. If that's not enough, then we need to find a better solution. In the worst case, we may prefer to move some of the packages out of gx86 and specifically expect all users to use an overlay, consistently. But in this case, we should probably consider redesigning Gentoo to be based more on official or semi-official repositories like Exherbo so that all users would have equal rights. As a last note, I'd like to note that I'm talking about lisp that much because maxima is a recent case where I've seen this. But there were even worse things with science overlay, lapack and blas -- including getting the system into a state where neither gx86, nor science overlay packages work. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Jun 2013 18:59:48 +0200 hasufell hasuf...@gentoo.org wrote: On 06/12/2013 06:51 PM, Michał Górny wrote: Teams, what are the main reasons for keeping that much stuff in overlays? It's a mix of easier workflow especially for contributors and less responsibility/noise in case of bugs. If there is a bug in an overlay, you rather expect people to come up with a pull request. Herds relying heavily on overlays and their portage packages being far behind their overlay is just a prove that the herd is dying and needs assistance. That goes especially for science. Isn't it more an indication that Gentoo needs better package management support for overlays? - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG4qcIACgkQ96zL6DUtXhGkvQCeOCoIQfdBLNifJxQpGmC0UOrO yZ8An0LmIV8S8AjIaSU5IVDeHa4RuysV =8keM -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 07:02 PM, Ciaran McCreesh wrote: On Wed, 12 Jun 2013 18:59:48 +0200 hasufell hasuf...@gentoo.org wrote: On 06/12/2013 06:51 PM, Michał Górny wrote: Teams, what are the main reasons for keeping that much stuff in overlays? It's a mix of easier workflow especially for contributors and less responsibility/noise in case of bugs. If there is a bug in an overlay, you rather expect people to come up with a pull request. Herds relying heavily on overlays and their portage packages being far behind their overlay is just a prove that the herd is dying and needs assistance. That goes especially for science. Isn't it more an indication that Gentoo needs better package management support for overlays? No. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuKpZAAoJEFpvPKfnPDWza5EH/3Oc6ytKY9jH88DSWKO+WIeW eXv49f0SL2+VOGdpZ7as4rZSTNBktCsLAuug05F+iQyCOhXBQkYYetLJPEt6W7Fa LSMFFov2/jdGLIN1WhNzCHpjpvKs2vx5A28jcm/Iz6liYkSYw4jbd1MP0gb0pKBT 8oaUNL3KVQGhPJekEF+9+W/akeXoy5cCGUbngWghZtAhAN3k/H+QRsmToaq1/yK8 BnrHv9UXnh88k3KbAhrvfNjce8Oom6/Gf3XS7MjBxnQM323CbrZzoj0fJL6czvLa safA3gaVSTkK+FGmaz9oZv+hqmNUG1wWa020jt/UP88zVuQZoRr3y6yS9fDVKUo= =en4R -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? No. You make a persuasive argument. I realise now that the Summer of Code projects for this were a mistake. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG4rCsACgkQ96zL6DUtXhGtggCfXAKVZ6hTDOuoJyFkXSfD0hRX qo0An0wvJBcu7LNaPT7ybIbeFaVECScz =wzUv -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 07:13 PM, Ciaran McCreesh wrote: On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? No. You make a persuasive argument. I realise now that the Summer of Code projects for this were a mistake. Your conclusion is not related to my answer. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuK27AAoJEFpvPKfnPDWzTEoH/RRYSfZqrwE0YdbvoFi8Df/x yN+XUn95Dt9k08XGa6uhSdKc0U+hxjuP7JRE6C1lfV3M+sgegA5l+mEZSo0WeZmO xjMGykbLEIxAmUGmRTu1Hroy7R9RoRQKKF9aQ6VlwjmcbsxhVYpNJis/UY4sHrxe 7yygdcgpzMkT3rCZDdLyxUS5RCfOevVftImkmD/RlXayjHvqJDx8yisCxd4Ws2ll VR+xaTOe5UlTAxKj1t0qtIhd332tFsVY2+5XUtTkv3Ay0E6fd7t9GNvh+lUvoZfJ 0KT7Zz3dsuduerIoWBBy60c3G4A4mITlFwiOou4oEgE44L0Z/LBZheJGL6SFes4= =ASxW -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? No. You make a persuasive argument. I realise now that the Summer of Code projects for this were a mistake. We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRuK54AAoJEBxJck0inpOiHCsP/ivXsWF4GMYNkzNTCYLUmTZI hXXuF2ZEx6c1nlml/BXNtmABFcE6IO6GthLqLW7P6lmVyxy9E5jtDXD6Hht2H05K JLP57LO9dUjHZDeZeElkQDhZ1BHWFhTA0wAvzZqodGtjUiuxDFvp58E8iVvnnqw+ b852Y5bSh1hNPeb6c/P/tcRekOrz8k98LBlJny+rmw6AlRZLcieeKcTe5XPhRD6s QE79saIDThrqRn2fvkgdSMYJ0XR3FfkFWDeRopcilIJwm6+gjmkzGmXjBFkjG0g5 ImpeCtjL/0m/2gjUhKcJIYCNYxM/TD8K0MFRUpXLPX6jd76U1IL77UmTWMNz2r7m 2Rlr8gkvn9Iutlw1mhcLjYe6gaypfnDDv7rPZiJlLbSMY9XLwB3tLwatUzbEveBw Bn0AliHppphdA7cs50C7DlAw6cLTZKsdGlqTQJWaMxNHyXftYRQb65zD1AhfMawr /1XQ97cUHtozySdPMHaQVwrm0I7FxUtuV1z3x484gEgvn184u3XLnJIxRB8+ykhP vM/Az7GmGqNzDUeOFBKi1GHjQRlniMZPCOv43/QaKrN6t1Sjnrl68zuYEW5ujf/g tPUnLnVWl8vRQ6PZYE4OfipT9ovaTJFivRpXHWER6FTIIeBoypWfIYCnV5hNCOUL t6uIkp0UbYWl2RAL+ZIM =tHMl -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am Mittwoch, 12. Juni 2013, 18:59:48 schrieb hasufell: On 06/12/2013 06:51 PM, Michał Górny wrote: Teams, what are the main reasons for keeping that much stuff in overlays? It's a mix of easier workflow especially for contributors and less responsibility/noise in case of bugs. If there is a bug in an overlay, you rather expect people to come up with a pull request. Ah btw how's that git migration coming along? [/me runs and hides] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
RE: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-Original Message- From: Michał Górny [mailto:mgo...@gentoo.org] Sent: Wednesday, June 12, 2013 9:51 AM To: Gentoo Developer Mailing List Subject: [gentoo-dev] Over-reliance of Gentoo projects on overlays Hello, I'd like to raise another issue I've met again recently. Shortly put, some of our projects are relying too much on their overlays. The net result is that some of their packages in the tree are not well-tested, semi-broken and users end up being hurt by that. On the other hand, if those overlays' code, due to lack of sufficient manpower, interest, code quality, or whatever, is not able to bubble up through whatever chain of upstreams, perhaps the broken ebuilds or eclasses should be removed from gx86 or have non-gx86-compatible features masked or removed, so that overlay-specific code or features are maintained downstream, in the overlays that service them. In short, is it not the idea that non-masked gx86 stable, (and, to a lesser extent, non-masked gx86 ~arch) should contain easy-to-use, working ebuilds for the vast majority of users and standard use-cases, whereas overlays, even official overlays, are free to implement whatever quality standards suit the needs of the projects that administer them? Although there are clearly some Bad Things about overlays as a means of communicating features to end-users and organizing development, I'm not sure this implies there's anything wrong with the overlay mechanism per-se. These Bad Things may, instead, arise from deficiencies in the modularity of ebuilds or portage itself. Perhaps you should mention the specific bathwater you'd like to see thrown out, and, from there, folks can help determine where, if anywhere, is the baby? -gmt
TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? No. We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Disclaimer: I'm not a Gentoo developer -- actually, fuck that noise, I am a Gentoo developer. But you know what I mean. My knowledge of the gentoo QA process is limited to what I've been able to glean as a beneficiary of the work and a limited participant via the bugzilla system. The precise mechanisms and policies that drive Gentoo QA are actually fairly opaque to me. Anyhow... wrt overlays defeating the purpose of QA: overlays may or may not prevent the QA process from pertaining to users of overlays, depending on the nature of the overlays. But, in fact, far from defeating the purpose and integrity of Gentoo QA, my belief is that by providing a standard baseline that QA may rely upon, overlays serve to enhance and protect Gentoo's quality. consider: emerge --info provides the overlays in bug reports to gx86 package maintainers and, if there is doubt about the sanity of the overlays, maintainers are (I presume) free not to support nonstandard configurations. But if a bug-reporter has this problem, the overlay system actually protects them. If they feel they are left high-and-dry due to their nonstandard gentoo installation, and are sure that their bug is a legitimate gx86 bug, they are free to whip up a virtual machine or to temporarily drop their overlays and CFLAG rice and emerge --depclean emerge -e system. Assuming they turn out to be right, bug reporters and package maintainers can be sure to be roughly on the same page wrt reproducibility. Indeed, no matter what kind of personality conflicts or other nontechnical issues may be at play, the reporter of a legitimate bug is pretty much guaranteed to get some kind of resolution to his issue, or at least that has been my experience. If bug reporters don't like those results and want to implement a different solution than the one they got, overlays enable them to do that as well. In short, overlays permit Gentoo to maintain reasonable quality standards while encouraging innovation and casual experimentation. Larry the Cow approves of them. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. Such a policy might be OK for developers who are able to just hop on and make changes to gx86 without going though the whole bugzilla process, hence official. However, it seems like you're thinking of overlays as piles of package ebuilds which haven't yet made it into stable. They may be that, or they may not -- overlays can add profiles, modify core eclasses, or even replace portage itself with a customized variant, and who knows what else. As another poster pointed out sarcastically, the GSOC types of projects clearly don't comport well with this, even if certain things like, i.e., sunrise, arguably might. Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays, although I suppose that might have a negative impact on QA coverage without some corresponding changes on the QA end of things... I guess I don't know enough about it to speak confidently. As a huge consumer of the overlay and layman mechanisms, both as a user and a developer, there is absolutely no doubt in my mind that by far the gravest problem with the overlay architecture is its inability to create direct VCS connectivity between an overlay and its upstream PORTDIR (coupled with it's requirement to clone entire package directories instead of overriding them on a per-file basis). FWIW, I have nascent ideas about how to fix that, but they are quite radical, probably half-baked (even just as vaporware ideas), and arguably off-topic, so I won't elaborate. -gmt
Re: TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On 06/12/2013 06:31 PM, Greg Turner wrote: On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: On Wed, 12 Jun 2013 19:05:29 +0200 hasufell hasuf...@gentoo.org wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? No. We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Disclaimer: I'm not a Gentoo developer -- actually, fuck that noise, I am a Gentoo developer. But you know what I mean. My knowledge of the gentoo QA process is limited to what I've been able to glean as a beneficiary of the work and a limited participant via the bugzilla system. The precise mechanisms and policies that drive Gentoo QA are actually fairly opaque to me. Anyhow... wrt overlays defeating the purpose of QA: overlays may or may not prevent the QA process from pertaining to users of overlays, depending on the nature of the overlays. But, in fact, far from defeating the purpose and integrity of Gentoo QA, my belief is that by providing a standard baseline that QA may rely upon, overlays serve to enhance and protect Gentoo's quality. E.g. https://bugs.gentoo.org/show_bug.cgi?id=341807 Overlays aren't tested against one another. As you add more overlays, the probability of brokenness approaches unity. You're not allowed to commit broken shit to the tree, so adding your packages to gx86 implies that it works with the rest of the packages in gx86.
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On Wed, Jun 12, 2013 at 4:10 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Ah btw how's that git migration coming along? Even though we're drifting here an update is probably due. At this point I'd say we have pretty high confidence that we can accurately migrate the tree. The issues that remain shouldn't hold us back from just moving forward (they're issues with cvs keywords that are already issues in cvs). The bigger issues were all fixed (like mangling unicode). Infra changes aren't started, and those are probably rate-limiting at this point, especially since it is hard for anybody not in infra to contribute to this. We also need to write up docs, and once an actual workflow is announced I suspect we'll start getting objections. The likely conflict I see is between those who want all commits in the log to be signed (which means no rebasing), and those who don't want any merge commits in the log (which means always rebasing unless you are REALLY fast). Anybody who wants to chip in on this one feel free to do so - I would like to but haven't gotten around to it yet. Rich
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. As a part of gentoo-haskell team, I'd like to say that CVS issue is not strongest one, there are much more meaningful reasons for having much stuff in overlays at least for haskell. IMHO: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. All above is applicable because in overlay we work on programmers libraries, with enduser applications (that are synchronized with portage tree) situation is slightly different. -- Alexander
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-06-12, o godz. 13:23:04 Michael Orlitzky mich...@orlitzky.com napisał(a): We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. Sunrise is not that good example. I liked to use it as an example but over time you start to see how degenerated it becomes. It seems that the bond between people is pretty poor there, and many of the packages lack proper maintenance. Some of them simply don't build at all and wait for a random Sunrise user to fix them. Then they lay unmaintained once again, and the story repeats. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRuVxUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKY3gP/2EnN/dhh11Br7mMW2uyojIf 6/kmuS+r2FsarD844WazUCEgFlxFZFyg2KBER2FrF1Ke39yiMpxIYBEL1L6fw4oZ uZVw9Sxjdkm+uVTdTXoSPS1EJcLbjVcWCykEXfs9VkN88xLrarfr6QwWtPvnV8mT Pdtoa7NsvvR8Ch1a4iHY/6l5gJgEVptY/uFJeyJf9uV23fIKZ7xASNON0TwSYdZN AnsHFuC2CVx228Yh3XOjAHazO25QblwrOhHQdrgmh54mYAP2G6AkqsleKr/zSxT8 JwI7gYeinPIjsq9mn/wtCRq0ilFYX1RjK43YfeKoUGIY1yZz6RHyHKr+jvOyEHod BHMcjORQpIV6RNk4mrPPvlw85mgMMIy3lulXdlb48GIMCzdL7h62Ng0SdYXYVDIo 7d8zys/QdnVlqjfYHJPiGXvlHt2mm62Fi6Jvndp/3L2xfjEf9oIe/l4jK09J8vjr LjumvpOe+O09IZ+O4J+xOPidCmKzvye6L/Irg8T1wKLr5A4nSIDRny57z7iNZlym uKJHF7Nfg7lciIqEBBo8a3U2CmAhlC5b1kGJQ6hV7jKGKOVM7FwF//1UMFZVwpsc DNgBor/qvAnRbmZBm0Xxdo8rUeyp3N6xnxzlFVv2gKtStGkZPEaambzNB5Lne/u7 s4GWAvN4AtmdT9Iu67S5 =ZoAv -END PGP SIGNATURE-
