-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/09/13 08:19 PM, William Hubbs wrote:
> On Tue, Sep 03, 2013 at 01:37:25PM +0200, Michał Górny wrote:
>> Dnia 2013-09-03, o godz. 12:24:49 Markos Chandras
>> <[email protected]> napisał(a):
>> 
>>> On 3 September 2013 12:17, Michał Górny <[email protected]>
>>> wrote:
>>>> Dnia 2013-09-03, o godz. 11:53:22 Markos Chandras
>>>> <[email protected]> napisał(a):
>>>> 
>>>>> On 3 September 2013 11:45, Michał Górny <[email protected]>
>>>>> wrote:
>>>>>> Hello, all.
>>>>>> 
>>>>>> 
>>>>>> I'm attaching git-r3.eclass and a patch to git-2.eclass
>>>>>> that adds ability to use git-r3 internally via make.conf
>>>>>> switch.
>>>>> 
>>>>> I am a bit skeptical about this. Why would someone want to
>>>>> do this apart from testing the git-r3 eclass without
>>>>> touching the existing git-r2 compatible ebuilds? And why do
>>>>> you want to do that in the first place? If the maintainer
>>>>> is happy with how git-r2 works with his ebuilds I see no
>>>>> reason to allow users to silently override that eclass.
>>>> 
>>>> The goal is to give git-r3 most testing it could get before
>>>> it gets widely used. I'd prefer catching corner cases sooner
>>>> than later.
>>>> 
>>>> -- Best regards, Michał Górny
>>> 
>>> Ok but I don't think allowing users to override eclasses like
>>> this is a good thing. Maintainers expect the existing ebuilds
>>> to work with git-r2. If they start getting bugs because a user
>>> silently overrode the eclass the this is not going to be
>>> pleasant.
>> 
>> It is not done silently. It comes with big fat warning at the
>> top:
>> 
>> +       ewarn "Using git-r3 backend in git-2. Not everything is
>> supported." +       ewarn "Expect random failures and have fun
>> testing."
> 
> I tend also to want to err on the side of caution here. I don't
> think users should be able to change something in make.conf that
> affects which eclass an ebuild uses.
> 
> I would suggest putting a warning in the git-2.eclass that starts 
> encouraging maintainers to migrate their ebuilds to git-r3.
> 

To be honest, I see no problems with the option to source git-3 within
git-2 -- it's for testing, it's internal, it's not meant to be
supportable, and it's a precursor to official git-3 adoption and
deprecation of git-2.  There is a warning already that end-users will
see (as will we, in build.log's if bugs are filed), and I don't think
it's any more dangerous than say, setting 'I_KNOW_WHAT_IM_DOING="yes"'
in make.conf.

If this were to be an option that was explicitly meant for end-users
to use on a regular basis, then I would agree that it's not proper.
But this isn't some sort of official new feature, it's just a
workaround to allow something to get more testing.  I would be quite
surprised if anyone outside of ebuild developers/maintainers (whether
they be dev's or otherwise) would enable this option, or even know it
exists (outside of those that read this ML, of course)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iF4EAREIAAYFAlInPKQACgkQ2ugaI38ACPDrrgD+MyynAyYF4u9WhH/eAn2XT26P
OZIfSpVSdVB7/fdeqcEA+wUJgThucM5pZdf3QY8g2T15GA6McED+Hc/iABQG85Gk
=Tp+l
-----END PGP SIGNATURE-----

Reply via email to