FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 09-02-2012, 06:04 PM
Ciaran McCreesh
 
Default EAPI usage

On Sun, 2 Sep 2012 15:23:58 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> To be honest I personally consider that ("eapis are not ordered") an
> abomination, and my personal wish would be to keep them large-scale
> ordered with (among one major version) unordered sub-versions
> ("4-xxx") if needed. or at least keep all PMS-approved eapis ordered.
> "Experimental eapis for use in third party software" should not
> require any mentioning in pms anyway. :]

I think you're missing the point of that declaration... It's fine for
you to think of EAPI 4 as being newer than EAPI 3. It's not fine for
you to consider EAPI 4 to be a superset of EAPI 3, and it's not fine to
try using comparisons other than string equality (with the annoying
special case for "" being "0") on an EAPI value.

--
Ciaran McCreesh
 
Old 09-02-2012, 07:04 PM
Michał Górny
 
Default EAPI usage

On Sun, 2 Sep 2012 14:54:12 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 02 Sep 2012 14:03:07 +0200
> hasufell <hasufell@gentoo.org> wrote:
>
> > On 09/02/2012 12:52 PM, Vaeth wrote:
> > > Rich Freeman <rich0@gentoo.org> wrote:
> > >
> > >> If I thought that bumping the EAPI would make my life as a
> > >> maintainer easier I'd just do it - I wouldn't need a policy to
> > >> tell me to do it.
> > >
> > > It is not only so much a question of whether it helps you as a
> > > maintainer but more whether it helps the user. And this is the
> > > case for all EAPIs which currently exist.
> > >
> > > I am surprised that nobody mentioned the following example:
> > >
> > > One of the arguments to introduce the user-patching code into
> > > EAPI=5 was that it should work for all packages - not randomly on
> > > some but not on others. So if in the course of time not all
> > > packages are bumped to at least EAPI=5, this goal cannot be
> > > reached by introducing the feature into the EAPI.
> >
> > global epatch_user has a downside which I think was not even really
> > discussed here unless I missed something. It could introduce many
> > bogus bug reports which are caused by user-applied patches, cause
> > it's easier now and you don't need to do it in an overlay.
> > The maintainer will need to catch this and asking which repo the
> > bugreporter did use is not sufficient. He will need the build log
> > and check if user patches got applied there.
>
> it is probably easy to add a big warning 'user patches have been
> applied' when emerge bails out because a build failed

Yes, and it is definitely easier to nice them than the fact that user
has patched the ebuild silently.

That said, I do not really remember users ever doing bogus bug reports.
But well, every reason to complain is good, isn't it?

--
Best regards,
Michał Górny
 
Old 09-03-2012, 06:19 AM
Duncan
 
Default EAPI usage

Michael Orlitzky posted on Sun, 02 Sep 2012 10:36:13 -0400 as excerpted:

> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> are valid. If someone would benefit from such a bump, he can file a bug
> and know that it won't be closed WONTFIX. On the other hand, the dev is
> under no more pressure than usual to do the bump.

This looks like a reasonable compromise indeed. =:^)

Tho I'd still suggest that like other "low priority" bugs, the package
maintainer can still resolve it as LATER, BLUESKY (tho AFAIK gentoo's
bugzilla doesn't have that one), or even WONTFIX (as opposed to
INVALID). The bug should be considered valid, so INVALID isn't correct,
but disallowing WONTFIX simply gets in the way of proper communication.
If a package maintainer WONTFIX, it's better to let them actually SAY
that, so the bug filer can get on with life, knowing they'll have to
longterm maintain their own overlay copy if they want the EAPI bump bad
enough, than to have the bug simply sit there, ignored.

Talking about which. what about a resolution PATCHESACCEPTED? IOW, I
don't care enough to bother with it myself, but if you provide the patch,
I'll take it. Tho I guess WORKSFORME sort of fits, if the definition is
bent far enough.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 09-04-2012, 09:06 PM
Brian Harring
 
Default EAPI usage

