On Jul 24, 2014, at 12:43 AM, Mojca Miklavec wrote:
> On Thu, Jul 24, 2014 at 3:18 AM, Ryan Schmidt wrote:
>>
>> On Jul 23, 2014, at 9:31 AM, mo...@macports.org wrote:
>
>>> --- trunk/dports/_resources/port1.0/group/perl5-1.0.tcl 2014-07-23
>>> 14:29:55 UTC (rev 122520)
>>> +++ trunk/dpo
On 2014-7-24 01:20 , Mojca Miklavec wrote:
> One slightly easier step-by-step approach could be the following
>
> 1.) Replace
> perl5.branches 5.14 5.16 5.18
> in all perl modules with
> perl5.branches_blacklist 5.8 5.10 5.12
> or to remove branche_blacklist altogether if the module b
Hi all,
I am wondering if there is a well defined policy regarding maintainer ship for
new ports.
I understand that it is quite usual to assume maintainer ship when contributing
a new port and that nomantainer is more usual for abandoned ports. But is it
usual to commit new ports as with `nom
On 7/24/14 4:25 AM, p...@macports.org wrote:
> Hi all,
> I am wondering if there is a well defined policy regarding maintainer ship
> for new ports.
>
> I understand that it is quite usual to assume maintainer ship when
> contributing a new port and that nomantainer is more usual for abandoned
On Jul 24, 2014, at 7:13 AM, p...@macports.org wrote:
> Revision
> 122588
> Author
> p...@macports.org
> Date
> 2014-07-24 05:13:58 -0700 (Thu, 24 Jul 2014)
> Log Message
>
> zope-* : add modeline to all zope ports
But the zope ports I checked don't actually conform to the modeline. If you're
On 24 Jul 2014, at 14:22, Ryan Schmidt wrote:
>
> On Jul 24, 2014, at 7:13 AM, p...@macports.org wrote:
>
>> Revision
>> 122588
>> Author
>> p...@macports.org
>> Date
>> 2014-07-24 05:13:58 -0700 (Thu, 24 Jul 2014)
>> Log Message
>>
>> zope-* : add modeline to all zope ports
>
> But the zope
On Jul 24, 2014, at 7:24 AM, p...@macports.org wrote:
>
> On 24 Jul 2014, at 14:22, Ryan Schmidt wrote:
>
>>
>> On Jul 24, 2014, at 7:13 AM, p...@macports.org wrote:
>>
>>> Revision
>>> 122588
>>> Author
>>> p...@macports.org
>>> Date
>>> 2014-07-24 05:13:58 -0700 (Thu, 24 Jul 2014)
>>> Log
Do you also have the years when Apple made each of these versions its
system perl as well?
On Wed, Jul 23, 2014 at 7:59 PM, Mark Anderson wrote:
> Yeah, I'm with Daniel here. I think we should only support the latest
> version of Perl.
>
> From perl.org: "*We recommend that you always run the l
On Wed, Jun 4, 2014 at 4:18 PM, "René J.V. Bertin"
wrote:
>
> On Jun 04, 2014, at 20:21, Eric Gallager wrote:
>
> > Wow, that looks a lot simpler than I thought that it would be... I was
> expecting something like this would have to be fixed upstream by gcc,
> because that is how they handle the
On Jul 24, 2014, at 12:48 AM, Mojca Miklavec wrote:
> So far I’m hitting a few bumps with p5.20-digest-sha1 [1] and p5.18-pdl not
> compiling. I can’t even try p5.20-pdl until p5.20-digest-sha1 is fixed.
>
> The digest-sha1 works for me, pdl takes a bit longer, but eventually
> fails for me as
Hi all,
I am not a zope user, but I came across some problems with `zope-*` ports.
Looking a bit around I am wondering what might actually be the status and usage
of zope and related ports. The ports seem to have no maintainer already for
quite some while and most maintenance seem to be relate
Am 24.07.2014 um 18:50 schrieb p...@macports.org:
> I am not a zope user, but I came across some problems with `zope-*` ports.
> Looking a bit around I am wondering what might actually be the status and
> usage of zope and related ports. The ports seem to have no maintainer already
> for quite
David Evans writes:
> On 7/24/14 4:25 AM, p...@macports.org wrote:
>> Hi all,
>> I am wondering if there is a well defined policy regarding maintainer ship
>> for new ports.
>>
>> I understand that it is quite usual to assume maintainer ship when
>> contributing a new port and that nomantainer
On Jul 24, 2014, at 2:37 PM, Sean Farley wrote:
>
> Why not drop 'openmaintainer' and amend the community policy to have
> every port be what we now call 'openmaintainer'? Furthermore, we could
> set up a way for the listed port authors to be emailed when a port with
> their name on it has change
A compromise here could be, instead of getting rid of openmaintainer
entirely, or keeping it opt-in like it currently is, we could make it
opt-out instead. There are two ways we could do this:
1. When committing new ports submitted by users without commit access, make
it a policy to automatically
Daniel J. Luke writes:
> On Jul 24, 2014, at 2:37 PM, Sean Farley wrote:
>>
>> Why not drop 'openmaintainer' and amend the community policy to have
>> every port be what we now call 'openmaintainer'? Furthermore, we could
>> set up a way for the listed port authors to be emailed when a port wit
On Jul 24, 2014, at 4:55 PM, Sean Farley wrote:
>
>> I, for one, appreciate the ability to specify which ports I don't care if
>> people apply patches to vs. ports where I'm very careful about
>> updating/keeping things from breaking.
>
> Well, the problem is people still commit on your ports.
* On 24.07.2014 11:49 pm, Daniel J. Luke wrote:
>> Unless you've
>> left comments in your portfiles, then there's no auditable way to
>> maintain your ports if, say, you stop being a maintainer.
> I can't parse this sentence. "no auditable way" what are you auditing?
Don't nitpick. :)
He means th
Daniel J. Luke writes:
> On Jul 24, 2014, at 4:55 PM, Sean Farley wrote:
>>
>>> I, for one, appreciate the ability to specify which ports I don't care if
>>> people apply patches to vs. ports where I'm very careful about
>>> updating/keeping things from breaking.
>>
>> Well, the problem is p
Mihai Moldovan writes:
> * On 24.07.2014 11:49 pm, Daniel J. Luke wrote:
>>> Unless you've
>>> left comments in your portfiles, then there's no auditable way to
>>> maintain your ports if, say, you stop being a maintainer.
>> I can't parse this sentence. "no auditable way" what are you auditing?
20 matches
Mail list logo
