On 06.04.2013 20:08, Michał Górny wrote:
> Hello,
>
> As far as I'm aware, we don't really have much of a patch maintenance
> policy in Gentoo. There a few loose rules like «don't put awfully big
> files into FILESDIR» or the common sense «use unified diff», but no
> complete and clear policy.
>
On Sat, 06 Apr 2013 13:00:35 -0700
""Paweł Hajdan, Jr."" wrote:
> On 4/6/13 12:41 PM, Michał Górny wrote:
> > I would honestly just go for the git style. It's the first thing that
> > really succeeded in standardizing patches. Inventing something new is
> > not really necessary, I believe.
>
> O
On Sat, Apr 06, 2013 at 08:08:43PM +0200, Michał Górny wrote:
> The above-listed policy will apply to the patches kept in the gx86 tree
> (in FILESDIRs) and patch archives created by Gentoo developers. They
> will not apply to the patch archives created upstream.
What about patches created by upstr
# Ryan Hill (06 Apr 2013)
# Restrictive licence, basically demo versions of paid software. 14 versions
# have been released in the past 4 years and not one person has requested a
# bump. Use dev-util/codeblocks for all your wxWidgets IDE needs.
# Bug #464768. Removal May 5/13.
dev-util/dialogblo
On 4/6/13 12:41 PM, Michał Górny wrote:
>>> 6. Patch files shall start with a brief description of what the patch
>>> does. Developers are encouraged to use git-style tags like 'Fixes:' to
>>> point to the relevant bug URIs.
>>
>> That could be helpful - could this be made more precise though? Is t
On Sat, 06 Apr 2013 12:02:28 -0700
""Paweł Hajdan, Jr."" wrote:
> On 4/6/13 11:08 AM, Michał Górny wrote:
> > 5. The patch name shall shortly summarize the changes done by it.
>
> Common sense again. :) And I agree that patches should do that, the
> question is just whether we put common sense i
On 06/04/13 03:02 PM, "Paweł Hajdan, Jr." wrote:
> Are there any other formats than unified and context diff? If not, it'd
> be like another "for indoor or outdoor use only" or "home or office use"
> - i.e. no need to explicitly list all possible options.
From the man page:
> -c, -C NUM, --contex
On 4/6/13 11:08 AM, Michał Górny wrote:
> 1. Patches have to be either in unified or context diff format. Unified
> diff is preferred.
Are there any other formats than unified and context diff? If not, it'd
be like another "for indoor or outdoor use only" or "home or office use"
- i.e. no need to
On Apr 6, 2013 2:36 PM, "Alexandre Rostovtsev" wrote:
>
> On Sat, 2013-04-06 at 20:08 +0200, Michał Górny wrote:
> > 2. Patches have to apply to the top directory of the source tree with
> > 'patch -p1'. If patches are applied to sub-directories, necessary '-p'
> > argument shall be passed to 'epa
On Sat, 06 Apr 2013 14:35:47 -0400
Alexandre Rostovtsev wrote:
> On Sat, 2013-04-06 at 20:08 +0200, Michał Górny wrote:
> > 2. Patches have to apply to the top directory of the source tree with
> > 'patch -p1'. If patches are applied to sub-directories, necessary '-p'
> > argument shall be passed
On Sat, 2013-04-06 at 20:08 +0200, Michał Górny wrote:
> 2. Patches have to apply to the top directory of the source tree with
> 'patch -p1'. If patches are applied to sub-directories, necessary '-p'
> argument shall be passed to 'epatch' explicitly. Developers are
> encouraged to create patches wh
On 6 April 2013 19:08, Michał Górny wrote:
> Hello,
>
> ...
> What are your thoughts?
Maybe it is time to setup a patch tracking system like Debian[1]?
Sometimes it is really hard to understand what patches are applied by
an ebuild (especially when all the
build process is handled by an eclass)
On Sat, 2013-04-06 at 20:08 +0200, Michał Górny wrote:
> What are your thoughts?
Sensible document. Can we have it on the agenda for the council meeting
please. It looks suitable for a yes/no vote, and I expect some guidance
from the wider developer community in how they respond on the list.
Rega
Hello,
As far as I'm aware, we don't really have much of a patch maintenance
policy in Gentoo. There a few loose rules like «don't put awfully big
files into FILESDIR» or the common sense «use unified diff», but no
complete and clear policy.
Especially considering the late discussion related to t
On Sat, 6 Apr 2013 16:27:33 +0100
Ciaran McCreesh wrote:
> On Sat, 6 Apr 2013 11:13:36 -0400
> Mike Gilbert wrote:
> > I'm just not sure how the package managers like an in-place EAPI
> > change. If it works, great.
>
> If you don't revbump when going from an EAPI that doesn't have
> subslots t
On Sat, 6 Apr 2013 11:13:36 -0400
Mike Gilbert wrote:
> I'm just not sure how the package managers like an in-place EAPI
> change. If it works, great.
If you don't revbump when going from an EAPI that doesn't have subslots
to one that does, and then people start using subslot deps upon that
packa
On Sat, Apr 6, 2013 at 11:09 AM, Alexis Ballier wrote:
> On Sat, 6 Apr 2013 11:02:14 -0400
> Mike Gilbert wrote:
>
>> On Sat, Apr 6, 2013 at 10:33 AM, Alexis Ballier
>> wrote:
>> > On Fri, 05 Apr 2013 22:18:22 -0400
>> > Ian Stakenvicius wrote:
>> >
>> >>
>> >> Revbump -- very important in this
On Sat, 6 Apr 2013 11:02:14 -0400
Mike Gilbert wrote:
> On Sat, Apr 6, 2013 at 10:33 AM, Alexis Ballier
> wrote:
> > On Fri, 05 Apr 2013 22:18:22 -0400
> > Ian Stakenvicius wrote:
> >
> >>
> >> Revbump -- very important in this case, as the slot-operator dep
> >> (iirc) does not take effect to
On Sat, Apr 6, 2013 at 10:33 AM, Alexis Ballier wrote:
> On Fri, 05 Apr 2013 22:18:22 -0400
> Ian Stakenvicius wrote:
>
>>
>> Revbump -- very important in this case, as the slot-operator dep
>> (iirc) does not take effect to allow sub-slot-triggered until after a
>> version with the slot-operator
On Fri, 05 Apr 2013 22:18:22 -0400
Ian Stakenvicius wrote:
>
> Revbump -- very important in this case, as the slot-operator dep
> (iirc) does not take effect to allow sub-slot-triggered until after a
> version with the slot-operator has been emerged.
>
> So we want users to re-emerge packages e
20 matches
Mail list logo