On Sun, Sep 02, 2012 at 10:36:13AM -0400, Michael Orlitzky wrote:
> On 09/02/2012 09:46 AM, Rich Freeman wrote:
> > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> >> What I dont actually understand at all is why bumping the EAPI should be so
> >> complicated or involved that it even deserves so much resistance...
> >
> > <rant>Ok, it REALLY annoys me when people pull out this kind of a line
> > in an argument... If it isn't all that complicated or involved and it
> > just makes so much sense, then why do we bother to waste time asking
> > for it to be made policy, since obviously everybody will just do it
> > anyway...
> >
> > Believe it or not, people who take up an opposing side in a debate
> > don't ALWAYS do it because they're simply dumber than you. That is,
> > unless they're arguing with me... </rant>
> >
>
>
> I think everyone would be happier if all ebuilds in the tree were EAPI4.
> On the other hand, Rich is right that making this a policy will have the
> opposite of the intended effect: developers just won't fix bugs in
> EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could
> easily spend a few hours on this).
>
> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> are valid. If someone would benefit from such a bump, he can file a bug
> and know that it won't be closed WONTFIX. On the other hand, the dev is
> under no more pressure than usual to do the bump.

If you attach a patch and have done the legwork, sure.

If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
noise and it's annoying. EAPI bump requests for pkgs that need to
move forward so an eclass can be cleaned up/moved forward, sure, but
arbitrary "please go bump xyz" without a specific reason (and/or
legwork done if not) isn't helpful. Kind of equivalent to zero-day
bump requests in my view in terms of usefulness.

~harring
 
Old 09-05-2012, 01:03 AM
Michael Orlitzky
 
Default EAPI usage

On 09/04/2012 05:06 PM, Brian Harring wrote:
>>
>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>> are valid. If someone would benefit from such a bump, he can file a bug
>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>> under no more pressure than usual to do the bump.
>
> If you attach a patch and have done the legwork, sure.
>
> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
> noise and it's annoying. EAPI bump requests for pkgs that need to
> move forward so an eclass can be cleaned up/moved forward, sure, but
> arbitrary "please go bump xyz" without a specific reason (and/or
> legwork done if not) isn't helpful. Kind of equivalent to zero-day
> bump requests in my view in terms of usefulness.

Except this is what we have now, and isn't a compromise at all.
 
Old 09-05-2012, 04:15 PM
Mike Gilbert
 
Default EAPI usage

On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>
>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>> are valid. If someone would benefit from such a bump, he can file a bug
>>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>>> under no more pressure than usual to do the bump.
>>
>> If you attach a patch and have done the legwork, sure.
>>
>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
>> noise and it's annoying. EAPI bump requests for pkgs that need to
>> move forward so an eclass can be cleaned up/moved forward, sure, but
>> arbitrary "please go bump xyz" without a specific reason (and/or
>> legwork done if not) isn't helpful. Kind of equivalent to zero-day
>> bump requests in my view in terms of usefulness.
>
> Except this is what we have now, and isn't a compromise at all.
>

What use is a bug report requesting an EAPI bump for no reason? There
is no sense in "compromising" and creating such a policy if nobody
actually benefits from it.
 
Old 09-05-2012, 09:29 PM
Brian Harring
 
Default EAPI usage

On Tue, Sep 04, 2012 at 09:03:55PM -0400, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
> >>
> >> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> >> are valid. If someone would benefit from such a bump, he can file a bug
> >> and know that it won't be closed WONTFIX. On the other hand, the dev is
> >> under no more pressure than usual to do the bump.
> >
> > If you attach a patch and have done the legwork, sure.
> >
> > If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
> > noise and it's annoying. EAPI bump requests for pkgs that need to
> > move forward so an eclass can be cleaned up/moved forward, sure, but
> > arbitrary "please go bump xyz" without a specific reason (and/or
> > legwork done if not) isn't helpful. Kind of equivalent to zero-day
> > bump requests in my view in terms of usefulness.
>
> Except this is what we have now,

Yes, I stated it because I view it as useful/sane.

> and isn't a compromise at all.

