Re: [LEDE-DEV] Proposal to sign all commits

[Daniel Dickinson]

On 16-05-06 08:28 PM, Kus wrote:
> Daniel, I like what you said. I hinted something like that in the original 
> message.

Er, sorry which part - I think you mean about fast-forward only and not
the ideal world where everything is always tested no matter who it's from?

Regards,

Daniel

> 
> I don't like the idea of making changes to history after it is published. 
> Personally, I don't care about commit pollution but if the team thinks it is 
> important, then we should squash commits before we merge with master.

History should never be rewritten in a *public* (meaning one that is
supposed to be pulled from rather than a feature or staging branch that
is intended for testing and rebasing and so on) branch.  Ever. IMNSHO.

(Unless it's something like a personal tree on github that hasn't been
forked and you have no reason believe someone else has even noticed it,
yet, and you have a good reason).

In other branches only history not already in public branches should be
rewritten else you've got an ugly problem.

> In an ideal world, we'd make all commits on master and we'd have 100% 
> confidence that each commit is guaranteed to cause no regression. If wishes 
> were fishes...

Heh, if that were the case we'd be the robots that took over the world
because we were better than our human creators

> Maybe require all commits in master be signed and encourage but not require 
> signing for others? Would that be acceptable?
> 

Make sense to me.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] RFC: Throughput testing results.

[Dave Taht]

On Fri, May 6, 2016 at 4:00 PM, Ben Greear  wrote:
> On 05/06/2016 12:05 PM, David Lang wrote:
>>
>> On Fri, 6 May 2016, Ben Greear wrote:
>>
>>> On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:

 Ben Greear  writes:

> I am interested in feedback on the testing output. My goal is to add a
> few more different hardware configurations and then do nightly (or at
> least weekly) tests.


 So that is showing up to 10s of *seconds* of latency, right? (I'm not
 sure I'm reading the units right).
>>>
>>>
>>> Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
>>> RENO, and default socket sizes, so it can be at least part of the
>>> problem.
>>
>>
>> That's so much latency that you may as well be down.
>>
>> Please look at the make-wifi-fast mailing list and the tests that are
>> being done there. they show latency spikes as well as throughput, and show
>> how it is very
>> possible to get low latency without affecting throughput (in some cases,
>> throughput actually increases)
>
>
> I did some tcp/udp mix, tcp only, udp only download tests, with fq_codel and
> fifo-fast on the traffic
> generator.  AP was un-changed, seems LEDE uses fq_codel by default.
> Generator is using 4.4.8+ kernel, and it looks
> like fq_codel works nicely!
>
> http://www.candelatech.com/examples/ventana/
>
> We'll run some tests on some of our higher-performing APs and see if
> fq_codel works well there
> too when we get a chance

At the qdisc layer fq_codel is presently at, it is still difficult to
remove baseline latency at lower speeds nor serve multiple stations
well.

we can do much better with the patches that michal is working on

http://blog.cerowrt.org/flent/qca-10.2-fqmac35-codel-5-wifi/slow_fast_simultaneously.svg

The blog series analyzing the impact of these patches is at:
http://blog.cerowrt.org/tags/wifi/

starting, basically, here:

http://blog.cerowrt.org/post/fq_codel_on_ath10k/

It would be good to also get an ath9k and mt72 version working

> Thanks,
> Ben
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] RFC: Throughput testing results.

[David Lang]

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 12:05 PM, David Lang wrote:

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:

Ben Greear  writes:


I am interested in feedback on the testing output. My goal is to add a
few more different hardware configurations and then do nightly (or at
least weekly) tests.


So that is showing up to 10s of *seconds* of latency, right? (I'm not
sure I'm reading the units right).


Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
RENO, and default socket sizes, so it can be at least part of the problem.


That's so much latency that you may as well be down.

Please look at the make-wifi-fast mailing list and the tests that are being 
done there. they show latency spikes as well as throughput, and show how it 
is very
possible to get low latency without affecting throughput (in some cases, 
throughput actually increases)


I understand that.  My test case is fairly abusive, and my generator is not 
optimized for

low-latency at this time.

In many cases, throughput does go down though, so I have been slow to try the 
buffer bloat stuff.  I can run some tests with codel enabled sometime soon.


I can also run my capacity test with UDP only.  That might be better for pure 
throughput testing.  My hope is to be able to show regressions/improvements 
over time as LEDE changes...


This is a good idea, but it is going to be very specific to the exact setup you 
use for the testing. Use different hardware, or add/remove nodes from the test 
(or have someone nearby create additional noise) and you can end up with very 
different results.


I think it would be a bad idea to setup something that encourages chasing 
benchmarks. I agree it's a good idea to watch out for regressions. The hard 
thing is doing the latter without the former :-)


David Lang___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] RFC: Throughput testing results.

[David Lang]

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:

Ben Greear  writes:


I am interested in feedback on the testing output. My goal is to add a
few more different hardware configurations and then do nightly (or at
least weekly) tests.


