[gentoo-dev] Over-reliance of Gentoo projects on overlays

[gentoo-dev] Over-reliance of Gentoo projects on overlays

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRuKkEAAoJEFpvPKfnPDWzafoH/3YI+qPoOUuAUka7KjEtUMgP
Y2duMnyIxlYFGQF9VYCT6ARNdg87qACbPKgYhI0ExxQrKZ7BC4m+IJCpiUdzUQW5
BiKnk80KMp1Tdl98b/5EmODwkmQeEmGTlfZtkXMnx2pfs4e+5E+U04n/HDwsydue
W8jw6LnDdv4CrjaGpfNgZmmu+R4/opymravixq7Oh7JZ848hXijTY3sGfah3a7zB
4I5zzsTZ17GA9x5xr5Qhz+VJGvkODLNDnkKsMMLT7QIPlQUZX9Wqzu55Qu94WQsd
gtrf3/RbtyrBZe9XyTgUqhb1uHlbsjlhOxtD68YRBOQ/BGXvU5wFMuwY5gIZxsc=
=lH9A
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 12 Jun 2013 18:59:48 +0200
hasufell <hasufell@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

[hasufell]

-----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 <hasufell@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

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 12 Jun 2013 19:05:29 +0200
hasufell <hasufell@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

[hasufell]

-----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 <hasufell@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

[Michael Orlitzky]

-----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 <hasufell@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

[Alexander V Vershilov]

> 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

[Dirkjan Ochtman]

On Thu, Jun 13, 2013 at 6:56 AM, Alexander V Vershilov
<alexander.vershilov@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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

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ł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Alexander V Vershilov]

On 16 June 2013 08:08, "Paweł Hajdan, Jr." <phajdan.jr@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

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

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ł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Michael Orlitzky]

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

[Michał Górny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Dnia 2013-06-12, o godz. 13:23:04
Michael Orlitzky <michael@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)

iQJ8BAEBCgBmBQJRuVxUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
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-----

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[René Neumann]

Am 13.06.2013 07:44, schrieb Michał Górny:
> Dnia 2013-06-12, o godz. 13:23:04
> Michael Orlitzky <michael@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: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 585 bytes --]

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 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Rich Freeman]

On Wed, Jun 12, 2013 at 4:10 PM, Andreas K. Huettel
<dilfridge@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

[gmt]

> -----Original Message-----
> From: Michał Górny [mailto:mgorny@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

Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 381 bytes --]