I think you're mistaken in assuming a compromise is the required
outcome of this. Given the choice between something productive, and
something not productive, you don't choose the quasi-productive
solution.

Bluntly, chasing EAPI versions w/out gain is a waste of time; others
may think "but it should be EAPI4- the latest!"- and they'd be wrong.
You bump when there is a reason to do so, or when from a maintenance
standoint you've got time (now) to do so and can push it forward-
getting ahead of future work. Keep in mind the rule "every change
carries a risk"- while the risk is generally stupidly low, it's
something I don't think you're being cognizant of in this notion of
trying to get everything at EAPI whatever.

Filing a bunch of "please bump this to EAPI-whatever" is just annoying
nagging, it doesn't accomplish anything nor is the ticket particularly
useful on it's own. A "Please bump to EAPI4 due to issue xyz" is
useful- there is a core reason beyond "hey, EAPI4 is the latest AND
EVERYTHING MUST BE THE LATEST GREATEST!!!"

Same angle for EAPI5 and user patching... yes, devs will have a reason
to move it forward, but user patching is going to be used by a *small*
fraction of our userbase. Meaning if you want it, you're likely going
to need to do the legwork bumping things forward, else you're on the
devs time/prioritizations.

Not saying it's perfect, but the comments above are realistic rather
than trying to compromise against the realities of the situation.
~harring
 
Old 09-06-2012, 05:03 PM
Michael Orlitzky
 
Default EAPI usage

On 09/05/2012 12:15 PM, Mike Gilbert wrote:
> On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
>> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>>
>>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>>> are valid. If someone would benefit from such a bump, he can file a bug
>>>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>>>> under no more pressure than usual to do the bump.
>>>
>>> If you attach a patch and have done the legwork, sure.
>>>
>>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
>>> noise and it's annoying. EAPI bump requests for pkgs that need to
>>> move forward so an eclass can be cleaned up/moved forward, sure, but
>>> arbitrary "please go bump xyz" without a specific reason (and/or
>>> legwork done if not) isn't helpful. Kind of equivalent to zero-day
>>> bump requests in my view in terms of usefulness.
>>
>> Except this is what we have now, and isn't a compromise at all.
>>
>
> What use is a bug report requesting an EAPI bump for no reason? There
> is no sense in "compromising" and creating such a policy if nobody
> actually benefits from it.
>

If there's really no reason, why would anyone bother to file a bug for
it? It's better for developers than the must-bump policy, and better for
users than what we have now.
 
Old 09-06-2012, 05:15 PM
Rich Freeman
 
Default EAPI usage

On Thu, Sep 6, 2012 at 1:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> If there's really no reason, why would anyone bother to file a bug for
> it? It's better for developers than the must-bump policy, and better for
> users than what we have now.

What change is even being proposed? If there is an issue that
actually impacts users, then that issue is the bug, and bumping the
EAPI is just the solution to the bug.

If an ebuild unnecessarily ignores CFLAGS, or if it is a blocker to
some eclass update, or whatever, then that is already considered a
valid bug.

That is my main concern with all of this stuff - just state what you
need in terms of outcomes, not solutions. If you can't identify the
outcome, then there is no need for the change anyway. By all means
suggest solutions in the report, but don't confuse the solution with
the problem.

Rich
 
Old 09-06-2012, 05:16 PM
Michael Orlitzky
 
Default EAPI usage

On 09/05/2012 05:29 PM, Brian Harring wrote:
>
> Yes, I stated it because I view it as useful/sane.
>
>> and isn't a compromise at all.
>
> I think you're mistaken in assuming a compromise is the required
> outcome of this. Given the choice between something productive, and
> something not productive, you don't choose the quasi-productive
> solution.

From a developer's perspective, it's obviously better to be able to do
whatever you want. But for users it'd be nice to be able to request a
bump to EAPI5 and not get told to buzz off.

Some people are unhappy with the current situation or this thread
wouldn't exist. A good compromise should make everyone just a little bit
unhappy =)
 

Thread Tools




All times are GMT. The time now is 03:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org