So that is showing up to 10s of *seconds* of latency, right? (I'm not
sure I'm reading the units right).


Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
RENO, and default socket sizes, so it can be at least part of the problem.


That's so much latency that you may as well be down.

Please look at the make-wifi-fast mailing list and the tests that are being done 
there. they show latency spikes as well as throughput, and show how it is very 
possible to get low latency without affecting throughput (in some cases, 
throughput actually increases)


David Lang___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] A change to the way packages are built

[Daniel Dickinson]

On 16-05-05 04:16 AM, Michal Hrusecky wrote:
> David Lang - 18:20  4.05.16 wrote:
>> Debian has ...
> 
> Just for the sake of discussion and inspiration, how openSUSE does it's 
> rolling
> release. We have OBS, which is server software, connected to multiple 
> builders.

[snip]

Thank you David and Michal for the info.  I'll try to make some time to
look into both of these options and see if they can be used with and
openwrt SDK to do what we're looking for (well at the least to get
started on).

I also have to look a Jo's buildbot stuff to see how things are done
currently for LEDE.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Proposal to sign all commits

[Kus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


> Regarding signing commits with GPG key, it would be nice to recommend it but 
> making it a requirement sounds like a barrier.

I'd argue such a barrier is OK if we want to quickly increase the size of the 
team of people with commit access. I think we're underestimating our 
contributors here. I agree that we shouldn't have unnecessary barriers (such as 
copyright assignment to give a specific example).

I am getting mixed signals here though. Some people say requiring signing 
causes friction and limits participation. Others say that there will only be a 
couple of people who will ever have commit access so signing is unnecessary.

I don't want to take too much time here because signing commits is a lower 
priority compared to doing the actual work of writing code/documentation 
(including a wiki), increasing/maintaining test coverage, and setting up 
automatic signed builds and so on (being discussed in separate threads).

I don't think there's a definite right or wrong answer here as long as we 
understand and accept the trade offs.

Sincerely,
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQJRBAEBCgA7BQJXLL6NNBxLdXNoYWwgSGFkYSAoZGV2ZWxvcGVyKSA8a3VzaGFs
ZGV2ZWxvcGVyQGdtYWlsLmNvbT4ACgkQJsInd2b1xmPv9w/+Km0COpDHFHWjahVX
XCGZdokz4BZn41ZF54R4z7iyexzZ9uviLJfQyftHODHYCvdl/P+zA3WYX2nyEQ5j
zDIkXuGKmrG68zt55Y2layVgOrqJ3BswwdkFhG7mFEyvTJQDWYp50F6a9JjURZmB
x1YCUO7fQidrmjOYdE9omEeJCBukujGtBFG1i2YxGPHA8hWANxB+hZD5AZHouNto
i5YG7ssjJXusdoCtReIxUsimUwQ6s5IqSiOSZPwlGGl3lTj4rVcQtUNZzTlwBRsL
3VEAAlXNd6Kl0oKaet9wVJNwiF3nrDiLAgwTjS2T5ZIe5l4+TwcSAsN3xJUAe1tx
7ysWFEbgYNLxXuI8cvEXr9g9n7BW3QnbgQzpgadjQisGeIOzwsCirpGKrSBJDXVP
RDClZQe9FhJ4edxgWig4htvH4eHsyyzic0RDaG+70aSNlWS4gVniAZ+dvn4cxnlF
22v7Ryl/Sb3dmhub2bQVVP4TZyYityNNfyW74cODj4mx2cYYwEhVEIAbvKz+ZE7r
D6T2svtOSJpaPBGKL4JGhXxdwo6UZJucA13h3nrxYH+nHlm6v0xHWkV955LyP976
SYS7Nw6Opw0L66L5jAJjQ3z6+YAabd00AmxWMnL6pMJk3k8sY8sH45CLghCvQNzr
xeFklDOsle8MwWAuuBb9CMB1OLI=
=bVJi
-END PGP SIGNATURE-


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Why technical elitism is contrary to stated goal of community

[David Woodhouse]

On Fri, 2016-05-06 at 11:48 -0400, Daniel Curran-Dickinson wrote:
> > As I said, the issue is not with 'only good bug reports', it's with 'we
> > can ensure only good bug reports by making it a pain to report bugs at all'.
> 
> I'd also like to point out that if the approach is being taken on the
> assumption that on technically advanced people write good reports, then
> I'd like to point out that
> 
> a) There are plenty of technically advanced people who really suck at
> writing good bug reports
> b) There are a goodly number of noobs who given the right
> prompts/prompting can give better bug reports than even many technically
> advanced users who aren't in a).
> c) There are going to be bad bug reports no matter how badly you try to
> avoid it
> d) Making it hard to report bugs means that bugs don't get reported,
> even in cases where all you needed to fix the bug was to know it existed.

All very true. It's also worth noting that if you are "guided" too hard
to include information which you don't have or can't accurately
provide, or which is irrelevant in your specific case, then you often
end up making stuff up and that *detracts* from the quality of the
report.

I have a lot of expense reports where the mandatory "Business purpose?"
field has the simple answer "yes" :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Why technical elitism is contrary to stated goal of community

