[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[nlopes.ml]

+1

I actually have been applying the various patches in the one I build
privately. It shouldn't be too hard to just commit them and have them
available in github. I would rather not fork though as that would make
one of us the decision makers for stuff that sometimes is not really
easy to decide on (As an example, I just saw the discussion related to
the ABI change for the nonset variable vs empty string). Instead I
would gladly give a helping hand to Lars even though I am new around
here.

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[cgit]

On Fri, Dec 16, 2011 at 05:17:30PM -0800, Norberto Lopes wrote:
> +1
> 
> I actually have been applying the various patches in the one I build
> privately. It shouldn't be too hard to just commit them and have them
> available in github. I would rather not fork though as that would make
> one of us the decision makers for stuff that sometimes is not really
> easy to decide on (As an example, I just saw the discussion related to
> the ABI change for the nonset variable vs empty string). Instead I
> would gladly give a helping hand to Lars even though I am new around
> here.

Committing patches you consider to be appropriate and publishing these
in a public branch *is* forking. The other problem is that Lars didn't
even reply to this list for ~3 months and didn't reply to private mails,
also, so I'm not sure what to do apart from creating a fork...

> 
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[jamie.couture]

Likewise.  I too can lend a hand applying / testing submissions.
I have done so already with a few that apply properly - some patches 
need to be re-submitted.

I'm not sure if a fork is necessary yet; rather, someone Lars trusts to 
pull changes from.

Also, tags haven't been signed since 0.8.1 (not sure if people care 
about that one).

On 12/16/2011 08:17 PM, Norberto Lopes wrote:
> +1
>
> I actually have been applying the various patches in the one I build
> privately. It shouldn't be too hard to just commit them and have them
> available in github. I would rather not fork though as that would make
> one of us the decision makers for stuff that sometimes is not really
> easy to decide on (As an example, I just saw the discussion related to
> the ABI change for the nonset variable vs empty string). Instead I
> would gladly give a helping hand to Lars even though I am new around
> here.
>
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

-- 
Jamie Couture

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[cgit]

On Fri, Dec 16, 2011 at 09:01:23PM -0500, Jamie Couture wrote:
> Likewise.  I too can lend a hand applying / testing submissions.
> I have done so already with a few that apply properly - some patches
> need to be re-submitted.
> 
> I'm not sure if a fork is necessary yet; rather, someone Lars trusts
> to pull changes from.

So, that means that *you* will decide which patches are ready for
mainline inclusion and Lars only merges your branch from time to time?
What's the difference to creating a fork then? Having one maintainer and
several developers that the maintainer pulls from makes sense if there
are loads of patches and/or different subsystems - it allows for sharing
work efficiently. Or if there's a lot of patches that need to be rebased
on each other and you want to assist with doing all the conflict
resolution (which obviously isn't the case here).

If you really want to help, what I'd suggest is:

* Review and test patches. Reply to mails, give feedback and tell
  contributors if there's anything that should probably be fixed. The
  more people review, the better it helps Lars.

* Try to contact Lars and ask him if there's anything else you can do to
  improve his response time. If he doesn't react for another 4 weeks or
  says that he won't be able to spend any time on developing cgit in the
  near future, we should find a new maintainer or start off a fork...

> 
> Also, tags haven't been signed since 0.8.1 (not sure if people care
> about that one).
> 
> On 12/16/2011 08:17 PM, Norberto Lopes wrote:
> >+1
> >
> >I actually have been applying the various patches in the one I build
> >privately. It shouldn't be too hard to just commit them and have them
> >available in github. I would rather not fork though as that would make
> >one of us the decision makers for stuff that sometimes is not really
> >easy to decide on (As an example, I just saw the discussion related to
> >the ABI change for the nonset variable vs empty string). Instead I
> >would gladly give a helping hand to Lars even though I am new around
> >here.
> >
> >_______________________________________________
> >cgit mailing list
> >cgit at hjemli.net
> >http://hjemli.net/mailman/listinfo/cgit
> 
> -- 
> Jamie Couture
> 
> 
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[jamie.couture]

On 12/17/2011 06:24 AM, Lukas Fleischer wrote:
> On Fri, Dec 16, 2011 at 09:01:23PM -0500, Jamie Couture wrote:
>> Likewise.  I too can lend a hand applying / testing submissions.
>> I have done so already with a few that apply properly - some patches
>> need to be re-submitted.
>>
>> I'm not sure if a fork is necessary yet; rather, someone Lars trusts
>> to pull changes from.
> So, that means that *you* will decide which patches are ready for
> mainline inclusion and Lars only merges your branch from time to time?
No, I'm not self serving - I wasn't referring to myself at all; it was 
merely a suggestion.
> What's the difference to creating a fork then? Having one maintainer and
> several developers that the maintainer pulls from makes sense if there
> are loads of patches and/or different subsystems - it allows for sharing
> work efficiently. Or if there's a lot of patches that need to be rebased
> on each other and you want to assist with doing all the conflict
> resolution (which obviously isn't the case here).
>
> If you really want to help, what I'd suggest is:
>
> * Review and test patches. Reply to mails, give feedback and tell
>    contributors if there's anything that should probably be fixed. The
>    more people review, the better it helps Lars.
>
> * Try to contact Lars and ask him if there's anything else you can do to
>    improve his response time. If he doesn't react for another 4 weeks or
>    says that he won't be able to spend any time on developing cgit in the
>    near future, we should find a new maintainer or start off a fork...
>
agreed.
>> Also, tags haven't been signed since 0.8.1 (not sure if people care
>> about that one).
>>
>> On 12/16/2011 08:17 PM, Norberto Lopes wrote:
>>> +1
>>>
>>> I actually have been applying the various patches in the one I build
>>> privately. It shouldn't be too hard to just commit them and have them
>>> available in github. I would rather not fork though as that would make
>>> one of us the decision makers for stuff that sometimes is not really
>>> easy to decide on (As an example, I just saw the discussion related to
>>> the ABI change for the nonset variable vs empty string). Instead I
>>> would gladly give a helping hand to Lars even though I am new around
>>> here.
>>>
>>> _______________________________________________
>>> cgit mailing list
>>> cgit at hjemli.net
>>> http://hjemli.net/mailman/listinfo/cgit
>> -- 
>> Jamie Couture
>>
>>
>> _______________________________________________
>> cgit mailing list
>> cgit at hjemli.net
>> http://hjemli.net/mailman/listinfo/cgit
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[mailings]

On 12/14/2011 09:44 PM, Lukas Fleischer wrote:
> On Wed, Dec 14, 2011 at 09:50:48AM -0800, Norberto Lopes wrote:
>> ---
>>  shared.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
> 
> Removing the include altogether is the right thing to here. I already
> submitted a patch [1] almost 5 months ago... No reply yet. Is it time to
> start a fork? :)
> 

yeah my thinking exactly.
lars is extremely slow in responding, I already asked him to be faster
and more interactive but that appearently didn't work.

-- 
Ferry Huberts

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[cgit]

On Wed, Dec 14, 2011 at 09:50:48AM -0800, Norberto Lopes wrote:
> ---
>  shared.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 

Removing the include altogether is the right thing to here. I already
submitted a patch [1] almost 5 months ago... No reply yet. Is it time to
start a fork? :)

> diff --git a/shared.c b/shared.c
> index 699c362..0d2a295 100644
> --- a/shared.c
> +++ b/shared.c
> @@ -8,7 +8,7 @@
>  
>  #include "cgit.h"
>  #include <stdio.h>
> -#include <linux/limits.h>
> +#include <limits.h>
>  
>  struct cgit_repolist cgit_repolist;
>  struct cgit_context ctx;
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit

[1] http://hjemli.net/pipermail/cgit/2011-July/000280.html

[PATCH] include limits.h instead of linux/limits.h for FreeBSD

[nlopes.ml]

---
 shared.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/shared.c b/shared.c
index 699c362..0d2a295 100644
--- a/shared.c
+++ b/shared.c
@@ -8,7 +8,7 @@
 
 #include "cgit.h"
 #include <stdio.h>
-#include <linux/limits.h>
+#include <limits.h>
 
 struct cgit_repolist cgit_repolist;
 struct cgit_context ctx;
-- 
1.7.7.3