Ryan Hill wrote:
> Pushing to eliminate one of these options is going to make one group or
> the other very annoyed.
>
++ When in doubt: "mechanism, not policy"
--
[EMAIL PROTECTED] mailing list
William L. Thomson Jr. wrote:
> On Tue, 2007-08-07 at 10:12 +, Duncan wrote:
>> Isn't the point, however, that if it's a die if the do* is on a file that
>> no longer exists, the maintainer will see it when they test, take care of
>> it, and as a result, it shouldn't ever hit the user?
>
> Y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
>
> Yes, you have a good point, as it applies to ebuilds. But there are still
> potential incompatibilities in the source itself that this cannot solve.
> At least for the ebuild side, perhaps we should get some sort of automate
Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Fri, 10 Aug 2007 21:19:13 +0300:
>> (OTOH, now that portage is recompressing
>> all such files based on the PORTAGE_COMPRESS setting, I suppose it's
>> possible the user screwed up their PORTAGE_COMPRESS setting. Stil
On 00:25 Sat 11 Aug , Petteri Räty wrote:
> It's not really about the amount of combinations but the amount of code
> paths in the ebuild.
Yes, you have a good point, as it applies to ebuilds. But there are still
potential incompatibilities in the source itself that this cannot solve.
At least
William L. Thomson Jr. kirjoitti:
> On Fri, 2007-08-10 at 12:32 -0700, Donnie Berkholz wrote:
>> On 22:09 Fri 10 Aug , Petteri Räty wrote:
>>> And you think maintainers are not needed to test use flags they think
>>> are uncommon?
>> I think my computer isn't powerful enough to rebuild xorg-ser
William L. Thomson Jr. wrote:
> What about distcc? Sounds like we need to get you some more powerful
> hardware to develop on or etc. Since xorg is a fairly major package.
> Understandably hard to test every time, but ideally all should be.
Well, last time I checked, PHP had about 90 USE flags. I
On Fri, 2007-08-10 at 12:32 -0700, Donnie Berkholz wrote:
> On 22:09 Fri 10 Aug , Petteri Räty wrote:
> > And you think maintainers are not needed to test use flags they think
> > are uncommon?
>
> I think my computer isn't powerful enough to rebuild xorg-server with every
> possible combinati
On 22:09 Fri 10 Aug , Petteri Räty wrote:
> And you think maintainers are not needed to test use flags they think
> are uncommon?
I think my computer isn't powerful enough to rebuild xorg-server with every
possible combination of USE flags every time I commit to it, at 45 minutes per
build.
T
Donnie Berkholz kirjoitti:
> On 12:40 Fri 10 Aug , Duncan wrote:
>> Agreed. Within the limited scope of dodoc, under what legitimate
>> circumstances might a file /not/ be there to "dodoc" for a user, when
>> it's there for a maintainer? (OTOH, now that portage is recompressing
>> all such
On 12:40 Fri 10 Aug , Duncan wrote:
> Agreed. Within the limited scope of dodoc, under what legitimate
> circumstances might a file /not/ be there to "dodoc" for a user, when
> it's there for a maintainer? (OTOH, now that portage is recompressing
> all such files based on the PORTAGE_COMPR
Duncan kirjoitti:
> Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Fri, 10 Aug 2007 10:45:15 +0300:
>
>> Alin Năstac kirjoitti:
>>> Duncan wrote:
If the user sees it, it means the maintainer failed to do his job.
The tarball couldn't have even been cha
Petteri Räty <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Fri, 10 Aug 2007 10:45:15 +0300:
> Alin Năstac kirjoitti:
>> Duncan wrote:
>>> If the user sees it, it means the maintainer failed to do his job.
>>> The tarball couldn't have even been changed upstream without notice
Alin Năstac kirjoitti:
> Duncan wrote:
>> If the user sees it, it means the maintainer failed to do his job. The
>> tarball couldn't have even been changed upstream without notice, since
>> it'd then fail the sanity/security/signing checks. I think that's the
>> suggestion, that it be mandator
Duncan wrote:
> If the user sees it, it means the maintainer failed to do his job. The
> tarball couldn't have even been changed upstream without notice, since
> it'd then fail the sanity/security/signing checks. I think that's the
> suggestion, that it be mandatory for maintainers to deal wit
On Tue, 2007-08-07 at 10:12 +, Duncan wrote:
>
> Isn't the point, however, that if it's a die if the do* is on a file that
> no longer exists, the maintainer will see it when they test, take care of
> it, and as a result, it shouldn't ever hit the user?
Yes, exactly the idea.
> If the maint
Ciaran McCreesh wrote:
> On Tue, 07 Aug 2007 09:14:17 -0400
> Richard Freeman <[EMAIL PROTECTED]> wrote:
>> If the patches are conditional then nobody else is affected anyway.
>
> And that's the issue -- this claim is incorrect. With conditional
> patching everyone is affected. A common example us
On Tue, 07 Aug 2007 09:14:17 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> If the patches are conditional then nobody else is affected anyway.
And that's the issue -- this claim is incorrect. With conditional
patching everyone is affected. A common example used to be selinux
patches that were
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
>
> I'm saying that there are plenty of past occurrences of arch teams
> applying arch-specific patches that were either outright wrong or
> really required on all archs. Most arch developers aren't familiar with
> the source of
On Mon, 06 Aug 2007 15:09:34 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > arch-specific patches are almost always wrong. The last thing people
> > need is to come along and find some arch developer has applied a bad
> > arch-specific patch without asking first...
> >
>
Mike Frysinger <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Mon, 06 Aug
2007 20:23:11 -0400:
> we're not talking developers, we're talking users. it's inappropriate
> for a user to have spent significant time compiling a package only to
> have it fail because TODO does not e
Ryan Hill kirjoitti:
> Petteri Räty wrote:
>> Steev Klimaszewski kirjoitti:
>>> Vlastimil Babka wrote:
>>>
dodoc calls should have || die and USE=doc should be tested before
commiting a bump, IMHO
>>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
>>> because TO
Petteri Räty wrote:
> Steev Klimaszewski kirjoitti:
>> Vlastimil Babka wrote:
>>
>>> dodoc calls should have || die and USE=doc should be tested before
>>> commiting a bump, IMHO
>>>
>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die
>> because TODO wasn't around. Vote against
Chris Gianelloni wrote:
>> The stabilization idea sounds good and it could free maintainers from
>> filing similar bugs over and over ; but wouldn't this be more and harder
>> work for arch teams?. For example, they should carefully track the
>> history of all the packages to know when and if they
Ciaran McCreesh wrote:
> On Fri, 03 Aug 2007 15:06:07 -0700
> Chris Gianelloni <[EMAIL PROTECTED]> wrote:
>> - arch-specific patches/dependencies - If someone is requesting
>> KEYWORD changes on a package and it requires a patch or additional
>> dependencies for your architecture, you are not only
Chris Gianelloni <[EMAIL PROTECTED]>:
[a lot of things]
everything but
> - metadata.xml changes
is ok in my eyes. Additions should be fine, but removing should be a
no-no. Emphasize on common sense and after reading the "guide" and
doing the first commit, the person should write "I will test
Steve Long kirjoitti:
> Vlastimil Babka wrote:
>> dodoc calls should have || die and USE=doc should be tested before
>> commiting a bump, IMHO
>>
> Would it not be easier to roll the || die into dodoc? I know some eclass
> functions die on error, but I haven't been able to find out what the
> defin
Tiziano Müller wrote:
> Chris Gianelloni schrieb:
>> - arch-specific patches/dependencies - If someone is requesting KEYWORD
>> changes on a package and it requires a patch or additional dependencies
>> for your architecture, you are not only permitted, but really are
>> required to make the neces
Vlastimil Babka wrote:
>
> dodoc calls should have || die and USE=doc should be tested before
> commiting a bump, IMHO
>
Would it not be easier to roll the || die into dodoc? I know some eclass
functions die on error, but I haven't been able to find out what the
definitive list is, or at least th
Chris Gianelloni schrieb:
- arch-specific patches/dependencies - If someone is requesting KEYWORD
changes on a package and it requires a patch or additional dependencies
for your architecture, you are not only permitted, but really are
required to make the necessary changes to add support for you
Steve Long wrote:
Alec Warner wrote:
Ask for forgiveness, not permission.
++ I think anything that streamlines the process is a good thing. (Obviously
I don't know enough about all the changes to comment on specifics.) Not
saying it should be done recklessly, eg SRC_URI changes. How about a s
Alec Warner wrote:
> Ask for forgiveness, not permission.
++ I think anything that streamlines the process is a good thing. (Obviously
I don't know enough about all the changes to comment on specifics.) Not
saying it should be done recklessly, eg SRC_URI changes. How about a simple
requirement th
32 matches
Mail list logo
