On 1/28/12 1:46 AM, Geert Uytterhoeven wrote:
> On Sat, Jan 28, 2012 at 06:43, Philip Prindeville
> wrote:
>> Recently I submitted a patch for 3.2 and it was rejected because it didn't
>> include versions for early kernel releases (2.6.39, 3.0, and 3.1). Another
>> patch I suggested that was fo
On Sat, Jan 28, 2012 at 06:43, Philip Prindeville
wrote:
> Recently I submitted a patch for 3.2 and it was rejected because it didn't
> include versions for early kernel releases (2.6.39, 3.0, and 3.1). Another
> patch I suggested that was for 2.6.39 which I had extensively tested was
> reject
On 1/25/12 3:50 PM, Philip Prindeville wrote:
> [snip]
> My problem is the opposite. I use x86 hardware because it's what I have, and
> ath5k hardware for the same reason.
>
> I'm told that my patches languish because they are for 2.6.39.4 (or whatever)
> and I'm encouraged to go to a newer ker
On 1/25/12 4:07 PM, Peter Naulls wrote:
> Right, this sounds familiar, except it's with e/glibc stuff. No one
> much has tested it because it's not in SVN, etc. Moreover, it doesn't
> affect most users, and without them, e/glibc doesn't work at all.
I build with eglibc because I need the g729 co
On 01/25/2012 02:50 PM, Philip Prindeville wrote:
I'm told that my patches languish because they are for 2.6.39.4 (or
whatever)
and I'm encouraged to go to a newer kernel... but I can't because all of the
churn with the ath9k goes untested and tends to be extremely destabilizing to
the ath5k d
On 1/25/12 5:30 AM, Dave Taht wrote:
> "A second, large problem (in my mind), is that I would like to find a
> process for getting stuff upstream into the mainline kernel."
>
> Returning to handling the patch backlog:
>
> One way to perhaps help this is for the overall schedule to be more
> widel
On Wed, Jan 25, 2012 at 3:46 AM, Philip Prindeville
wrote:
> On 1/24/12 6:06 AM, Jonathan McCrohan wrote:
>> I also see svn as part of the problem. I think a move towards the
>> linux-kernel development model would be a great benefit.
>>
>> Using git would allow users to make many small fixes in t
Hello Felix,
> Does this proposal make sense? Do we have any volunteers that are
> willing to organize and take care of maintaining the tree and compile
> testing and reviewing the incoming changes?
I can offer to help with brcm47xx, x86. Also, I working on webif package (just
for your interest).
On 01/25/2012 03:46 AM, Philip Prindeville wrote:
>
> For those of us that submit fixes that then languish for months before being
> committed, wouldn't that mean having to constantly rebase them?
i don't think svn as any magic to deal with it either...
--
bye,
p.
_
On 1/24/12 6:06 AM, Jonathan McCrohan wrote:
> I also see svn as part of the problem. I think a move towards the
> linux-kernel development model would be a great benefit.
>
> Using git would allow users to make many small fixes in their own tree
> and send single a pull request for fixes to x,y a
On Tuesday 24 January 2012 15:59:18 Emmanuel Deloget wrote:
> Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit :
> > On 24/01/12 08:22, Dave Taht wrote:
> >> My principal critique of this workflow is that I tend to view svn as
> >> part of the problem to a large extent. If I do a patch in my own (
Hello,
On Tuesday 24 January 2012 21:14:23 Michael Heimpold wrote:
> Hi,
>
> > In my opinion, the main issue is not that we don't give out SVN access
> > fast enough,
>
> from my personal experience I can say that I got SVN access very quickly
> after I offered taking over maintainership for php
Hi,
> In my opinion, the main issue is not that we don't give out SVN access
> fast enough,
from my personal experience I can say that I got SVN access very quickly
after I offered taking over maintainership for php5 package.
After some months I suggested to split php into multiple packages
(for
On 2012-01-24 4:29 PM, Geert Uytterhoeven wrote:
> On Tue, Jan 24, 2012 at 16:16, Felix Fietkau wrote:
>> Probably not going to happen for the main repo. Some developers like to
>> stay with SVN. Right now I don't see a point in pushing for a complete
>> switch to git, since the svn<->git integrat
On Tue, Jan 24, 2012 at 16:16, Felix Fietkau wrote:
> Probably not going to happen for the main repo. Some developers like to
> stay with SVN. Right now I don't see a point in pushing for a complete
> switch to git, since the svn<->git integration is working just fine.
While git-svn is bidirectio
On 2012-01-24 3:57 PM, Brian J. Murrell wrote:
> On 12-01-24 08:06 AM, Jonathan McCrohan wrote:
>>
>> I also see svn as part of the problem. I think a move towards the
>> linux-kernel development model would be a great benefit.
>
> I hate sending simple "me too" posts, but to help demonstrate tha
Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit :
On 24/01/12 08:22, Dave Taht wrote:
My principal critique of this workflow is that I tend to view svn as part
of the problem to a large extent. If I do a patch in my own (git) tree
to test with, I invariably have to rebase that tree when it com
On 12-01-24 08:06 AM, Jonathan McCrohan wrote:
>
> I also see svn as part of the problem. I think a move towards the
> linux-kernel development model would be a great benefit.
I hate sending simple "me too" posts, but to help demonstrate that there
is demand for this, I too would welcome a move t
On 24/01/12 08:22, Dave Taht wrote:
> My principal critique of this workflow is that I tend to view svn as part
> of the problem to a large extent. If I do a patch in my own (git) tree
> to test with, I invariably have to rebase that tree when it comes down
> from svn.
>
> as I am frequently offli
On Mon, Jan 23, 2012 at 8:33 PM, Felix Fietkau wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also
On Mon, 23 Jan 2012 20:33:31 +0100, Felix Fietkau wrote:
As you've probably noticed, we've had issues keeping up with the
workload of incoming patches.
There is quite a bit of work involved in taking care of incoming
patches, not just review. Patches need to be compile tested, ideally
also runt
Im pretty new here but id help anyway that i can. My company mostly deals
with ar231x and ar71xx. So id be available to test both platforms daily.
On Jan 23, 2012 2:33 PM, "Felix Fietkau" wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> T
On Monday 23 Jan 2012 21:18:48 Outback Dingo wrote:
> On Mon, Jan 23, 2012 at 2:33 PM, Felix Fietkau wrote:
> > As you've probably noticed, we've had issues keeping up with the
> > workload of incoming patches.
> > There is quite a bit of work involved in taking care of incoming
> > patches, not j
On Mon, Jan 23, 2012 at 2:33 PM, Felix Fietkau wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also
On 23.01.2012 20:33, Felix Fietkau wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also runtime tes
As you've probably noticed, we've had issues keeping up with the
workload of incoming patches.
There is quite a bit of work involved in taking care of incoming
patches, not just review. Patches need to be compile tested, ideally
also runtime tested, and checked for dependency issues. Most of the
ti
26 matches
Mail list logo