[Daniel Dickinson]

Hi all,

I have noticed that some of the policies of this project are already
veering towards a brand of technical elitism that I feel is completely
contrary to the stated goal of having a stronger community.

A strong community welcomes 'outsiders' and noobs and helps them find
their place in the community and *helps* them learn how to to
participate in a friendly, open manner.

Technical elitism tends give a 'you're not good enough / you don't think
like us, go away' feel to a community.  The 'we won't event look at your
bug report if it doesn't meet the special format we came up with that no
one else uses' policy is I fear an example of this.  I realize the
reason for it is to try and get better quality bug reports, and less
ones that aren't useful, but I don't think that is necessarily a good
way to about it.

If LEDE is *serious* about community some of it's core members need to
rethink how they approach contributions and the project.  Perhaps time
is the issue, and perhaps the issue is attitude, or perhaps it's a bit
of both.  Either way, if nothing genuinely changes from what was the
case in OpenWrt, this project and OpenWrt will both die.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Proposal to sign all commits

[Jo-Philipp Wich]

Hi,

> I am concerned that git signing gives little, if any value, while making
> it harder to contribute (and making it easier to contribute is one of
> the *stated* goals of LEDE) and is another example of a tendency toward
> a particular brand of technical elitism that will kill this project if
> not nipped in the bud.

I tend to agree here - people specifically ask about being able to
contribute via Github because it allegedly makes contributions easier.

My experience has shown that a lot of contributors already struggle with
the concept of sign-off lines. Require them to PGP sign stuff would
pretty much kill any effort in this direction right away.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Introducing the LEDE project

[Daniel Dickinson]

Might I submit that my impression is that Kaloz (at least) holds
infrastructure hostage to maintain control, and that the fundamental
problem here is that OpenWrt is *not* democratic and ignores what people
who were ones visibly working on openwrt want and overrides their wishes
because he/they has/have the keys.

That doesn't work.  Perhaps I'm wrong, but that is certainly my impression.

There isn't management for openwrt except by democratic/meritocratic
principles, and no one should try to force it to be otherwise.

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [OpenWrt-Devel] Introducing the LEDE project

[Roman Yeryomin]

On 6 May 2016 at 03:53, Luka Perkov  wrote:
>>On 2016-05-05 20:22, mbm wrote:
>>> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
 Many of the changes that we previously tried to introduce were often
 squashed by internal disagreements. Resulting discussions often turned
 toxic quickly and led to nothing being done to address the issues.
 Setting up the LEDE project was our way of creating a testbed for
 changes that we believe are important for the survival of the project.
>>>
>>> Change is not easy. Discussions need to happen. The problem is simply
>>> kicking out people you didn't agree with by starting a new organization
>>> in secret; you've created the public perception that we're somehow
>>> against you when really we all want the same things.
>>
>> Years of internal discussion led nowhere. Maybe it helps now that we're
>> making the whole issue public.
>
> For the sake of transparency, we've had public discussions, about a number of
> things, for example switching to Git:
>
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html
>
> And based on these inputs from you the switch was not made even though several
> OpenWrt developers wanted to switch.
>
> Also, server outages can happen to anybody:
> - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html
>
> However, we do not want to point fingers. What we do want is to make a great
> community around OpenWrt and to drive innovation - just like it has been done
> for more then a decade now.
>
> There has been a long history - mostly good, sometimes bad - since the project
> started from a garage project, to now having a project used by an awesome
> amount of users. This can be seen from the constructive discussions in this
> list on a daily basis, and in this very thread. Also, the project is used as
> the main SDK by many silicon vendors internally, and by vast number of
> companies on the embedded market.
>
> We are open for a discussion and would like to keep the OpenWrt's and it's
> community interests in the first place. Splitting the project does not make
> sense. Do you agree?
>
 We appreciate your effort to have an open discussion about this,
 however the sudden deletion of our widely published openwrt.org email
 addresses somewhat undermines this. We will not respond in kind and we
 will continue to maintain the critical parts of OpenWrt infrastructure
 that we control.
>>>
>>> Let's be clear on this subject; no commit access was revoked, you still
>>> have full read and write access to the entire OpenWrt tree.
>>>
>>> Email forwarding was temporarily disabled following the LEDE announcement
>>> - LEDE's own rules prohibit project based email addresses
>> No, they don't. They state that the LEDE project won't provide project
>> email addresses. Interpreting that as meaning that we shouldn't be able
>> to access our openwrt.org addresses is more than a bit of a stretch.
>
> In any case, due to the events that happened and the fact that the OpenWrt 
> name
> is being used in a manner opposite of the projects best interest, we felt that
> these actions were needed in order to avoid the further damages to the 
> project.
>
>>> - It's unclear if LEDE still represents OpenWrt
>> So? Asking us to not send any further emails about LEDE from our
>> openwrt.org addresses should have been enough.
>
> Actually, this was discussed on #lede-adm.

IRC history is hard to follow, I'd better assume that something not
written here never happened.

Regards,
Roman

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev