From nbd at nbd.name  Mon Dec  5 10:50:10 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Mon, 5 Dec 2016 19:50:10 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
Message-ID: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>

Hello LEDE team,

we recently had a very constructive discussion between the 2 project
teams regarding the next step of a more than likely remerge in the near
future.

As a step towards that common goal, we all agreed, that consolidating
the two trees is the first and most important step that we need to take.
It was agreed that the easiest and fastest way to do so is merging the
delta from OpenWrt into the LEDE tree.

To make this work, we would like to grant LEDE commit access and voting
rights to Imre, Zoltan and Luka. To speed things up we would like to set
a 24 hour grace period for the very unlikely case of anyone wanting to
veto this.

Thanks,

Daniel
Felix
John
Jonas
Lynxis
Hans
Hauke
Mathias
Matthias
Rafa?



From richb.hanover at gmail.com  Tue Dec  6 06:34:07 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 09:34:07 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
Message-ID: <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>


> On Dec 5, 2016, at 1:50 PM, Felix Fietkau <nbd at nbd.name> wrote:
> 
> Hello LEDE team,
> 
> we recently had a very constructive discussion between the 2 project
> teams regarding the next step of a more than likely remerge in the near
> future.
> 
> As a step towards that common goal, we all agreed, that consolidating
> the two trees is the first and most important step that we need to take.
> It was agreed that the easiest and fastest way to do so is merging the
> delta from OpenWrt into the LEDE tree.
> 
> To make this work, we would like to grant LEDE commit access and voting
> rights to Imre, Zoltan and Luka. To speed things up we would like to set
> a 24 hour grace period for the very unlikely case of anyone wanting to
> veto this.

ACK for me.

Thanks for all the work on this. I'll send a separate followup message with questions for the future.

> 
> Thanks,
> 
> Daniel
> Felix
> John
> Jonas
> Lynxis
> Hans
> Hauke
> Mathias
> Matthias
> Rafa?
> 
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



From vincenzo.romano at notorand.it  Tue Dec  6 06:45:14 2016
From: vincenzo.romano at notorand.it (Vincenzo Romano)
Date: Tue, 6 Dec 2016 15:45:14 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>
Message-ID: <CAHjZ2x5ZRNuphzhjqbO1N0S_h7ByeO8dKudEd+ZoMxHbNGiPKQ@mail.gmail.com>

I see only positive values in such an approach.
Fragmentation won't help. Fragmentation will fragment also the user
base making both communities less relevant.
Thanks a lot from all you guys.
Thus it's a "go" for me.
--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
cel. +39 339 8083886
tel. +39 0823 454163
fax. +39 02 700506964
--
NON QVIETIS MARIBVS NAVTA PERITVS


2016-12-06 15:34 GMT+01:00 Rich Brown <richb.hanover at gmail.com>:
>
>> On Dec 5, 2016, at 1:50 PM, Felix Fietkau <nbd at nbd.name> wrote:
>>
>> Hello LEDE team,
>>
>> we recently had a very constructive discussion between the 2 project
>> teams regarding the next step of a more than likely remerge in the near
>> future.
>>
>> As a step towards that common goal, we all agreed, that consolidating
>> the two trees is the first and most important step that we need to take.
>> It was agreed that the easiest and fastest way to do so is merging the
>> delta from OpenWrt into the LEDE tree.
>>
>> To make this work, we would like to grant LEDE commit access and voting
>> rights to Imre, Zoltan and Luka. To speed things up we would like to set
>> a 24 hour grace period for the very unlikely case of anyone wanting to
>> veto this.
>
> ACK for me.
>
> Thanks for all the work on this. I'll send a separate followup message with questions for the future.
>
>>
>> Thanks,
>>
>> Daniel
>> Felix
>> John
>> Jonas
>> Lynxis
>> Hans
>> Hauke
>> Mathias
>> Matthias
>> Rafa?
>>
>>
>> _______________________________________________
>> lede-adm mailing list
>> lede-adm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-adm
>
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm


From richb.hanover at gmail.com  Tue Dec  6 06:47:11 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 09:47:11 -0500
Subject: Re-integrating LEDE and OpenWrt communities
Message-ID: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>

In light of the strong statement of support from nbd and the rest of the LEDE team, I am completely in favor of granting OpenWrt core developers commit access to the LEDE repo.

Have there been any discussions about the process of re-integrating the communities, and the infrastructure sites, documentation, forums, etc? What is the best way to continue that discussion?

Best regards, 

Rich

From jo at mein.io  Tue Dec  6 06:57:08 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 6 Dec 2016 15:57:08 +0100
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
Message-ID: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>

Hi Rich,

in our previous telephone conference this topic was more or less postponed.

Ideally I'd like to let the community decide by itself with the
LEDE/OpenWrt/whatever project merely providing the resources and some
technical help.

There's obviously a problem with having two forums, two wikis etc. in
the long run and I personally see the largest pain points with the forum
as LEDE's current choice of discourse seems to provoke some rather
strong like and dislike reactions.

Unifying the wiki should be easier imho as there's a large overlap in
information and implementation there.

I'd say the best that can be done currently is to wait and see how
things shape out in the end to avoid unnecessary, preliminary work.


~ Jo


From david at lang.hm  Tue Dec  6 07:05:02 2016
From: david at lang.hm (David Lang)
Date: Tue, 6 Dec 2016 07:05:02 -0800 (PST)
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
 <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
Message-ID: <nycvar.QRO.7.75.62.1612060703080.21122@qynat-yncgbc>

On Tue, 6 Dec 2016, Jo-Philipp Wich wrote:

> There's obviously a problem with having two forums, two wikis etc. in
> the long run and I personally see the largest pain points with the forum
> as LEDE's current choice of discourse seems to provoke some rather
> strong like and dislike reactions.

I really dislike accessing the LEDE forum via a browser, but because I can 
have new posts show up in my e-mail and reply directly (wihtout having to go 
look for new posts), I am able to contribute without ever looking at the forum, 
which I like

:-)

David Lang


From richb.hanover at gmail.com  Tue Dec  6 07:08:13 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 10:08:13 -0500
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
 <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
Message-ID: <276358C6-8B7B-4DE4-B6C7-D64C952FF7F1@gmail.com>

Hi Jo,

I think this is the perfect answer, given the state of the discussions. I don't think any action/work is required at this time.

I throw out the question now so that our collective minds can begin to chew on the problem in the background to see if there are good solutions. (I agree that the forum choice seems harder to resolve than the wiki...)

Best regards,

Rich

> On Dec 6, 2016, at 9:57 AM, Jo-Philipp Wich <jo at mein.io> wrote:
> 
> Hi Rich,
> 
> in our previous telephone conference this topic was more or less postponed.
> 
> Ideally I'd like to let the community decide by itself with the
> LEDE/OpenWrt/whatever project merely providing the resources and some
> technical help.
> 
> There's obviously a problem with having two forums, two wikis etc. in
> the long run and I personally see the largest pain points with the forum
> as LEDE's current choice of discourse seems to provoke some rather
> strong like and dislike reactions.
> 
> Unifying the wiki should be easier imho as there's a large overlap in
> information and implementation there.
> 
> I'd say the best that can be done currently is to wait and see how
> things shape out in the end to avoid unnecessary, preliminary work.
> 
> 
> ~ Jo
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



From jo at mein.io  Thu Dec  8 03:17:47 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 8 Dec 2016 12:17:47 +0100
Subject: Scheduled Discourse maintenance
Message-ID: <240b6090-09ac-e6eb-e6af-c2905d2f78b4@mein.io>

Hi,

Digital Ocean informed us that the Hypervisor running the Discourse
forum instance is undergoing maintenance from December the 15th at
02:00 UTC until 06:00 UTC.

A minimal downtime of a few minutes within that time frame is expected.


Regards,
Jo


From ynezz at true.cz  Thu Dec  8 07:38:43 2016
From: ynezz at true.cz (Petr =?iso-8859-2?Q?=A9tetiar?=)
Date: Thu, 8 Dec 2016 16:38:43 +0100
Subject: Donations?
In-Reply-To: <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
 <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
Message-ID: <20161208153843.GF17320@ibawizard.net>

Rich Brown <richb.hanover at gmail.com> [2016-10-28 14:49:54]:

Hi Rich,

> - I looked into one such site - gofundme.com. They take 5.3 % of the amount.
> I think (in the US) we might avoid a separate legal structure, since
> gofundme.com also says that most donations would be treated as personal
> gifts, and thus not taxable. I will ask my accountant, and report back.

any news regarding this topic? Thanks.

-- ynezz


From john at phrozen.org  Thu Dec  8 07:42:33 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 8 Dec 2016 16:42:33 +0100
Subject: Donations?
In-Reply-To: <20161208153843.GF17320@ibawizard.net>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
 <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
 <20161208153843.GF17320@ibawizard.net>
Message-ID: <9528eeac-edaf-3668-419f-f683f2895dbe@phrozen.org>



On 08/12/2016 16:38, Petr ?tetiar wrote:
> Rich Brown <richb.hanover at gmail.com> [2016-10-28 14:49:54]:
> 
> Hi Rich,
> 
>> - I looked into one such site - gofundme.com. They take 5.3 % of the amount.
>> I think (in the US) we might avoid a separate legal structure, since
>> gofundme.com also says that most donations would be treated as personal
>> gifts, and thus not taxable. I will ask my accountant, and report back.
> 
> any news regarding this topic? Thanks.
> 
> -- ynezz
> 

owrt has received 5,000+K$ of donations via the SPI in the last years. i
think that once the remerge has become a reality we should use the SPI
for donations.

	John

> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
> 


From john at phrozen.org  Sat Dec 10 01:37:39 2016
From: john at phrozen.org (John Crispin)
Date: Sat, 10 Dec 2016 10:37:39 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
Message-ID: <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>



On 05/12/2016 19:50, Felix Fietkau wrote:
> Hello LEDE team,
> 
> we recently had a very constructive discussion between the 2 project
> teams regarding the next step of a more than likely remerge in the near
> future.
> 
> As a step towards that common goal, we all agreed, that consolidating
> the two trees is the first and most important step that we need to take.
> It was agreed that the easiest and fastest way to do so is merging the
> delta from OpenWrt into the LEDE tree.
> 
> To make this work, we would like to grant LEDE commit access and voting
> rights to Imre, Zoltan and Luka. To speed things up we would like to set
> a 24 hour grace period for the very unlikely case of anyone wanting to
> veto this.
> 
> Thanks,
> 
> Daniel
> Felix
> John
> Jonas
> Lynxis
> Hans
> Hauke
> Mathias
> Matthias
> Rafa?
> 

with no vetos or worries being announced, could the owrt guys please
send their ssh keys ? once the ssh keys were added you also need to add
yourselves to the keyring.git tree. there was a howto that might not yet
have been moved to the wiki. i'll try to figure that one out today.

	John


From openwrt at vittgam.net  Sat Dec 10 13:02:00 2016
From: openwrt at vittgam.net (Vittorio G (VittGam))
Date: Sat, 10 Dec 2016 22:02:00 +0100
Subject: =?UTF-8?Q?Donations=3F?=
In-Reply-To: <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
Message-ID: <8f6d92ebf91818ea3e9a716b4002089a@vittgam.net>

Hello,

On 28/10/2016 17:15:19 CEST, Jo-Philipp Wich wrote:
> - 3x 49,00 Eur / month for three Hetzner EX40 servers [1] serving as
>   download master and build server
> [...]
> 1: https://www.hetzner.de/hosting/produkte_rootserver/ex40

Just wanted to say that Hetzner offers the EX41 which has a newer CPU
(i7-6700 instead of 4770) and double the disk drives (2x4TB instead of
2x2TB) for a bit less monthly price than the EX40! The only downside is
that there is a setup fee of 79? + VAT... but sometimes they waive the
fee on some months of the year, so watch out for that offer!

Also, if you find a person outside the EU to rent the servers, then
they would not pay VAT on the servers.

Just my 2 cents! :)

Cheers,
Vittorio


From richb.hanover at gmail.com  Sat Dec 10 19:46:39 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Sat, 10 Dec 2016 22:46:39 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
Message-ID: <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>


> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
> 
> with no vetos or worries being announced, could the owrt guys please
> send their ssh keys ? once the ssh keys were added you also need to add
> yourselves to the keyring.git tree. there was a howto that might not yet
> have been moved to the wiki. i'll try to figure that one out today.
> 
> 	John

I believe the two pages that are relevant are on the wiki:

https://lede-project.org/docs/user-guide/signatures and
https://lede-project.org/docs/user-guide/release_signatures

NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.

Best,

Rich

From john at phrozen.org  Sat Dec 10 22:26:18 2016
From: john at phrozen.org (John Crispin)
Date: Sun, 11 Dec 2016 07:26:18 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
Message-ID: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>



On 11/12/2016 04:46, Rich Brown wrote:
> 
>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>
>> with no vetos or worries being announced, could the owrt guys please
>> send their ssh keys ? once the ssh keys were added you also need to add
>> yourselves to the keyring.git tree. there was a howto that might not yet
>> have been moved to the wiki. i'll try to figure that one out today.
>>
>> 	John
> 
> I believe the two pages that are relevant are on the wiki:
> 
> https://lede-project.org/docs/user-guide/signatures and
> https://lede-project.org/docs/user-guide/release_signatures
> 
> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
> 
> Best,
> 
> Rich
> 

Hi,

i was looking for this page
-> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt


	John


From david at lang.hm  Sat Dec 10 23:17:18 2016
From: david at lang.hm (David Lang)
Date: Sat, 10 Dec 2016 23:17:18 -0800 (PST)
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
Message-ID: <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>

There have obviously been a lot of discussions about a merge, we see that the 
plan is to merge the OpenWRT changes into the LEDE repository, and there have 
been a couple e-mails about logistical things of merging resources.

But I don't think I've seen anything about administrative plans.

I am assuming that post-merge, the OpenWRT branding will survive (due to it 
being far better known) and the LEDE branding will fade.

But what is going to change in how the resulting project is going to be run 
compared to how OpenWRT was run in the past?

The two extreme positions (neither of which is likely, but both of which are 
possible) are:

1. LEDE devs are giving up running their own project and going back to the 
OpenWRT status-quo, but taking their changes with them

2. OpenWRT devs are joining LEDE and everything will run as LEDE has run, just 
taking over the name and existing resources of OpenWRT

I expect that the reality is somewhere in between, but I haven't seen anything 
about what is being planned.

It's very possible that I've missed something, and if so, please point me at 
what I've missed.

David Lang

On Sun, 11 Dec 2016, John Crispin wrote:

> Date: Sun, 11 Dec 2016 07:26:18 +0100
> From: John Crispin <john at phrozen.org>
> To: Rich Brown <richb.hanover at gmail.com>
> Cc: LEDE Project Administration <lede-adm at lists.infradead.org>,
>     OpenWrt Internal Developer List <openwrt-hackers at lists.openwrt.org>,
>     Felix Fietkau <nbd at nbd.name>
> Subject: Re: Proposal, progress in merge discussion with OpenWrt
> 
>
>
> On 11/12/2016 04:46, Rich Brown wrote:
>>
>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>>
>>> with no vetos or worries being announced, could the owrt guys please
>>> send their ssh keys ? once the ssh keys were added you also need to add
>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>> have been moved to the wiki. i'll try to figure that one out today.
>>>
>>> 	John
>>
>> I believe the two pages that are relevant are on the wiki:
>>
>> https://lede-project.org/docs/user-guide/signatures and
>> https://lede-project.org/docs/user-guide/release_signatures
>>
>> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
>>
>> Best,
>>
>> Rich
>>
>
> Hi,
>
> i was looking for this page
> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
>
>
> 	John
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
>


From vincenzo.romano at notorand.it  Sat Dec 10 23:32:01 2016
From: vincenzo.romano at notorand.it (Vincenzo Romano)
Date: Sun, 11 Dec 2016 08:32:01 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
 <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>
Message-ID: <CAHjZ2x7CuVdvmOJxA2Fq1xMceXN7Jx2Evz9Jbp22UUAyBYZk8w@mail.gmail.com>

>From the LEDE (current) main web page I read that it started with the

"goals of continuing to develop superior software in an open
governance model and encouraging new developers to contribute to the
development effort"

What I would expect from this merger discussion is OpenWRT value,
history and experience to merge with LEDE's.
What I would expect is OpenWRT to ditch the current project management
policy and philosophy and to fully embrace LEDE's.
If that's not the case, then it'd be better to keep the two projects split.

--
Vincenzo Romano - NotOrAnd.IT
--
NON QVIETIS MARIBVS NAVTA PERITVS


2016-12-11 8:17 GMT+01:00 David Lang <david at lang.hm>:
> There have obviously been a lot of discussions about a merge, we see that
> the plan is to merge the OpenWRT changes into the LEDE repository, and there
> have been a couple e-mails about logistical things of merging resources.
>
> But I don't think I've seen anything about administrative plans.
>
> I am assuming that post-merge, the OpenWRT branding will survive (due to it
> being far better known) and the LEDE branding will fade.
>
> But what is going to change in how the resulting project is going to be run
> compared to how OpenWRT was run in the past?
>
> The two extreme positions (neither of which is likely, but both of which are
> possible) are:
>
> 1. LEDE devs are giving up running their own project and going back to the
> OpenWRT status-quo, but taking their changes with them
>
> 2. OpenWRT devs are joining LEDE and everything will run as LEDE has run,
> just taking over the name and existing resources of OpenWRT
>
> I expect that the reality is somewhere in between, but I haven't seen
> anything about what is being planned.
>
> It's very possible that I've missed something, and if so, please point me at
> what I've missed.
>
> David Lang
>
> On Sun, 11 Dec 2016, John Crispin wrote:
>
>> Date: Sun, 11 Dec 2016 07:26:18 +0100
>> From: John Crispin <john at phrozen.org>
>> To: Rich Brown <richb.hanover at gmail.com>
>> Cc: LEDE Project Administration <lede-adm at lists.infradead.org>,
>>     OpenWrt Internal Developer List <openwrt-hackers at lists.openwrt.org>,
>>     Felix Fietkau <nbd at nbd.name>
>> Subject: Re: Proposal, progress in merge discussion with OpenWrt
>>
>>
>>
>> On 11/12/2016 04:46, Rich Brown wrote:
>>>
>>>
>>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>>>
>>>> with no vetos or worries being announced, could the owrt guys please
>>>> send their ssh keys ? once the ssh keys were added you also need to add
>>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>>> have been moved to the wiki. i'll try to figure that one out today.
>>>>
>>>>         John
>>>
>>>
>>> I believe the two pages that are relevant are on the wiki:
>>>
>>> https://lede-project.org/docs/user-guide/signatures and
>>> https://lede-project.org/docs/user-guide/release_signatures
>>>
>>> NB: I believe the Public Keys page (top one) is unchanged from the
>>> original asciidoc, but all key holders should verify that their listed
>>> public keys check out properly.
>>>
>>> Best,
>>>
>>> Rich
>>>
>>
>> Hi,
>>
>> i was looking for this page
>> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
>>
>>
>>         John
>>
>> _______________________________________________
>> lede-adm mailing list
>> lede-adm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-adm
>>
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm


From richb.hanover at gmail.com  Sun Dec 11 05:08:35 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Sun, 11 Dec 2016 08:08:35 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
Message-ID: <EE8901DE-BAD8-4237-9697-C38E5B5F846E@gmail.com>

Drat. I realize I should have included the top one one as well... For completeness, here are all three

https://lede-project.org/docs/user-guide/keygen
https://lede-project.org/docs/user-guide/signatures 
https://lede-project.org/docs/user-guide/release_signatures

Rich

> On Dec 11, 2016, at 1:26 AM, John Crispin <john at phrozen.org> wrote:
> 
> 
> 
> On 11/12/2016 04:46, Rich Brown wrote:
>> 
>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>> 
>>> with no vetos or worries being announced, could the owrt guys please
>>> send their ssh keys ? once the ssh keys were added you also need to add
>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>> have been moved to the wiki. i'll try to figure that one out today.
>>> 
>>> 	John
>> 
>> I believe the two pages that are relevant are on the wiki:
>> 
>> https://lede-project.org/docs/user-guide/signatures and
>> https://lede-project.org/docs/user-guide/release_signatures
>> 
>> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
>> 
>> Best,
>> 
>> Rich
>> 
> 
> Hi,
> 
> i was looking for this page
> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
> 
> 
> 	John



From jmomo at jmomo.net  Sun Dec 11 19:58:42 2016
From: jmomo at jmomo.net (J Mo)
Date: Sun, 11 Dec 2016 19:58:42 -0800
Subject: Patch submission review intervention requested
Message-ID: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>


I am in the process of submitting patches but am having problems with 
the LEDE dev reviewing them. I would appreciate it if a couple of the 
people on the LEDE team were to get into contact with me so that the 
situation can be reviewed.




From richb.hanover at gmail.com  Thu Dec 15 06:57:58 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Thu, 15 Dec 2016 09:57:58 -0500
Subject: Criteria for first LEDE stable release?
Message-ID: <A777BFA8-6812-46FC-AA6F-69BADA99FD77@gmail.com>

To LEDE-adm and LEDE-dev,

A discussion about the criteria for a first stable LEDE release came up on the Forum at: https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552

Please add your thoughts. Thanks.

From john at phrozen.org  Thu Dec 15 11:16:10 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 15 Dec 2016 20:16:10 +0100
Subject: Patch submission review intervention requested
In-Reply-To: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
References: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
Message-ID: <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>



On 12/12/2016 04:58, J Mo wrote:
> 
> I am in the process of submitting patches but am having problems with
> the LEDE dev reviewing them. I would appreciate it if a couple of the
> people on the LEDE team were to get into contact with me so that the
> situation can be reviewed.
> 

Hi,

sorry for the late reply, I agree with Mathias and I think Felix also
agrees. Felix posted a review a few days ago. did you have time to look
into this ?

http://lists.infradead.org/pipermail/lede-dev/2016-December/004621.html

	John


From jmomo at jmomo.net  Thu Dec 15 15:59:56 2016
From: jmomo at jmomo.net (J Mo)
Date: Thu, 15 Dec 2016 15:59:56 -0800
Subject: Patch submission review intervention requested
In-Reply-To: <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>
References: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
 <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>
Message-ID: <7deb2a3d-5b5e-4bb2-ee53-42313438f5dd@jmomo.net>


Yea, I get the message. Thanks. Bye.



On 12/15/2016 11:16 AM, John Crispin wrote:
>
> On 12/12/2016 04:58, J Mo wrote:
>> I am in the process of submitting patches but am having problems with
>> the LEDE dev reviewing them. I would appreciate it if a couple of the
>> people on the LEDE team were to get into contact with me so that the
>> situation can be reviewed.
>>
> Hi,
>
> sorry for the late reply, I agree with Mathias and I think Felix also
> agrees. Felix posted a review a few days ago. did you have time to look
> into this ?
>
> http://lists.infradead.org/pipermail/lede-dev/2016-December/004621.html
>
> 	John
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



From jo at mein.io  Wed Dec 21 11:13:00 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 21 Dec 2016 20:13:00 +0100
Subject: Release planning
Message-ID: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>

Hi guys,

I spent the last few weeks working on automating the release procedure
as much as possible and am now mostly satisfied with the result.

Currently, I am reusing most parts of the existing build bot logic and
developed some scripts to automate the setup of release build bots and
to homogenize repository specific tasks like branching and tagging.

I think that the tree is in an acceptable overall state at the moment
and that it is now time to make it available to a wider audience by
providing an alternative to untested snapshot builds.

Below you'll find some thoughts on the upcoming release which I'd like
the contributors to comment on.

The text below will refer to "yy.mm" which is a placeholder for the
final agreed date. It might be LEDE 16.12, LEDE 17.01 or even LEDE
17.02, depending on what is decided.

The first final version will be yy.mm.0 (e.g. 17.01.0), the first
maintenance release will be yy.mm.1 (e.g. 17.01.1).


# Release scope and goals

The initial LEDE release will define the future process for releasing
LEDE and serve as an extensive test run to assess the state of the tree
in general and the build and support infrastructure in particular.

It does not aim to be 100% bug free, but shall serve as a starting point
for a fixed, stable series of versions with maintenance guarantees until
the next major release is made.

I expect several minor releases to happen within the upcoming LEDE mm.yy
release series, made roughly every 4 to 8 weeks, mainly to back port
support for new devices and to address important bugs found within the
life time of the first major release.

Commits done to the release branches of the package feeds will be
available in the repository within one to two days, commits done to the
core will be made available within 4 to 8 weeks as part of the next
minor maintenance release, unless security considerations force the
project to release out of band.


# Timeline

A rough timeline for an upcoming release could look like below:

 day 0  - announce LEDE yy.mm release plan, ask feeds to create
          "lede-yy.mm" branches which will be used for the release

 day 3  - create "lede-yy.mm" release branch
        - set up build farm observing the release branches

 day 5  - phase1 (images + core package) builds done
        - distribute early, volatile yy.mm-SNAPSHOT builds to
          interested parties for smoke testing

 day 10 - phase2 (package universe done) builds done
        - create yy.mm-RC1 tag
        - trigger yy.mm-RC1 builds

 day 11 - publish & announce fixed yy.mm-RC1 builds, ask for testing
        - declare "lede-yy.mm" branch feature complete and in bugfix
          only mode
        - set grace period of 5 days to identify and fix blockers

 If no blockers identified:

  day 16 - tag yy.mm.0 and issue final rebuilds

  day 17 - publish & announce yy.mm.0 builds

 If blockers are found:

  day 16 - extend grace period by 5 days until blockers are resolved

  day 21 - create yy.mm-RC2 tag
         - trigger yy.mm-RC2 builds

  day 22 - publish & announce fixed yy.mm-RC2 builds, ask for testing
         - continue with day 11


# Branching

Prior to building any release artifact, a branch called "lede-yy.mm"
will be created in the main source.git repository, with the necessary
defaults adjusted to produce versions distinguishable from master branch
builds and with feeds.conf.default pointing to the "lede-yy.mm" branches
within the respective package feeds.

Package feed maintainers are asked to provide a "lede-yy.mm" branch
which is used by LEDE throughout the entire lifetime of the yy.mm
release series.

Attached is a script, "makebranch.sh" which is used to create a release
branch.


# Tagging

Annotated Git tags are created prior to building a fixed release and
release images are produced from source trees having the Git tag checked
out, without further build-specific overrides to ensure the
reproducibility of releases.

Release Git tags will be attached to a single commit which contains
necessary adjustments to the configuration defaults to match version
numbers and revisions needed for building proper release images.

The feeds.conf.default file will be rewritten to point to the exact Git
revision of each feed used at the time the tag was made.

An example tag can be found in my staging tree:
http://git.lede-project.org/3cd5326

Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
release version, N being the number of the minor release and an optional
-RC# designating release candidate numbers.

It remains to be decided whether we want to retain RC git tags and
binaries or whether we want to delete them after final release and/or
whether we do not want to produce RC releases at all.

Refer to the attached "maketag.sh" script to see how the build
infrastructure currently creates the git tags.


# Signing

A new GPG signing key is generated and used to sign binaries of the
upcoming release series. This key shall be cross signed by one or more
developers GPG keys and its public part will be added to the
keyring.git repository.

Git tags will be signed by this release key as well.


# Open questions

- Are there any outstanding changes?

  Is there important changes we should wait for before branching the
  release? Is there pending stuff in the staging trees which should
  absolutely go into the first release?

- When do we want to branch?

  Personally I'd like to branch before Christmas so that we can use the
  free time for building images (it takes about 8 days and ~2TB of space
  to build all targets and all packages).

- How do we want to code name the release?

  Imho we should avoid naming it the same as master ("Reboot") to
  prevent future confusion. Maybe we could simply name it "Zero" or
  "Debut" to underline the fact that it is the first release.

- Release branches in feed repos?

  What do we do if an external feed does not want to maintain a LEDE
  specific release branch - shall we fork it instead and host the fork
  our self?

- Who is willing to support the release branch?

  We will need one to two people to keep an closer eye on the release
  branch and to fulfill back port requests, who is volunteering here
  to serving as part of a maintainer group and as contact for release
  specific issues?


Please provide feedback so that we can agree on a definitive road map
for branching and for starting the preparations.

Regards,
Jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maketag.sh
Type: application/x-shellscript
Size: 4242 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161221/33de4dd1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makebranch.sh
Type: application/x-shellscript
Size: 3425 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161221/33de4dd1/attachment-0001.bin>

From john at phrozen.org  Wed Dec 21 11:29:00 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 21 Dec 2016 20:29:00 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>
Message-ID: <7f0feb04-74c6-5630-2e4c-6b7b06ba9dd5@phrozen.org>



On 21/12/2016 20:23, Dave Taht wrote:
> a) It is obviously my sincere hope that the wifi airtime fairness
> patches make this release.
> 
> b) is there any plan in the cards to fund a "stable maintainer", or
> otherwise make assurances, that a stable release will be maintained
> for X time?

i am planning to maintain this release for at least as long as it takes
to get the next one out of the door.


> c) I am curious as to what "big changes" are pending after the
> release. The switch to musl (while a very good idea), was painful in
> terms of dealing with keeping a stable and new tree working.

* v4.9
* heavily reducing the patch backlog (we have over 1000 patches pending)



From david at lang.hm  Wed Dec 21 11:29:01 2016
From: david at lang.hm (David Lang)
Date: Wed, 21 Dec 2016 11:29:01 -0800 (PST)
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <nycvar.QRO.7.75.62.1612211125040.1011@qynat-yncgbc>

On Wed, 21 Dec 2016, Jo-Philipp Wich wrote:

>        - set grace period of 5 days to identify and fix blockers
<snip>
>  day 16 - extend grace period by 5 days until blockers are resolved

As a practical matter, make these 7 days rather than 5 days. the shift between 
the work-week and the release schedule will cause problems both for devs and 
testers.

> - When do we want to branch?
>
>  Personally I'd like to branch before Christmas so that we can use the
>  free time for building images (it takes about 8 days and ~2TB of space
>  to build all targets and all packages).

how big is the build farm? how much hardware would people need to donate to 
reduce this significantly (1-2 days for example)?

David Lang


From hannu.nyman at iki.fi  Wed Dec 21 12:48:04 2016
From: hannu.nyman at iki.fi (Hannu Nyman)
Date: Wed, 21 Dec 2016 22:48:04 +0200
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <7576b0d8-a880-8323-a939-e28b082813a0@iki.fi>

Great that release planning is entering the final steps.

> The text below will refer to "yy.mm" which is a placeholder for the
> final agreed date. It might be LEDE 16.12, LEDE 17.01 or even LEDE
> 17.02, depending on what is decided.

I would prefer 17.01 as the targeted branch/release number if the final 
release is planned for January 2017.
16.12 would be a bit strange for a 2017 relase.

> - How do we want to code name the release?
>
>    Imho we should avoid naming it the same as master ("Reboot") to
>    prevent future confusion. Maybe we could simply name it "Zero" or
>    "Debut" to underline the fact that it is the first release.

I suggest a "growing alphabet" logic for future release codenames. Similar as 
in Ubuntu, Eclipse, Openwrt & whatever. In the long run that is easier than 
arbitrary names (like WR, K and B before AA, BB and CC in Openwrt) for 
quickly seeing/remembering the age/order of the releases.

The starting point could be logically defined to almost any character, but 
preferably to the early alphabets...
Some ideas:
  - A as the first character in alphabet, (but maybe not, just to avoid 
confusion with earlier Openwrt releases)
  - D as a continuation of AA BB and CC
  - E like DD+1
  - F like first, fresh, fork
  - I like initial, Roman number 1

The name could be either one word (as in Eclipse) or adjective+word (as in 
Ubuntu).

The codenames can be from separate/individual themes, so that just the first 
letter is determined in advance. That is maybe the easiest, so that no 
definite themed list needs to be formed.

But the codenames could also from a defined theme. E.g. bird names, animal 
names, gem stones, planets, constellations, Greek mythology deities, ...
Some examples:
Anaconda, Bear, Camel, Dingo, Eagle, Fox, Gazelle, Hornet, Impala, Jaguar, 
Koala, Lion, Mink, ...
Albatross, Blackbird, Cuckoo, Duck, Eagle, Falcon, Goose, Hawk, ...



From daniel.engberg.lists at pyret.net  Wed Dec 21 15:22:15 2016
From: daniel.engberg.lists at pyret.net (Daniel Engberg)
Date: Thu, 22 Dec 2016 00:22:15 +0100
Subject: Release planning
Message-ID: <70b606d5426f69e4797f7c8d2f56c804@pyret.net>

Hi,

First of all, thanks for all the effort and time put into this project.

A few issues that I'd like to see resolved and some concerning ones if 
you want to maintain this release.

Major issue(s):

package/libs/polarssl/ needs to go, the mbedtls 1.3-branch is going end 
of life at the end of this year.

General issue(s):

Kirkwood's image building Makefile should be rewritten to use 
squashfs+ubifs like oxnas. Right now the compiled u-boot binaries are 
configured to use ubifs only images however they're are not generated. 
nbd have expressed concerns about the current layout and recommended to 
use the same setup as oxnas. It's a bit over my head but I'm willing to 
test images on my iomega connect platform which is one of the affected 
devices.

Issues I'd like to see resolved:

* Make blkid-tiny support exfat
* usbmode-data should be synced with upstream
* OpenVPN 2.4 should be included instead of 2.3 or possibly moved to the 
external package repo. This also provides mbedtls support to newer 
versions than 1.3.

Best regards,
Daniel Engberg


From david at lang.hm  Thu Dec 22 00:33:12 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 00:33:12 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
Message-ID: <nycvar.QRO.7.75.62.1612220031090.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, James Feeney wrote:
> On 12/21/2016 12:13 PM, Jo-Philipp Wich wrote:

>> Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
>> release version, N being the number of the minor release and an optional
>> -RC# designating release candidate numbers.
>
> With respect to the version name, do you really want to use a "dash" instead of
> a "period", for the release candidate numbers?  I would think that adding the
> character string "RC" already provides enough information to distinguish a
> release candidate - where the ".n" suffix would be changed to ".RCm" - and that
> changing ".n" to "-RCm" just makes this suffix more difficult to parse.  Would
> it not be more practical to consistently use a "period" as the suffix delimiter?

I missed this, you don't want to use a dash or a period, you want to use a tilde 
'~'

the reason for this is sort order, if something is sorting versions with an 
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you 
want that to show up as older than the YY.MM.N releases.

David Lang


From david at lang.hm  Thu Dec 22 00:51:21 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 00:51:21 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <dc8cb6e5-54d8-50db-b7c6-ce53e8b0479d@nurealm.net>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
 <nycvar.QRO.7.75.62.1612220031090.1011@qynat-yncgbc>
 <dc8cb6e5-54d8-50db-b7c6-ce53e8b0479d@nurealm.net>
Message-ID: <nycvar.QRO.7.75.62.1612220050080.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, James Feeney wrote:

> On 12/22/2016 01:33 AM, David Lang wrote:
>> the reason for this is sort order, if something is sorting versions with an
>> alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
>> want that to show up as older than the YY.MM.N releases.
>
> A "cleaner looking" format could be "YY.MM.~m" for the release candidates?

cleaner looking but more confusing. people are used to 'rc' 'beta', etc. .~3 
just doesn't have the human readable factor.

David Lang


From john at phrozen.org  Thu Dec 22 04:29:36 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 22 Dec 2016 13:29:36 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
Message-ID: <8bd7c6cd-df30-8cd7-3530-6243412badb1@phrozen.org>



On 22/12/2016 13:19, Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
>> - Are there any outstanding changes?
>>
>>    Is there important changes we should wait for before branching the
>>    release? Is there pending stuff in the staging trees which should
>>    absolutely go into the first release?
>>
> Bump musl to a newer head? (or better to backport some fixes?)
> 

i thinkt hat bumping the libc shortly before the release is a really bad
idea. it might fix some problems but can introduce some regressions

> I see a lot of fixes since 1.1.15 on important parts which could
> influence stability as a lot of packages depend on musl:
> 

backporting would be an option. could you provide a patch adding these
fixes ?

	John

> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>     fix build regression on archs with variable page size
>     fix swprintf internal buffer state and error handling
>     fix integer overflow of tm_year in __secs_to_tm
>     fix minor problem in previous strtod non-nearest rounding bug fix
>     fix strtod int optimization in non-nearest rounding mode
>     fix strtod and strtof rounding with many trailing zeros
>     fix gratuitous undefined behavior in strptime
>     fix float formatting of some exact halfway cases
>     add pthread_setname_np (useful for debugging)
>     fix clock_nanosleep error case
>     math: fix pow signed shift ub
>     fix integer overflows and uncaught EOVERFLOW in printf core
>     fix integer overflow in float printf needed-precision computation
>     fix regexec with haystack strings longer than INT_MAX
>     fix missing integer overflow checks in regexec buffer size computations
>     fix strftime %y for negative tm_year
>     fix getservby*_r result pointer value on error
>     fix undefined behavior in sched.h cpu_set_t usage
>     add missing *_unlocked and wcsftime_l prototypes to wchar.h
>     fix if_indextoname error case
>     fix ifru_data and ifcu_buf types in net/if.h
>     fix printf regression with alt-form octal, zero flag, and field width
>     fix FFSYNC by changing it to O_SYNC
>     verify that ttyname refers to the same file as the fd
>     fix pread/pwrite syscall calling convention on sh
>     fix regression in tcsetattr on all mips archs
>     fix asctime day/month names not to vary by locale
> 
> 
> Please share your view on this one :-)
> 
> Thanks
> 


From zajec5 at gmail.com  Thu Dec 22 04:42:02 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 22 Dec 2016 13:42:02 +0100
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>

On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
> - Are there any outstanding changes?
>
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

1) Possible brcmfmac fix
I'm working on this for last few days, if that happens to work, it may
improve brcmfmac stability.

2) Better support for tri-band devices in brcmfmac
I didn't start working on this yet, but it should be easy and many
people were complaining on this issue.

3) Per device rootfs for brcm47xx
Everything is prepared, I just need to make sure rootfs don't get
bigger and then I need to specify packages.


> - When do we want to branch?
>
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

This gives us a very short period for working on extra features, I'd
appreciate something like 2 weeks at least.


From john at phrozen.org  Thu Dec 22 04:44:57 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 22 Dec 2016 13:44:57 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <b32e5915-fbcc-5c31-6ce9-24be482d25f9@phrozen.org>



On 22/12/2016 13:42, Rafa? Mi?ecki wrote:
> On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
> 
> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.
> 
> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.
> 
> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.
> 
> 
>> - When do we want to branch?
>>
>>   Personally I'd like to branch before Christmas so that we can use the
>>   free time for building images (it takes about 8 days and ~2TB of space
>>   to build all targets and all packages).
> 
> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.
> 

would starting the builders on the monday 9th of january work ? that
would give is a 17.01 release

	John

> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
> 


From jo at mein.io  Thu Dec 22 04:45:00 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 22 Dec 2016 13:45:00 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>

Hi Rafa?,

> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.

Noted.

> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.

Noted.

> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.

Noted.

> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.

Sure thing, realistically I think the branching will happen early
sometime in January.


~ Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161222/c76fbe15/attachment.sig>

From richb.hanover at gmail.com  Thu Dec 22 12:59:49 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Thu, 22 Dec 2016 15:59:49 -0500
Subject: Release planning
In-Reply-To: <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
Message-ID: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>

Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.

Rich

From david at lang.hm  Thu Dec 22 13:47:08 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 13:47:08 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
 <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
Message-ID: <nycvar.QRO.7.75.62.1612221345540.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, Rich Brown wrote:

> Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.

nope, you can start going through the git log history to pick out things that 
you think should be highlighted now. Even if the release doesn't happen for a 
while, the list will still be useful as it reduces how far back people would 
have to go at the point of release.

David Lang


From john at phrozen.org  Thu Dec 22 21:34:43 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 23 Dec 2016 06:34:43 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
 <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
Message-ID: <b07976db-6c73-a74a-196d-e953c80d4258@phrozen.org>



On 22/12/2016 21:59, Rich Brown wrote:
> Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.
> 
> Rich

if you would do that it'd be amazing. i recall doing it myself for the
last 2 releases and it is actually a huge pile of work. starting early
is good and will safe us headaches in the later phases of the release.

	John


From f.fainelli at gmail.com  Fri Dec 23 19:18:40 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 23 Dec 2016 19:18:40 -0800
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <c3f47765-38df-68b5-923d-ff89763add7e@gmail.com>

Hi,

Le 12/21/16 ? 11:13, Jo-Philipp Wich a ?crit :
> # Open questions
> 
> - Are there any outstanding changes?
> 
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

I have a number of fixes for rb532 that would probably be worth making
it to the release; including a kernel update to 4.4.

Thanks!
-- 
Florian


From daniel at makrotopia.org  Sat Dec 24 06:40:02 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 24 Dec 2016 15:40:02 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <20161224144000.GB1589@makrotopia.org>

Hi!

On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
> ...
> # Open questions
> 
> - Are there any outstanding changes?
> 
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

I believe that all targets should at least use the new image building
code to the point that we can nuke the old (sub-)target profiles.

I've just now touched sunxi (backporting ~ 350 patches to get better
support for H3 and thus the NanoPi NEO board) and there is quite a lot
to do there:
 - convert target/sunxi/image/Makefile to new style and clean up
   board-naming mess, currently we got:
   * profile name = U-Boot name (e.g. orangepi_plus)
     This name is currently also used to name OpenWrt/LEDE images
   * DTS filename (e.g. sun8i-h3-orangepi-plus)
   * /proc/device-tree/model, /proc/device-tree/compatible
   * sunxi_board_name() (e.g. organgepi-plus)
   ## consistent board names are needed for future sysupgrade

 - rewrite SDcard generation to support dynamicly sized partitions
   instead of hard-coding the rootfs size. probably it makes sense to
   unify SDcard generation code from bcm2708, mxs, sunxi and other
   platforms with similar requirements into a shared script.
 - use single-partition rootfs-split like x86 does
   => unlocks F2FS overlay and factory reset support

For obvious reasons the sunxi target hasn't seen much love since the
fork, and the same might apply for other targets which are maintained
by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
should we deal with that situation?
In the imho likely future re-merge of the LEDE and OpenWrt git trees,
all remaining OpenWrt devs will be given commit access which will allow
them to contribute and maintain things. However, I think we at least
need a dead-line for that to happen or ship the LEDE release either
without those targets or fix them up ourselves.

Apparently we already got quite a lot of different sunxi boards here at
the CCC in Hamburg, so maybe this could be a single evening
joint-effort to lift the target to use state-of-the-art image
generation and have the result tested on as much hardware as possible.

However, I'll mostly be focusing on getting the oxnas target fit for
release, the target is still stuck on kernel 4.1: currently, NAND
doesn't work on some devices on kernel 4.4 whereas the same driver
works great on kernel 4.1 -- the problem is most likely hiding
somewhere else, pinmux or even probe order... Fixing that for 4.4 would
allow to support all oxnas boards in the upcoming release.
Another way could be backporting the new oxnas support which recently
made it into the kernel and port the remaining drivers (ehci-glue,
stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
come with the advantage that most code is built so that it can be
shared and used also be used for the older ox810se, thus allowing to
support that subtarget in future in LEDE as well.

> 
> - When do we want to branch?
> 
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

Imho beginning of January, making it a 2017.01 is a good date for
branching.

> 
> - How do we want to code name the release?
> 
>   Imho we should avoid naming it the same as master ("Reboot") to
>   prevent future confusion. Maybe we could simply name it "Zero" or
>   "Debut" to underline the fact that it is the first release.

I don't care too much.

> 
> - Release branches in feed repos?
> 
>   What do we do if an external feed does not want to maintain a LEDE
>   specific release branch - shall we fork it instead and host the fork
>   our self?
> 
> - Who is willing to support the release branch?
> 
>   We will need one to two people to keep an closer eye on the release
>   branch and to fulfill back port requests, who is volunteering here
>   to serving as part of a maintainer group and as contact for release
>   specific issues?

I happily volunteer joining the backporting team.



Cheers


Daniel


> 
> 
> Please provide feedback so that we can agree on a definitive road map
> for branching and for starting the preparations.
> 
> Regards,
> Jo



> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From mschiffer at universe-factory.net  Sat Dec 24 11:26:00 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Sat, 24 Dec 2016 20:26:00 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20161224144000.GB1589@makrotopia.org>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
Message-ID: <e153c393-6b1c-24c2-dd40-68a6686bf173@universe-factory.net>

On 12/24/2016 03:40 PM, Daniel Golle wrote:
> Hi!
> 
> On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
>> ...
>> # Open questions
>>
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
> 
> I believe that all targets should at least use the new image building
> code to the point that we can nuke the old (sub-)target profiles.
> 
> I've just now touched sunxi (backporting ~ 350 patches to get better
> support for H3 and thus the NanoPi NEO board) and there is quite a lot
> to do there:
>  - convert target/sunxi/image/Makefile to new style and clean up
>    board-naming mess, currently we got:
>    * profile name = U-Boot name (e.g. orangepi_plus)
>      This name is currently also used to name OpenWrt/LEDE images
>    * DTS filename (e.g. sun8i-h3-orangepi-plus)
>    * /proc/device-tree/model, /proc/device-tree/compatible
>    * sunxi_board_name() (e.g. organgepi-plus)
>    ## consistent board names are needed for future sysupgrade

Another thing I noticed when I thought about converting sunxi to the new
build code a while ago (which I never actually did) is that the uboot
dependency handling is a mess. The different uboot builds are declared as
target packages, which are then pulled in by the profiles; the actual
packages are empty (but still appear in opkg as installed), they only exist
to trigger copying uboot to KERNEL_BUILD_DIR...

Matthias


> 
>  - rewrite SDcard generation to support dynamicly sized partitions
>    instead of hard-coding the rootfs size. probably it makes sense to
>    unify SDcard generation code from bcm2708, mxs, sunxi and other
>    platforms with similar requirements into a shared script.
>  - use single-partition rootfs-split like x86 does
>    => unlocks F2FS overlay and factory reset support
> 
> For obvious reasons the sunxi target hasn't seen much love since the
> fork, and the same might apply for other targets which are maintained
> by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
> should we deal with that situation?
> In the imho likely future re-merge of the LEDE and OpenWrt git trees,
> all remaining OpenWrt devs will be given commit access which will allow
> them to contribute and maintain things. However, I think we at least
> need a dead-line for that to happen or ship the LEDE release either
> without those targets or fix them up ourselves.
> 
> Apparently we already got quite a lot of different sunxi boards here at
> the CCC in Hamburg, so maybe this could be a single evening
> joint-effort to lift the target to use state-of-the-art image
> generation and have the result tested on as much hardware as possible.
> 
> However, I'll mostly be focusing on getting the oxnas target fit for
> release, the target is still stuck on kernel 4.1: currently, NAND
> doesn't work on some devices on kernel 4.4 whereas the same driver
> works great on kernel 4.1 -- the problem is most likely hiding
> somewhere else, pinmux or even probe order... Fixing that for 4.4 would
> allow to support all oxnas boards in the upcoming release.
> Another way could be backporting the new oxnas support which recently
> made it into the kernel and port the remaining drivers (ehci-glue,
> stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
> come with the advantage that most code is built so that it can be
> shared and used also be used for the older ox810se, thus allowing to
> support that subtarget in future in LEDE as well.
> 
>>
>> - When do we want to branch?
>>
>>   Personally I'd like to branch before Christmas so that we can use the
>>   free time for building images (it takes about 8 days and ~2TB of space
>>   to build all targets and all packages).
> 
> Imho beginning of January, making it a 2017.01 is a good date for
> branching.
> 
>>
>> - How do we want to code name the release?
>>
>>   Imho we should avoid naming it the same as master ("Reboot") to
>>   prevent future confusion. Maybe we could simply name it "Zero" or
>>   "Debut" to underline the fact that it is the first release.
> 
> I don't care too much.
> 
>>
>> - Release branches in feed repos?
>>
>>   What do we do if an external feed does not want to maintain a LEDE
>>   specific release branch - shall we fork it instead and host the fork
>>   our self?
>>
>> - Who is willing to support the release branch?
>>
>>   We will need one to two people to keep an closer eye on the release
>>   branch and to fulfill back port requests, who is volunteering here
>>   to serving as part of a maintainer group and as contact for release
>>   specific issues?
> 
> I happily volunteer joining the backporting team.
> 
> 
> 
> Cheers
> 
> 
> Daniel
> 
> 
>>
>>
>> Please provide feedback so that we can agree on a definitive road map
>> for branching and for starting the preparations.
>>
>> Regards,
>> Jo
> 
> 
> 
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161224/a326087e/attachment.sig>

From zajec5 at gmail.com  Wed Dec 28 12:54:32 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Wed, 28 Dec 2016 21:54:32 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <CACna6rx=0kgVU10x91P7Gip_pyr+ggY1Eh45A7eGoeBEdjTDdw@mail.gmail.com>

On 22 December 2016 at 13:42, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
>
> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.

Ignore that. I believe it's just FullMAC firmware bug I'm seeing.


> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.

I have early patches for this:
https://patchwork.kernel.org/patch/9490479/
https://patchwork.kernel.org/patch/9490481/


> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.

I was worried there may be some bug, because adding
DEVICE_PACKAGES := kmod-ath5k
for one device affected rootfs size of all other devices.

After analyzing this I discovered rootfs got bigger because of two
files getting fatter:
/usr/lib/libiwinfo.so
/usr/sbin/wpad

If you think about this, it makes sense, because enabling ath5k
changed options used for compiling libiwinfo and hostapd. Compiling
hostapd with things like:
-DCONFIG_DRIVER_NL80211
-DNEED_AP_MLME
-DCONFIG_ACS
-DCONFIG_SME
can obviously increase its size.

So after all it's not a bug and it was like this all the time if using
CONFIG_ALL. I'll work on brcm47xx target during next days.


From nbd at nbd.name  Thu Dec 29 07:33:31 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Thu, 29 Dec 2016 16:33:31 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
 <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>
Message-ID: <ebe961b9-7513-03d9-89d1-8dea127d69c4@nbd.name>

On 2016-12-29 15:21, Yousong Zhou wrote:
> I am working on converting sunxi target to using new image generation
> code.  The initial goal is just that preserving what the current code
> does, i.e. making fix-sized sdcard images.
> 
> I'd like to add another type of image where we have read-only squashfs
> rootfs and mkfs.ext4 remaining space at firstboot and using that ext4
> fs as rw overlay.  This part may take a while to review and evolve
> though and as such may not catch up with the release schedule.
This should be relatively simple. Just enable squashfs support, change
the kernel config to enable loopback device, ext4 and f2fs. Then build
squashfs images with a bit of padding like on x86 or mvebu.
fstools should take care of the rest at mount time.

- Felix



From dave.taht at gmail.com  Wed Dec 21 11:23:36 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 21 Dec 2016 11:23:36 -0800
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>

a) It is obviously my sincere hope that the wifi airtime fairness
patches make this release.

b) is there any plan in the cards to fund a "stable maintainer", or
otherwise make assurances, that a stable release will be maintained
for X time?

c) I am curious as to what "big changes" are pending after the
release. The switch to musl (while a very good idea), was painful in
terms of dealing with keeping a stable and new tree working.


From koen.vandeputte at ncentric.com  Thu Dec 22 04:19:46 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Thu, 22 Dec 2016 13:19:46 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>


On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> - Are there any outstanding changes?
>
>    Is there important changes we should wait for before branching the
>    release? Is there pending stuff in the staging trees which should
>    absolutely go into the first release?
>
Bump musl to a newer head? (or better to backport some fixes?)

I see a lot of fixes since 1.1.15 on important parts which could 
influence stability as a lot of packages depend on musl:

http://git.musl-libc.org/cgit/musl/log/

Some examples:
     fix build regression on archs with variable page size
     fix swprintf internal buffer state and error handling
     fix integer overflow of tm_year in __secs_to_tm
     fix minor problem in previous strtod non-nearest rounding bug fix
     fix strtod int optimization in non-nearest rounding mode
     fix strtod and strtof rounding with many trailing zeros
     fix gratuitous undefined behavior in strptime
     fix float formatting of some exact halfway cases
     add pthread_setname_np (useful for debugging)
     fix clock_nanosleep error case
     math: fix pow signed shift ub
     fix integer overflows and uncaught EOVERFLOW in printf core
     fix integer overflow in float printf needed-precision computation
     fix regexec with haystack strings longer than INT_MAX
     fix missing integer overflow checks in regexec buffer size computations
     fix strftime %y for negative tm_year
     fix getservby*_r result pointer value on error
     fix undefined behavior in sched.h cpu_set_t usage
     add missing *_unlocked and wcsftime_l prototypes to wchar.h
     fix if_indextoname error case
     fix ifru_data and ifcu_buf types in net/if.h
     fix printf regression with alt-form octal, zero flag, and field width
     fix FFSYNC by changing it to O_SYNC
     verify that ttyname refers to the same file as the fd
     fix pread/pwrite syscall calling convention on sh
     fix regression in tcsetattr on all mips archs
     fix asctime day/month names not to vary by locale


Please share your view on this one :-)

Thanks

-- 
Koen Vandeputte - Software Developer
koen.vandeputte at ncentric.com | +32499736158



From chunkeey at googlemail.com  Thu Dec 22 04:52:46 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu, 22 Dec 2016 13:52:46 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
Message-ID: <2065907.20j34c32dY@debian64>

On Thursday, December 22, 2016 1:19:46 PM CET Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> > - Are there any outstanding changes?
> >
> >    Is there important changes we should wait for before branching the
> >    release? Is there pending stuff in the staging trees which should
> >    absolutely go into the first release?
> >
> Bump musl to a newer head? (or better to backport some fixes?)
> 
> I see a lot of fixes since 1.1.15 on important parts which could 
> influence stability as a lot of packages depend on musl:
> 
> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>      fix build regression on archs with variable page size
>      fix swprintf internal buffer state and error handling
[...]

Well, if anyone is interested, here's a stand-alone patch for building
musl from git [0]. There's a small problem though with using GIT and
not point releases. It's because the musl version is used in the target and
toolchain triplet so unless you want ridiculously long names like
target-arm_cortex-a7+neon-vfpv4_musl-4c487165ff074e2f3fe7116140d1d9cded95b018_eabi

so I opt to just use 1.1.16 which unfortunately has the downside that
it's not getting updated automatically.

[0] <https://github.com/chunkeey/LEDE-IPQ40XX/commit/4c487165ff074e2f3fe7116140d1d9cded95b018>

Regards,
Christian


From yszhou4tech at gmail.com  Thu Dec 29 06:21:53 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 29 Dec 2016 22:21:53 +0800
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20161224144000.GB1589@makrotopia.org>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
Message-ID: <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>

On 24 December 2016 at 22:40, Daniel Golle <daniel at makrotopia.org> wrote:
> Hi!
>
> On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
>> ...
>> # Open questions
>>
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
>
> I believe that all targets should at least use the new image building
> code to the point that we can nuke the old (sub-)target profiles.
>
> I've just now touched sunxi (backporting ~ 350 patches to get better
> support for H3 and thus the NanoPi NEO board) and there is quite a lot
> to do there:
>  - convert target/sunxi/image/Makefile to new style and clean up
>    board-naming mess, currently we got:
>    * profile name = U-Boot name (e.g. orangepi_plus)
>      This name is currently also used to name OpenWrt/LEDE images
>    * DTS filename (e.g. sun8i-h3-orangepi-plus)
>    * /proc/device-tree/model, /proc/device-tree/compatible
>    * sunxi_board_name() (e.g. organgepi-plus)
>    ## consistent board names are needed for future sysupgrade
>
>  - rewrite SDcard generation to support dynamicly sized partitions
>    instead of hard-coding the rootfs size. probably it makes sense to
>    unify SDcard generation code from bcm2708, mxs, sunxi and other
>    platforms with similar requirements into a shared script.
>  - use single-partition rootfs-split like x86 does
>    => unlocks F2FS overlay and factory reset support
>
> For obvious reasons the sunxi target hasn't seen much love since the
> fork, and the same might apply for other targets which are maintained
> by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
> should we deal with that situation?
> In the imho likely future re-merge of the LEDE and OpenWrt git trees,
> all remaining OpenWrt devs will be given commit access which will allow
> them to contribute and maintain things. However, I think we at least
> need a dead-line for that to happen or ship the LEDE release either
> without those targets or fix them up ourselves.
>
> Apparently we already got quite a lot of different sunxi boards here at
> the CCC in Hamburg, so maybe this could be a single evening
> joint-effort to lift the target to use state-of-the-art image
> generation and have the result tested on as much hardware as possible.
>

I am working on converting sunxi target to using new image generation
code.  The initial goal is just that preserving what the current code
does, i.e. making fix-sized sdcard images.

I'd like to add another type of image where we have read-only squashfs
rootfs and mkfs.ext4 remaining space at firstboot and using that ext4
fs as rw overlay.  This part may take a while to review and evolve
though and as such may not catch up with the release schedule.

Regards,
                yousong


From nbd at nbd.name  Mon Dec  5 13:50:10 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Mon, 5 Dec 2016 19:50:10 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
Message-ID: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>

Hello LEDE team,

we recently had a very constructive discussion between the 2 project
teams regarding the next step of a more than likely remerge in the near
future.

As a step towards that common goal, we all agreed, that consolidating
the two trees is the first and most important step that we need to take.
It was agreed that the easiest and fastest way to do so is merging the
delta from OpenWrt into the LEDE tree.

To make this work, we would like to grant LEDE commit access and voting
rights to Imre, Zoltan and Luka. To speed things up we would like to set
a 24 hour grace period for the very unlikely case of anyone wanting to
veto this.

Thanks,

Daniel
Felix
John
Jonas
Lynxis
Hans
Hauke
Mathias
Matthias
Rafa?




From richb.hanover at gmail.com  Tue Dec  6 09:34:07 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 09:34:07 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
Message-ID: <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>


> On Dec 5, 2016, at 1:50 PM, Felix Fietkau <nbd at nbd.name> wrote:
> 
> Hello LEDE team,
> 
> we recently had a very constructive discussion between the 2 project
> teams regarding the next step of a more than likely remerge in the near
> future.
> 
> As a step towards that common goal, we all agreed, that consolidating
> the two trees is the first and most important step that we need to take.
> It was agreed that the easiest and fastest way to do so is merging the
> delta from OpenWrt into the LEDE tree.
> 
> To make this work, we would like to grant LEDE commit access and voting
> rights to Imre, Zoltan and Luka. To speed things up we would like to set
> a 24 hour grace period for the very unlikely case of anyone wanting to
> veto this.

ACK for me.

Thanks for all the work on this. I'll send a separate followup message with questions for the future.

> 
> Thanks,
> 
> Daniel
> Felix
> John
> Jonas
> Lynxis
> Hans
> Hauke
> Mathias
> Matthias
> Rafa?
> 
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm




From vincenzo.romano at notorand.it  Tue Dec  6 09:45:14 2016
From: vincenzo.romano at notorand.it (Vincenzo Romano)
Date: Tue, 6 Dec 2016 15:45:14 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <E7B967E5-8334-4167-9B26-E6517F25B300@gmail.com>
Message-ID: <CAHjZ2x5ZRNuphzhjqbO1N0S_h7ByeO8dKudEd+ZoMxHbNGiPKQ@mail.gmail.com>

I see only positive values in such an approach.
Fragmentation won't help. Fragmentation will fragment also the user
base making both communities less relevant.
Thanks a lot from all you guys.
Thus it's a "go" for me.
--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
cel. +39 339 8083886
tel. +39 0823 454163
fax. +39 02 700506964
--
NON QVIETIS MARIBVS NAVTA PERITVS


2016-12-06 15:34 GMT+01:00 Rich Brown <richb.hanover at gmail.com>:
>
>> On Dec 5, 2016, at 1:50 PM, Felix Fietkau <nbd at nbd.name> wrote:
>>
>> Hello LEDE team,
>>
>> we recently had a very constructive discussion between the 2 project
>> teams regarding the next step of a more than likely remerge in the near
>> future.
>>
>> As a step towards that common goal, we all agreed, that consolidating
>> the two trees is the first and most important step that we need to take.
>> It was agreed that the easiest and fastest way to do so is merging the
>> delta from OpenWrt into the LEDE tree.
>>
>> To make this work, we would like to grant LEDE commit access and voting
>> rights to Imre, Zoltan and Luka. To speed things up we would like to set
>> a 24 hour grace period for the very unlikely case of anyone wanting to
>> veto this.
>
> ACK for me.
>
> Thanks for all the work on this. I'll send a separate followup message with questions for the future.
>
>>
>> Thanks,
>>
>> Daniel
>> Felix
>> John
>> Jonas
>> Lynxis
>> Hans
>> Hauke
>> Mathias
>> Matthias
>> Rafa?
>>
>>
>> _______________________________________________
>> lede-adm mailing list
>> lede-adm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-adm
>
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



From richb.hanover at gmail.com  Tue Dec  6 09:47:11 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 09:47:11 -0500
Subject: Re-integrating LEDE and OpenWrt communities
Message-ID: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>

In light of the strong statement of support from nbd and the rest of the LEDE team, I am completely in favor of granting OpenWrt core developers commit access to the LEDE repo.

Have there been any discussions about the process of re-integrating the communities, and the infrastructure sites, documentation, forums, etc? What is the best way to continue that discussion?

Best regards, 

Rich


From jo at mein.io  Tue Dec  6 09:57:08 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 6 Dec 2016 15:57:08 +0100
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
Message-ID: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>

Hi Rich,

in our previous telephone conference this topic was more or less postponed.

Ideally I'd like to let the community decide by itself with the
LEDE/OpenWrt/whatever project merely providing the resources and some
technical help.

There's obviously a problem with having two forums, two wikis etc. in
the long run and I personally see the largest pain points with the forum
as LEDE's current choice of discourse seems to provoke some rather
strong like and dislike reactions.

Unifying the wiki should be easier imho as there's a large overlap in
information and implementation there.

I'd say the best that can be done currently is to wait and see how
things shape out in the end to avoid unnecessary, preliminary work.


~ Jo



From david at lang.hm  Tue Dec  6 10:05:02 2016
From: david at lang.hm (David Lang)
Date: Tue, 6 Dec 2016 07:05:02 -0800 (PST)
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
 <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
Message-ID: <nycvar.QRO.7.75.62.1612060703080.21122@qynat-yncgbc>

On Tue, 6 Dec 2016, Jo-Philipp Wich wrote:

> There's obviously a problem with having two forums, two wikis etc. in
> the long run and I personally see the largest pain points with the forum
> as LEDE's current choice of discourse seems to provoke some rather
> strong like and dislike reactions.

I really dislike accessing the LEDE forum via a browser, but because I can 
have new posts show up in my e-mail and reply directly (wihtout having to go 
look for new posts), I am able to contribute without ever looking at the forum, 
which I like

:-)

David Lang



From richb.hanover at gmail.com  Tue Dec  6 10:08:13 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Tue, 6 Dec 2016 10:08:13 -0500
Subject: Re-integrating LEDE and OpenWrt communities
In-Reply-To: <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
References: <4A7E8198-7967-4D7E-9F46-4632603DAAEF@gmail.com>
 <b65abd5e-f95b-6b83-9777-13a5a0aa078d@mein.io>
Message-ID: <276358C6-8B7B-4DE4-B6C7-D64C952FF7F1@gmail.com>

Hi Jo,

I think this is the perfect answer, given the state of the discussions. I don't think any action/work is required at this time.

I throw out the question now so that our collective minds can begin to chew on the problem in the background to see if there are good solutions. (I agree that the forum choice seems harder to resolve than the wiki...)

Best regards,

Rich

> On Dec 6, 2016, at 9:57 AM, Jo-Philipp Wich <jo at mein.io> wrote:
> 
> Hi Rich,
> 
> in our previous telephone conference this topic was more or less postponed.
> 
> Ideally I'd like to let the community decide by itself with the
> LEDE/OpenWrt/whatever project merely providing the resources and some
> technical help.
> 
> There's obviously a problem with having two forums, two wikis etc. in
> the long run and I personally see the largest pain points with the forum
> as LEDE's current choice of discourse seems to provoke some rather
> strong like and dislike reactions.
> 
> Unifying the wiki should be easier imho as there's a large overlap in
> information and implementation there.
> 
> I'd say the best that can be done currently is to wait and see how
> things shape out in the end to avoid unnecessary, preliminary work.
> 
> 
> ~ Jo
> 
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm




From jo at mein.io  Thu Dec  8 06:17:47 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 8 Dec 2016 12:17:47 +0100
Subject: Scheduled Discourse maintenance
Message-ID: <240b6090-09ac-e6eb-e6af-c2905d2f78b4@mein.io>

Hi,

Digital Ocean informed us that the Hypervisor running the Discourse
forum instance is undergoing maintenance from December the 15th at
02:00 UTC until 06:00 UTC.

A minimal downtime of a few minutes within that time frame is expected.


Regards,
Jo



From ynezz at true.cz  Thu Dec  8 10:38:43 2016
From: ynezz at true.cz (Petr =?iso-8859-2?Q?=A9tetiar?=)
Date: Thu, 8 Dec 2016 16:38:43 +0100
Subject: Donations?
In-Reply-To: <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
 <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
Message-ID: <20161208153843.GF17320@ibawizard.net>

Rich Brown <richb.hanover at gmail.com> [2016-10-28 14:49:54]:

Hi Rich,

> - I looked into one such site - gofundme.com. They take 5.3 % of the amount.
> I think (in the US) we might avoid a separate legal structure, since
> gofundme.com also says that most donations would be treated as personal
> gifts, and thus not taxable. I will ask my accountant, and report back.

any news regarding this topic? Thanks.

-- ynezz



From john at phrozen.org  Thu Dec  8 10:42:33 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 8 Dec 2016 16:42:33 +0100
Subject: Donations?
In-Reply-To: <20161208153843.GF17320@ibawizard.net>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
 <17E82668-33C5-41E0-B58D-EE0693352EA8@gmail.com>
 <20161208153843.GF17320@ibawizard.net>
Message-ID: <9528eeac-edaf-3668-419f-f683f2895dbe@phrozen.org>



On 08/12/2016 16:38, Petr ?tetiar wrote:
> Rich Brown <richb.hanover at gmail.com> [2016-10-28 14:49:54]:
> 
> Hi Rich,
> 
>> - I looked into one such site - gofundme.com. They take 5.3 % of the amount.
>> I think (in the US) we might avoid a separate legal structure, since
>> gofundme.com also says that most donations would be treated as personal
>> gifts, and thus not taxable. I will ask my accountant, and report back.
> 
> any news regarding this topic? Thanks.
> 
> -- ynezz
> 

owrt has received 5,000+K$ of donations via the SPI in the last years. i
think that once the remerge has become a reality we should use the SPI
for donations.

	John

> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
> 



From john at phrozen.org  Sat Dec 10 04:37:39 2016
From: john at phrozen.org (John Crispin)
Date: Sat, 10 Dec 2016 10:37:39 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
Message-ID: <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>



On 05/12/2016 19:50, Felix Fietkau wrote:
> Hello LEDE team,
> 
> we recently had a very constructive discussion between the 2 project
> teams regarding the next step of a more than likely remerge in the near
> future.
> 
> As a step towards that common goal, we all agreed, that consolidating
> the two trees is the first and most important step that we need to take.
> It was agreed that the easiest and fastest way to do so is merging the
> delta from OpenWrt into the LEDE tree.
> 
> To make this work, we would like to grant LEDE commit access and voting
> rights to Imre, Zoltan and Luka. To speed things up we would like to set
> a 24 hour grace period for the very unlikely case of anyone wanting to
> veto this.
> 
> Thanks,
> 
> Daniel
> Felix
> John
> Jonas
> Lynxis
> Hans
> Hauke
> Mathias
> Matthias
> Rafa?
> 

with no vetos or worries being announced, could the owrt guys please
send their ssh keys ? once the ssh keys were added you also need to add
yourselves to the keyring.git tree. there was a howto that might not yet
have been moved to the wiki. i'll try to figure that one out today.

	John



From openwrt at vittgam.net  Sat Dec 10 16:02:00 2016
From: openwrt at vittgam.net (Vittorio G (VittGam))
Date: Sat, 10 Dec 2016 22:02:00 +0100
Subject: =?UTF-8?Q?Donations=3F?=
In-Reply-To: <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
References: <8E623813-6BDF-47B3-87FA-88F4FF385090@gmail.com>
 <10f2ddb7-0f19-463b-2a22-cc6c90637b95@mein.io>
Message-ID: <8f6d92ebf91818ea3e9a716b4002089a@vittgam.net>

Hello,

On 28/10/2016 17:15:19 CEST, Jo-Philipp Wich wrote:
> - 3x 49,00 Eur / month for three Hetzner EX40 servers [1] serving as
>   download master and build server
> [...]
> 1: https://www.hetzner.de/hosting/produkte_rootserver/ex40

Just wanted to say that Hetzner offers the EX41 which has a newer CPU
(i7-6700 instead of 4770) and double the disk drives (2x4TB instead of
2x2TB) for a bit less monthly price than the EX40! The only downside is
that there is a setup fee of 79? + VAT... but sometimes they waive the
fee on some months of the year, so watch out for that offer!

Also, if you find a person outside the EU to rent the servers, then
they would not pay VAT on the servers.

Just my 2 cents! :)

Cheers,
Vittorio



From richb.hanover at gmail.com  Sat Dec 10 22:46:39 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Sat, 10 Dec 2016 22:46:39 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
Message-ID: <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>


> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
> 
> with no vetos or worries being announced, could the owrt guys please
> send their ssh keys ? once the ssh keys were added you also need to add
> yourselves to the keyring.git tree. there was a howto that might not yet
> have been moved to the wiki. i'll try to figure that one out today.
> 
> 	John

I believe the two pages that are relevant are on the wiki:

https://lede-project.org/docs/user-guide/signatures and
https://lede-project.org/docs/user-guide/release_signatures

NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.

Best,

Rich


From john at phrozen.org  Sun Dec 11 01:26:18 2016
From: john at phrozen.org (John Crispin)
Date: Sun, 11 Dec 2016 07:26:18 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
Message-ID: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>



On 11/12/2016 04:46, Rich Brown wrote:
> 
>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>
>> with no vetos or worries being announced, could the owrt guys please
>> send their ssh keys ? once the ssh keys were added you also need to add
>> yourselves to the keyring.git tree. there was a howto that might not yet
>> have been moved to the wiki. i'll try to figure that one out today.
>>
>> 	John
> 
> I believe the two pages that are relevant are on the wiki:
> 
> https://lede-project.org/docs/user-guide/signatures and
> https://lede-project.org/docs/user-guide/release_signatures
> 
> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
> 
> Best,
> 
> Rich
> 

Hi,

i was looking for this page
-> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt


	John



From david at lang.hm  Sun Dec 11 02:17:18 2016
From: david at lang.hm (David Lang)
Date: Sat, 10 Dec 2016 23:17:18 -0800 (PST)
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
Message-ID: <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>

There have obviously been a lot of discussions about a merge, we see that the 
plan is to merge the OpenWRT changes into the LEDE repository, and there have 
been a couple e-mails about logistical things of merging resources.

But I don't think I've seen anything about administrative plans.

I am assuming that post-merge, the OpenWRT branding will survive (due to it 
being far better known) and the LEDE branding will fade.

But what is going to change in how the resulting project is going to be run 
compared to how OpenWRT was run in the past?

The two extreme positions (neither of which is likely, but both of which are 
possible) are:

1. LEDE devs are giving up running their own project and going back to the 
OpenWRT status-quo, but taking their changes with them

2. OpenWRT devs are joining LEDE and everything will run as LEDE has run, just 
taking over the name and existing resources of OpenWRT

I expect that the reality is somewhere in between, but I haven't seen anything 
about what is being planned.

It's very possible that I've missed something, and if so, please point me at 
what I've missed.

David Lang

On Sun, 11 Dec 2016, John Crispin wrote:

> Date: Sun, 11 Dec 2016 07:26:18 +0100
> From: John Crispin <john at phrozen.org>
> To: Rich Brown <richb.hanover at gmail.com>
> Cc: LEDE Project Administration <lede-adm at lists.infradead.org>,
>     OpenWrt Internal Developer List <openwrt-hackers at lists.openwrt.org>,
>     Felix Fietkau <nbd at nbd.name>
> Subject: Re: Proposal, progress in merge discussion with OpenWrt
> 
>
>
> On 11/12/2016 04:46, Rich Brown wrote:
>>
>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>>
>>> with no vetos or worries being announced, could the owrt guys please
>>> send their ssh keys ? once the ssh keys were added you also need to add
>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>> have been moved to the wiki. i'll try to figure that one out today.
>>>
>>> 	John
>>
>> I believe the two pages that are relevant are on the wiki:
>>
>> https://lede-project.org/docs/user-guide/signatures and
>> https://lede-project.org/docs/user-guide/release_signatures
>>
>> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
>>
>> Best,
>>
>> Rich
>>
>
> Hi,
>
> i was looking for this page
> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
>
>
> 	John
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
>



From vincenzo.romano at notorand.it  Sun Dec 11 02:32:01 2016
From: vincenzo.romano at notorand.it (Vincenzo Romano)
Date: Sun, 11 Dec 2016 08:32:01 +0100
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
 <nycvar.QRO.7.75.62.1612102311550.21122@qynat-yncgbc>
Message-ID: <CAHjZ2x7CuVdvmOJxA2Fq1xMceXN7Jx2Evz9Jbp22UUAyBYZk8w@mail.gmail.com>

>From the LEDE (current) main web page I read that it started with the

"goals of continuing to develop superior software in an open
governance model and encouraging new developers to contribute to the
development effort"

What I would expect from this merger discussion is OpenWRT value,
history and experience to merge with LEDE's.
What I would expect is OpenWRT to ditch the current project management
policy and philosophy and to fully embrace LEDE's.
If that's not the case, then it'd be better to keep the two projects split.

--
Vincenzo Romano - NotOrAnd.IT
--
NON QVIETIS MARIBVS NAVTA PERITVS


2016-12-11 8:17 GMT+01:00 David Lang <david at lang.hm>:
> There have obviously been a lot of discussions about a merge, we see that
> the plan is to merge the OpenWRT changes into the LEDE repository, and there
> have been a couple e-mails about logistical things of merging resources.
>
> But I don't think I've seen anything about administrative plans.
>
> I am assuming that post-merge, the OpenWRT branding will survive (due to it
> being far better known) and the LEDE branding will fade.
>
> But what is going to change in how the resulting project is going to be run
> compared to how OpenWRT was run in the past?
>
> The two extreme positions (neither of which is likely, but both of which are
> possible) are:
>
> 1. LEDE devs are giving up running their own project and going back to the
> OpenWRT status-quo, but taking their changes with them
>
> 2. OpenWRT devs are joining LEDE and everything will run as LEDE has run,
> just taking over the name and existing resources of OpenWRT
>
> I expect that the reality is somewhere in between, but I haven't seen
> anything about what is being planned.
>
> It's very possible that I've missed something, and if so, please point me at
> what I've missed.
>
> David Lang
>
> On Sun, 11 Dec 2016, John Crispin wrote:
>
>> Date: Sun, 11 Dec 2016 07:26:18 +0100
>> From: John Crispin <john at phrozen.org>
>> To: Rich Brown <richb.hanover at gmail.com>
>> Cc: LEDE Project Administration <lede-adm at lists.infradead.org>,
>>     OpenWrt Internal Developer List <openwrt-hackers at lists.openwrt.org>,
>>     Felix Fietkau <nbd at nbd.name>
>> Subject: Re: Proposal, progress in merge discussion with OpenWrt
>>
>>
>>
>> On 11/12/2016 04:46, Rich Brown wrote:
>>>
>>>
>>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>>>
>>>> with no vetos or worries being announced, could the owrt guys please
>>>> send their ssh keys ? once the ssh keys were added you also need to add
>>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>>> have been moved to the wiki. i'll try to figure that one out today.
>>>>
>>>>         John
>>>
>>>
>>> I believe the two pages that are relevant are on the wiki:
>>>
>>> https://lede-project.org/docs/user-guide/signatures and
>>> https://lede-project.org/docs/user-guide/release_signatures
>>>
>>> NB: I believe the Public Keys page (top one) is unchanged from the
>>> original asciidoc, but all key holders should verify that their listed
>>> public keys check out properly.
>>>
>>> Best,
>>>
>>> Rich
>>>
>>
>> Hi,
>>
>> i was looking for this page
>> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
>>
>>
>>         John
>>
>> _______________________________________________
>> lede-adm mailing list
>> lede-adm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-adm
>>
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm



From richb.hanover at gmail.com  Sun Dec 11 08:08:35 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Sun, 11 Dec 2016 08:08:35 -0500
Subject: Proposal, progress in merge discussion with OpenWrt
In-Reply-To: <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
References: <8a8345e9-dd6f-a8b6-dac5-9d83fa9baa77@nbd.name>
 <a6625323-f24c-3a46-11bb-b3dad38244af@phrozen.org>
 <1D79FC44-91F0-48EA-BE3D-BBB167E59914@gmail.com>
 <74883f18-692f-f556-a76c-0a93dc2bd0cb@phrozen.org>
Message-ID: <EE8901DE-BAD8-4237-9697-C38E5B5F846E@gmail.com>

Drat. I realize I should have included the top one one as well... For completeness, here are all three

https://lede-project.org/docs/user-guide/keygen
https://lede-project.org/docs/user-guide/signatures 
https://lede-project.org/docs/user-guide/release_signatures

Rich

> On Dec 11, 2016, at 1:26 AM, John Crispin <john at phrozen.org> wrote:
> 
> 
> 
> On 11/12/2016 04:46, Rich Brown wrote:
>> 
>>> On Dec 10, 2016, at 4:37 AM, John Crispin <john at phrozen.org> wrote:
>>> 
>>> with no vetos or worries being announced, could the owrt guys please
>>> send their ssh keys ? once the ssh keys were added you also need to add
>>> yourselves to the keyring.git tree. there was a howto that might not yet
>>> have been moved to the wiki. i'll try to figure that one out today.
>>> 
>>> 	John
>> 
>> I believe the two pages that are relevant are on the wiki:
>> 
>> https://lede-project.org/docs/user-guide/signatures and
>> https://lede-project.org/docs/user-guide/release_signatures
>> 
>> NB: I believe the Public Keys page (top one) is unchanged from the original asciidoc, but all key holders should verify that their listed public keys check out properly.
>> 
>> Best,
>> 
>> Rich
>> 
> 
> Hi,
> 
> i was looking for this page
> -> https://git.lede-project.org/?p=web.git;a=blob;f=keygen.txt
> 
> 
> 	John




From jmomo at jmomo.net  Sun Dec 11 22:58:42 2016
From: jmomo at jmomo.net (J Mo)
Date: Sun, 11 Dec 2016 19:58:42 -0800
Subject: Patch submission review intervention requested
Message-ID: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>


I am in the process of submitting patches but am having problems with 
the LEDE dev reviewing them. I would appreciate it if a couple of the 
people on the LEDE team were to get into contact with me so that the 
situation can be reviewed.





From richb.hanover at gmail.com  Thu Dec 15 09:57:58 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Thu, 15 Dec 2016 09:57:58 -0500
Subject: Criteria for first LEDE stable release?
Message-ID: <A777BFA8-6812-46FC-AA6F-69BADA99FD77@gmail.com>

To LEDE-adm and LEDE-dev,

A discussion about the criteria for a first stable LEDE release came up on the Forum at: https://forum.lede-project.org/t/criteria-for-first-lede-stable-release/552

Please add your thoughts. Thanks.


From john at phrozen.org  Thu Dec 15 14:16:10 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 15 Dec 2016 20:16:10 +0100
Subject: Patch submission review intervention requested
In-Reply-To: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
References: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
Message-ID: <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>



On 12/12/2016 04:58, J Mo wrote:
> 
> I am in the process of submitting patches but am having problems with
> the LEDE dev reviewing them. I would appreciate it if a couple of the
> people on the LEDE team were to get into contact with me so that the
> situation can be reviewed.
> 

Hi,

sorry for the late reply, I agree with Mathias and I think Felix also
agrees. Felix posted a review a few days ago. did you have time to look
into this ?

http://lists.infradead.org/pipermail/lede-dev/2016-December/004621.html

	John



From jmomo at jmomo.net  Thu Dec 15 18:59:56 2016
From: jmomo at jmomo.net (J Mo)
Date: Thu, 15 Dec 2016 15:59:56 -0800
Subject: Patch submission review intervention requested
In-Reply-To: <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>
References: <97ffcf2d-c69d-b533-601f-3510703dc7e3@jmomo.net>
 <3e7f5972-8cef-4b3b-c774-8f8c89f142c2@phrozen.org>
Message-ID: <7deb2a3d-5b5e-4bb2-ee53-42313438f5dd@jmomo.net>


Yea, I get the message. Thanks. Bye.



On 12/15/2016 11:16 AM, John Crispin wrote:
>
> On 12/12/2016 04:58, J Mo wrote:
>> I am in the process of submitting patches but am having problems with
>> the LEDE dev reviewing them. I would appreciate it if a couple of the
>> people on the LEDE team were to get into contact with me so that the
>> situation can be reviewed.
>>
> Hi,
>
> sorry for the late reply, I agree with Mathias and I think Felix also
> agrees. Felix posted a review a few days ago. did you have time to look
> into this ?
>
> http://lists.infradead.org/pipermail/lede-dev/2016-December/004621.html
>
> 	John
>
> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm




From jo at mein.io  Wed Dec 21 14:13:00 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 21 Dec 2016 20:13:00 +0100
Subject: Release planning
Message-ID: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>

Hi guys,

I spent the last few weeks working on automating the release procedure
as much as possible and am now mostly satisfied with the result.

Currently, I am reusing most parts of the existing build bot logic and
developed some scripts to automate the setup of release build bots and
to homogenize repository specific tasks like branching and tagging.

I think that the tree is in an acceptable overall state at the moment
and that it is now time to make it available to a wider audience by
providing an alternative to untested snapshot builds.

Below you'll find some thoughts on the upcoming release which I'd like
the contributors to comment on.

The text below will refer to "yy.mm" which is a placeholder for the
final agreed date. It might be LEDE 16.12, LEDE 17.01 or even LEDE
17.02, depending on what is decided.

The first final version will be yy.mm.0 (e.g. 17.01.0), the first
maintenance release will be yy.mm.1 (e.g. 17.01.1).


# Release scope and goals

The initial LEDE release will define the future process for releasing
LEDE and serve as an extensive test run to assess the state of the tree
in general and the build and support infrastructure in particular.

It does not aim to be 100% bug free, but shall serve as a starting point
for a fixed, stable series of versions with maintenance guarantees until
the next major release is made.

I expect several minor releases to happen within the upcoming LEDE mm.yy
release series, made roughly every 4 to 8 weeks, mainly to back port
support for new devices and to address important bugs found within the
life time of the first major release.

Commits done to the release branches of the package feeds will be
available in the repository within one to two days, commits done to the
core will be made available within 4 to 8 weeks as part of the next
minor maintenance release, unless security considerations force the
project to release out of band.


# Timeline

A rough timeline for an upcoming release could look like below:

 day 0  - announce LEDE yy.mm release plan, ask feeds to create
          "lede-yy.mm" branches which will be used for the release

 day 3  - create "lede-yy.mm" release branch
        - set up build farm observing the release branches

 day 5  - phase1 (images + core package) builds done
        - distribute early, volatile yy.mm-SNAPSHOT builds to
          interested parties for smoke testing

 day 10 - phase2 (package universe done) builds done
        - create yy.mm-RC1 tag
        - trigger yy.mm-RC1 builds

 day 11 - publish & announce fixed yy.mm-RC1 builds, ask for testing
        - declare "lede-yy.mm" branch feature complete and in bugfix
          only mode
        - set grace period of 5 days to identify and fix blockers

 If no blockers identified:

  day 16 - tag yy.mm.0 and issue final rebuilds

  day 17 - publish & announce yy.mm.0 builds

 If blockers are found:

  day 16 - extend grace period by 5 days until blockers are resolved

  day 21 - create yy.mm-RC2 tag
         - trigger yy.mm-RC2 builds

  day 22 - publish & announce fixed yy.mm-RC2 builds, ask for testing
         - continue with day 11


# Branching

Prior to building any release artifact, a branch called "lede-yy.mm"
will be created in the main source.git repository, with the necessary
defaults adjusted to produce versions distinguishable from master branch
builds and with feeds.conf.default pointing to the "lede-yy.mm" branches
within the respective package feeds.

Package feed maintainers are asked to provide a "lede-yy.mm" branch
which is used by LEDE throughout the entire lifetime of the yy.mm
release series.

Attached is a script, "makebranch.sh" which is used to create a release
branch.


# Tagging

Annotated Git tags are created prior to building a fixed release and
release images are produced from source trees having the Git tag checked
out, without further build-specific overrides to ensure the
reproducibility of releases.

Release Git tags will be attached to a single commit which contains
necessary adjustments to the configuration defaults to match version
numbers and revisions needed for building proper release images.

The feeds.conf.default file will be rewritten to point to the exact Git
revision of each feed used at the time the tag was made.

An example tag can be found in my staging tree:
http://git.lede-project.org/3cd5326

Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
release version, N being the number of the minor release and an optional
-RC# designating release candidate numbers.

It remains to be decided whether we want to retain RC git tags and
binaries or whether we want to delete them after final release and/or
whether we do not want to produce RC releases at all.

Refer to the attached "maketag.sh" script to see how the build
infrastructure currently creates the git tags.


# Signing

A new GPG signing key is generated and used to sign binaries of the
upcoming release series. This key shall be cross signed by one or more
developers GPG keys and its public part will be added to the
keyring.git repository.

Git tags will be signed by this release key as well.


# Open questions

- Are there any outstanding changes?

  Is there important changes we should wait for before branching the
  release? Is there pending stuff in the staging trees which should
  absolutely go into the first release?

- When do we want to branch?

  Personally I'd like to branch before Christmas so that we can use the
  free time for building images (it takes about 8 days and ~2TB of space
  to build all targets and all packages).

- How do we want to code name the release?

  Imho we should avoid naming it the same as master ("Reboot") to
  prevent future confusion. Maybe we could simply name it "Zero" or
  "Debut" to underline the fact that it is the first release.

- Release branches in feed repos?

  What do we do if an external feed does not want to maintain a LEDE
  specific release branch - shall we fork it instead and host the fork
  our self?

- Who is willing to support the release branch?

  We will need one to two people to keep an closer eye on the release
  branch and to fulfill back port requests, who is volunteering here
  to serving as part of a maintainer group and as contact for release
  specific issues?


Please provide feedback so that we can agree on a definitive road map
for branching and for starting the preparations.

Regards,
Jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maketag.sh
Type: application/x-shellscript
Size: 4242 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-adm/attachments/20161221/33de4dd1/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makebranch.sh
Type: application/x-shellscript
Size: 3425 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-adm/attachments/20161221/33de4dd1/attachment-0003.bin>

From john at phrozen.org  Wed Dec 21 14:29:00 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 21 Dec 2016 20:29:00 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>
Message-ID: <7f0feb04-74c6-5630-2e4c-6b7b06ba9dd5@phrozen.org>



On 21/12/2016 20:23, Dave Taht wrote:
> a) It is obviously my sincere hope that the wifi airtime fairness
> patches make this release.
> 
> b) is there any plan in the cards to fund a "stable maintainer", or
> otherwise make assurances, that a stable release will be maintained
> for X time?

i am planning to maintain this release for at least as long as it takes
to get the next one out of the door.


> c) I am curious as to what "big changes" are pending after the
> release. The switch to musl (while a very good idea), was painful in
> terms of dealing with keeping a stable and new tree working.

* v4.9
* heavily reducing the patch backlog (we have over 1000 patches pending)




From david at lang.hm  Wed Dec 21 14:29:01 2016
From: david at lang.hm (David Lang)
Date: Wed, 21 Dec 2016 11:29:01 -0800 (PST)
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <nycvar.QRO.7.75.62.1612211125040.1011@qynat-yncgbc>

On Wed, 21 Dec 2016, Jo-Philipp Wich wrote:

>        - set grace period of 5 days to identify and fix blockers
<snip>
>  day 16 - extend grace period by 5 days until blockers are resolved

As a practical matter, make these 7 days rather than 5 days. the shift between 
the work-week and the release schedule will cause problems both for devs and 
testers.

> - When do we want to branch?
>
>  Personally I'd like to branch before Christmas so that we can use the
>  free time for building images (it takes about 8 days and ~2TB of space
>  to build all targets and all packages).

how big is the build farm? how much hardware would people need to donate to 
reduce this significantly (1-2 days for example)?

David Lang



From hannu.nyman at iki.fi  Wed Dec 21 15:48:04 2016
From: hannu.nyman at iki.fi (Hannu Nyman)
Date: Wed, 21 Dec 2016 22:48:04 +0200
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <7576b0d8-a880-8323-a939-e28b082813a0@iki.fi>

Great that release planning is entering the final steps.

> The text below will refer to "yy.mm" which is a placeholder for the
> final agreed date. It might be LEDE 16.12, LEDE 17.01 or even LEDE
> 17.02, depending on what is decided.

I would prefer 17.01 as the targeted branch/release number if the final 
release is planned for January 2017.
16.12 would be a bit strange for a 2017 relase.

> - How do we want to code name the release?
>
>    Imho we should avoid naming it the same as master ("Reboot") to
>    prevent future confusion. Maybe we could simply name it "Zero" or
>    "Debut" to underline the fact that it is the first release.

I suggest a "growing alphabet" logic for future release codenames. Similar as 
in Ubuntu, Eclipse, Openwrt & whatever. In the long run that is easier than 
arbitrary names (like WR, K and B before AA, BB and CC in Openwrt) for 
quickly seeing/remembering the age/order of the releases.

The starting point could be logically defined to almost any character, but 
preferably to the early alphabets...
Some ideas:
  - A as the first character in alphabet, (but maybe not, just to avoid 
confusion with earlier Openwrt releases)
  - D as a continuation of AA BB and CC
  - E like DD+1
  - F like first, fresh, fork
  - I like initial, Roman number 1

The name could be either one word (as in Eclipse) or adjective+word (as in 
Ubuntu).

The codenames can be from separate/individual themes, so that just the first 
letter is determined in advance. That is maybe the easiest, so that no 
definite themed list needs to be formed.

But the codenames could also from a defined theme. E.g. bird names, animal 
names, gem stones, planets, constellations, Greek mythology deities, ...
Some examples:
Anaconda, Bear, Camel, Dingo, Eagle, Fox, Gazelle, Hornet, Impala, Jaguar, 
Koala, Lion, Mink, ...
Albatross, Blackbird, Cuckoo, Duck, Eagle, Falcon, Goose, Hawk, ...




From daniel.engberg.lists at pyret.net  Wed Dec 21 18:22:15 2016
From: daniel.engberg.lists at pyret.net (Daniel Engberg)
Date: Thu, 22 Dec 2016 00:22:15 +0100
Subject: Release planning
Message-ID: <70b606d5426f69e4797f7c8d2f56c804@pyret.net>

Hi,

First of all, thanks for all the effort and time put into this project.

A few issues that I'd like to see resolved and some concerning ones if 
you want to maintain this release.

Major issue(s):

package/libs/polarssl/ needs to go, the mbedtls 1.3-branch is going end 
of life at the end of this year.

General issue(s):

Kirkwood's image building Makefile should be rewritten to use 
squashfs+ubifs like oxnas. Right now the compiled u-boot binaries are 
configured to use ubifs only images however they're are not generated. 
nbd have expressed concerns about the current layout and recommended to 
use the same setup as oxnas. It's a bit over my head but I'm willing to 
test images on my iomega connect platform which is one of the affected 
devices.

Issues I'd like to see resolved:

* Make blkid-tiny support exfat
* usbmode-data should be synced with upstream
* OpenVPN 2.4 should be included instead of 2.3 or possibly moved to the 
external package repo. This also provides mbedtls support to newer 
versions than 1.3.

Best regards,
Daniel Engberg



From david at lang.hm  Thu Dec 22 03:33:12 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 00:33:12 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
Message-ID: <nycvar.QRO.7.75.62.1612220031090.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, James Feeney wrote:
> On 12/21/2016 12:13 PM, Jo-Philipp Wich wrote:

>> Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
>> release version, N being the number of the minor release and an optional
>> -RC# designating release candidate numbers.
>
> With respect to the version name, do you really want to use a "dash" instead of
> a "period", for the release candidate numbers?  I would think that adding the
> character string "RC" already provides enough information to distinguish a
> release candidate - where the ".n" suffix would be changed to ".RCm" - and that
> changing ".n" to "-RCm" just makes this suffix more difficult to parse.  Would
> it not be more practical to consistently use a "period" as the suffix delimiter?

I missed this, you don't want to use a dash or a period, you want to use a tilde 
'~'

the reason for this is sort order, if something is sorting versions with an 
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you 
want that to show up as older than the YY.MM.N releases.

David Lang



From david at lang.hm  Thu Dec 22 03:51:21 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 00:51:21 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <dc8cb6e5-54d8-50db-b7c6-ce53e8b0479d@nurealm.net>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <fb4f3470-dbc2-3e9c-b68a-9690e337e806@nurealm.net>
 <nycvar.QRO.7.75.62.1612220031090.1011@qynat-yncgbc>
 <dc8cb6e5-54d8-50db-b7c6-ce53e8b0479d@nurealm.net>
Message-ID: <nycvar.QRO.7.75.62.1612220050080.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, James Feeney wrote:

> On 12/22/2016 01:33 AM, David Lang wrote:
>> the reason for this is sort order, if something is sorting versions with an
>> alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
>> want that to show up as older than the YY.MM.N releases.
>
> A "cleaner looking" format could be "YY.MM.~m" for the release candidates?

cleaner looking but more confusing. people are used to 'rc' 'beta', etc. .~3 
just doesn't have the human readable factor.

David Lang



From john at phrozen.org  Thu Dec 22 07:29:36 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 22 Dec 2016 13:29:36 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
Message-ID: <8bd7c6cd-df30-8cd7-3530-6243412badb1@phrozen.org>



On 22/12/2016 13:19, Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
>> - Are there any outstanding changes?
>>
>>    Is there important changes we should wait for before branching the
>>    release? Is there pending stuff in the staging trees which should
>>    absolutely go into the first release?
>>
> Bump musl to a newer head? (or better to backport some fixes?)
> 

i thinkt hat bumping the libc shortly before the release is a really bad
idea. it might fix some problems but can introduce some regressions

> I see a lot of fixes since 1.1.15 on important parts which could
> influence stability as a lot of packages depend on musl:
> 

backporting would be an option. could you provide a patch adding these
fixes ?

	John

> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>     fix build regression on archs with variable page size
>     fix swprintf internal buffer state and error handling
>     fix integer overflow of tm_year in __secs_to_tm
>     fix minor problem in previous strtod non-nearest rounding bug fix
>     fix strtod int optimization in non-nearest rounding mode
>     fix strtod and strtof rounding with many trailing zeros
>     fix gratuitous undefined behavior in strptime
>     fix float formatting of some exact halfway cases
>     add pthread_setname_np (useful for debugging)
>     fix clock_nanosleep error case
>     math: fix pow signed shift ub
>     fix integer overflows and uncaught EOVERFLOW in printf core
>     fix integer overflow in float printf needed-precision computation
>     fix regexec with haystack strings longer than INT_MAX
>     fix missing integer overflow checks in regexec buffer size computations
>     fix strftime %y for negative tm_year
>     fix getservby*_r result pointer value on error
>     fix undefined behavior in sched.h cpu_set_t usage
>     add missing *_unlocked and wcsftime_l prototypes to wchar.h
>     fix if_indextoname error case
>     fix ifru_data and ifcu_buf types in net/if.h
>     fix printf regression with alt-form octal, zero flag, and field width
>     fix FFSYNC by changing it to O_SYNC
>     verify that ttyname refers to the same file as the fd
>     fix pread/pwrite syscall calling convention on sh
>     fix regression in tcsetattr on all mips archs
>     fix asctime day/month names not to vary by locale
> 
> 
> Please share your view on this one :-)
> 
> Thanks
> 



From zajec5 at gmail.com  Thu Dec 22 07:42:02 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 22 Dec 2016 13:42:02 +0100
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>

On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
> - Are there any outstanding changes?
>
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

1) Possible brcmfmac fix
I'm working on this for last few days, if that happens to work, it may
improve brcmfmac stability.

2) Better support for tri-band devices in brcmfmac
I didn't start working on this yet, but it should be easy and many
people were complaining on this issue.

3) Per device rootfs for brcm47xx
Everything is prepared, I just need to make sure rootfs don't get
bigger and then I need to specify packages.


> - When do we want to branch?
>
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

This gives us a very short period for working on extra features, I'd
appreciate something like 2 weeks at least.



From john at phrozen.org  Thu Dec 22 07:44:57 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 22 Dec 2016 13:44:57 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <b32e5915-fbcc-5c31-6ce9-24be482d25f9@phrozen.org>



On 22/12/2016 13:42, Rafa? Mi?ecki wrote:
> On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
> 
> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.
> 
> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.
> 
> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.
> 
> 
>> - When do we want to branch?
>>
>>   Personally I'd like to branch before Christmas so that we can use the
>>   free time for building images (it takes about 8 days and ~2TB of space
>>   to build all targets and all packages).
> 
> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.
> 

would starting the builders on the monday 9th of january work ? that
would give is a 17.01 release

	John

> _______________________________________________
> lede-adm mailing list
> lede-adm at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm
> 



From jo at mein.io  Thu Dec 22 07:45:00 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 22 Dec 2016 13:45:00 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>

Hi Rafa?,

> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.

Noted.

> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.

Noted.

> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.

Noted.

> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.

Sure thing, realistically I think the branching will happen early
sometime in January.


~ Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-adm/attachments/20161222/c76fbe15/attachment-0001.sig>

From richb.hanover at gmail.com  Thu Dec 22 15:59:49 2016
From: richb.hanover at gmail.com (Rich Brown)
Date: Thu, 22 Dec 2016 15:59:49 -0500
Subject: Release planning
In-Reply-To: <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
Message-ID: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>

Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.

Rich


From david at lang.hm  Thu Dec 22 16:47:08 2016
From: david at lang.hm (David Lang)
Date: Thu, 22 Dec 2016 13:47:08 -0800 (PST)
Subject: [LEDE-DEV] Release planning
In-Reply-To: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
 <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
Message-ID: <nycvar.QRO.7.75.62.1612221345540.1011@qynat-yncgbc>

On Thu, 22 Dec 2016, Rich Brown wrote:

> Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.

nope, you can start going through the git log history to pick out things that 
you think should be highlighted now. Even if the release doesn't happen for a 
while, the list will still be useful as it reduces how far back people would 
have to go at the point of release.

David Lang



From john at phrozen.org  Fri Dec 23 00:34:43 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 23 Dec 2016 06:34:43 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
 <fe5d823c-6c61-a1ef-0992-e1b62f062f37@mein.io>
 <589BA7A6-42FD-4408-88F7-523553EFC37B@gmail.com>
Message-ID: <b07976db-6c73-a74a-196d-e953c80d4258@phrozen.org>



On 22/12/2016 21:59, Rich Brown wrote:
> Is it too soon to begin identifying/enumerating the features/packages that will go into the 17.01 release? Thanks.
> 
> Rich

if you would do that it'd be amazing. i recall doing it myself for the
last 2 releases and it is actually a huge pile of work. starting early
is good and will safe us headaches in the later phases of the release.

	John



From f.fainelli at gmail.com  Fri Dec 23 22:18:40 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 23 Dec 2016 19:18:40 -0800
Subject: Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <c3f47765-38df-68b5-923d-ff89763add7e@gmail.com>

Hi,

Le 12/21/16 ? 11:13, Jo-Philipp Wich a ?crit :
> # Open questions
> 
> - Are there any outstanding changes?
> 
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

I have a number of fixes for rb532 that would probably be worth making
it to the release; including a kernel update to 4.4.

Thanks!
-- 
Florian



From daniel at makrotopia.org  Sat Dec 24 09:40:02 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 24 Dec 2016 15:40:02 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <20161224144000.GB1589@makrotopia.org>

Hi!

On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
> ...
> # Open questions
> 
> - Are there any outstanding changes?
> 
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

I believe that all targets should at least use the new image building
code to the point that we can nuke the old (sub-)target profiles.

I've just now touched sunxi (backporting ~ 350 patches to get better
support for H3 and thus the NanoPi NEO board) and there is quite a lot
to do there:
 - convert target/sunxi/image/Makefile to new style and clean up
   board-naming mess, currently we got:
   * profile name = U-Boot name (e.g. orangepi_plus)
     This name is currently also used to name OpenWrt/LEDE images
   * DTS filename (e.g. sun8i-h3-orangepi-plus)
   * /proc/device-tree/model, /proc/device-tree/compatible
   * sunxi_board_name() (e.g. organgepi-plus)
   ## consistent board names are needed for future sysupgrade

 - rewrite SDcard generation to support dynamicly sized partitions
   instead of hard-coding the rootfs size. probably it makes sense to
   unify SDcard generation code from bcm2708, mxs, sunxi and other
   platforms with similar requirements into a shared script.
 - use single-partition rootfs-split like x86 does
   => unlocks F2FS overlay and factory reset support

For obvious reasons the sunxi target hasn't seen much love since the
fork, and the same might apply for other targets which are maintained
by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
should we deal with that situation?
In the imho likely future re-merge of the LEDE and OpenWrt git trees,
all remaining OpenWrt devs will be given commit access which will allow
them to contribute and maintain things. However, I think we at least
need a dead-line for that to happen or ship the LEDE release either
without those targets or fix them up ourselves.

Apparently we already got quite a lot of different sunxi boards here at
the CCC in Hamburg, so maybe this could be a single evening
joint-effort to lift the target to use state-of-the-art image
generation and have the result tested on as much hardware as possible.

However, I'll mostly be focusing on getting the oxnas target fit for
release, the target is still stuck on kernel 4.1: currently, NAND
doesn't work on some devices on kernel 4.4 whereas the same driver
works great on kernel 4.1 -- the problem is most likely hiding
somewhere else, pinmux or even probe order... Fixing that for 4.4 would
allow to support all oxnas boards in the upcoming release.
Another way could be backporting the new oxnas support which recently
made it into the kernel and port the remaining drivers (ehci-glue,
stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
come with the advantage that most code is built so that it can be
shared and used also be used for the older ox810se, thus allowing to
support that subtarget in future in LEDE as well.

> 
> - When do we want to branch?
> 
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

Imho beginning of January, making it a 2017.01 is a good date for
branching.

> 
> - How do we want to code name the release?
> 
>   Imho we should avoid naming it the same as master ("Reboot") to
>   prevent future confusion. Maybe we could simply name it "Zero" or
>   "Debut" to underline the fact that it is the first release.

I don't care too much.

> 
> - Release branches in feed repos?
> 
>   What do we do if an external feed does not want to maintain a LEDE
>   specific release branch - shall we fork it instead and host the fork
>   our self?
> 
> - Who is willing to support the release branch?
> 
>   We will need one to two people to keep an closer eye on the release
>   branch and to fulfill back port requests, who is volunteering here
>   to serving as part of a maintainer group and as contact for release
>   specific issues?

I happily volunteer joining the backporting team.



Cheers


Daniel


> 
> 
> Please provide feedback so that we can agree on a definitive road map
> for branching and for starting the preparations.
> 
> Regards,
> Jo



> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev




From mschiffer at universe-factory.net  Sat Dec 24 14:26:00 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Sat, 24 Dec 2016 20:26:00 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20161224144000.GB1589@makrotopia.org>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
Message-ID: <e153c393-6b1c-24c2-dd40-68a6686bf173@universe-factory.net>

On 12/24/2016 03:40 PM, Daniel Golle wrote:
> Hi!
> 
> On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
>> ...
>> # Open questions
>>
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
> 
> I believe that all targets should at least use the new image building
> code to the point that we can nuke the old (sub-)target profiles.
> 
> I've just now touched sunxi (backporting ~ 350 patches to get better
> support for H3 and thus the NanoPi NEO board) and there is quite a lot
> to do there:
>  - convert target/sunxi/image/Makefile to new style and clean up
>    board-naming mess, currently we got:
>    * profile name = U-Boot name (e.g. orangepi_plus)
>      This name is currently also used to name OpenWrt/LEDE images
>    * DTS filename (e.g. sun8i-h3-orangepi-plus)
>    * /proc/device-tree/model, /proc/device-tree/compatible
>    * sunxi_board_name() (e.g. organgepi-plus)
>    ## consistent board names are needed for future sysupgrade

Another thing I noticed when I thought about converting sunxi to the new
build code a while ago (which I never actually did) is that the uboot
dependency handling is a mess. The different uboot builds are declared as
target packages, which are then pulled in by the profiles; the actual
packages are empty (but still appear in opkg as installed), they only exist
to trigger copying uboot to KERNEL_BUILD_DIR...

Matthias


> 
>  - rewrite SDcard generation to support dynamicly sized partitions
>    instead of hard-coding the rootfs size. probably it makes sense to
>    unify SDcard generation code from bcm2708, mxs, sunxi and other
>    platforms with similar requirements into a shared script.
>  - use single-partition rootfs-split like x86 does
>    => unlocks F2FS overlay and factory reset support
> 
> For obvious reasons the sunxi target hasn't seen much love since the
> fork, and the same might apply for other targets which are maintained
> by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
> should we deal with that situation?
> In the imho likely future re-merge of the LEDE and OpenWrt git trees,
> all remaining OpenWrt devs will be given commit access which will allow
> them to contribute and maintain things. However, I think we at least
> need a dead-line for that to happen or ship the LEDE release either
> without those targets or fix them up ourselves.
> 
> Apparently we already got quite a lot of different sunxi boards here at
> the CCC in Hamburg, so maybe this could be a single evening
> joint-effort to lift the target to use state-of-the-art image
> generation and have the result tested on as much hardware as possible.
> 
> However, I'll mostly be focusing on getting the oxnas target fit for
> release, the target is still stuck on kernel 4.1: currently, NAND
> doesn't work on some devices on kernel 4.4 whereas the same driver
> works great on kernel 4.1 -- the problem is most likely hiding
> somewhere else, pinmux or even probe order... Fixing that for 4.4 would
> allow to support all oxnas boards in the upcoming release.
> Another way could be backporting the new oxnas support which recently
> made it into the kernel and port the remaining drivers (ehci-glue,
> stmmac-glue, sata, pmic/leon, ...) to work on top of that. This would
> come with the advantage that most code is built so that it can be
> shared and used also be used for the older ox810se, thus allowing to
> support that subtarget in future in LEDE as well.
> 
>>
>> - When do we want to branch?
>>
>>   Personally I'd like to branch before Christmas so that we can use the
>>   free time for building images (it takes about 8 days and ~2TB of space
>>   to build all targets and all packages).
> 
> Imho beginning of January, making it a 2017.01 is a good date for
> branching.
> 
>>
>> - How do we want to code name the release?
>>
>>   Imho we should avoid naming it the same as master ("Reboot") to
>>   prevent future confusion. Maybe we could simply name it "Zero" or
>>   "Debut" to underline the fact that it is the first release.
> 
> I don't care too much.
> 
>>
>> - Release branches in feed repos?
>>
>>   What do we do if an external feed does not want to maintain a LEDE
>>   specific release branch - shall we fork it instead and host the fork
>>   our self?
>>
>> - Who is willing to support the release branch?
>>
>>   We will need one to two people to keep an closer eye on the release
>>   branch and to fulfill back port requests, who is volunteering here
>>   to serving as part of a maintainer group and as contact for release
>>   specific issues?
> 
> I happily volunteer joining the backporting team.
> 
> 
> 
> Cheers
> 
> 
> Daniel
> 
> 
>>
>>
>> Please provide feedback so that we can agree on a definitive road map
>> for branching and for starting the preparations.
>>
>> Regards,
>> Jo
> 
> 
> 
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-adm/attachments/20161224/a326087e/attachment-0001.sig>

From zajec5 at gmail.com  Wed Dec 28 15:54:32 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Wed, 28 Dec 2016 21:54:32 +0100
Subject: Release planning
In-Reply-To: <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <CACna6rze06noS=ONyHZaa+2b+XT41S4vtu1VCMxMsCS_g34rqg@mail.gmail.com>
Message-ID: <CACna6rx=0kgVU10x91P7Gip_pyr+ggY1Eh45A7eGoeBEdjTDdw@mail.gmail.com>

On 22 December 2016 at 13:42, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> On 21 December 2016 at 20:13, Jo-Philipp Wich <jo at mein.io> wrote:
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
>
> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.

Ignore that. I believe it's just FullMAC firmware bug I'm seeing.


> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.

I have early patches for this:
https://patchwork.kernel.org/patch/9490479/
https://patchwork.kernel.org/patch/9490481/


> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.

I was worried there may be some bug, because adding
DEVICE_PACKAGES := kmod-ath5k
for one device affected rootfs size of all other devices.

After analyzing this I discovered rootfs got bigger because of two
files getting fatter:
/usr/lib/libiwinfo.so
/usr/sbin/wpad

If you think about this, it makes sense, because enabling ath5k
changed options used for compiling libiwinfo and hostapd. Compiling
hostapd with things like:
-DCONFIG_DRIVER_NL80211
-DNEED_AP_MLME
-DCONFIG_ACS
-DCONFIG_SME
can obviously increase its size.

So after all it's not a bug and it was like this all the time if using
CONFIG_ALL. I'll work on brcm47xx target during next days.



From nbd at nbd.name  Thu Dec 29 10:33:31 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Thu, 29 Dec 2016 16:33:31 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
 <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>
Message-ID: <ebe961b9-7513-03d9-89d1-8dea127d69c4@nbd.name>

On 2016-12-29 15:21, Yousong Zhou wrote:
> I am working on converting sunxi target to using new image generation
> code.  The initial goal is just that preserving what the current code
> does, i.e. making fix-sized sdcard images.
> 
> I'd like to add another type of image where we have read-only squashfs
> rootfs and mkfs.ext4 remaining space at firstboot and using that ext4
> fs as rw overlay.  This part may take a while to review and evolve
> though and as such may not catch up with the release schedule.
This should be relatively simple. Just enable squashfs support, change
the kernel config to enable loopback device, ext4 and f2fs. Then build
squashfs images with a bit of padding like on x86 or mvebu.
fstools should take care of the rest at mount time.

- Felix




From dave.taht at gmail.com  Wed Dec 21 14:23:36 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 21 Dec 2016 11:23:36 -0800
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <CAA93jw4EhnGBybhu3RtzjmwqfS==73hYkFgGYZ-Q1W2XyMfNVA@mail.gmail.com>

a) It is obviously my sincere hope that the wifi airtime fairness
patches make this release.

b) is there any plan in the cards to fund a "stable maintainer", or
otherwise make assurances, that a stable release will be maintained
for X time?

c) I am curious as to what "big changes" are pending after the
release. The switch to musl (while a very good idea), was painful in
terms of dealing with keeping a stable and new tree working.



From koen.vandeputte at ncentric.com  Thu Dec 22 07:19:46 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Thu, 22 Dec 2016 13:19:46 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
Message-ID: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>


On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> - Are there any outstanding changes?
>
>    Is there important changes we should wait for before branching the
>    release? Is there pending stuff in the staging trees which should
>    absolutely go into the first release?
>
Bump musl to a newer head? (or better to backport some fixes?)

I see a lot of fixes since 1.1.15 on important parts which could 
influence stability as a lot of packages depend on musl:

http://git.musl-libc.org/cgit/musl/log/

Some examples:
     fix build regression on archs with variable page size
     fix swprintf internal buffer state and error handling
     fix integer overflow of tm_year in __secs_to_tm
     fix minor problem in previous strtod non-nearest rounding bug fix
     fix strtod int optimization in non-nearest rounding mode
     fix strtod and strtof rounding with many trailing zeros
     fix gratuitous undefined behavior in strptime
     fix float formatting of some exact halfway cases
     add pthread_setname_np (useful for debugging)
     fix clock_nanosleep error case
     math: fix pow signed shift ub
     fix integer overflows and uncaught EOVERFLOW in printf core
     fix integer overflow in float printf needed-precision computation
     fix regexec with haystack strings longer than INT_MAX
     fix missing integer overflow checks in regexec buffer size computations
     fix strftime %y for negative tm_year
     fix getservby*_r result pointer value on error
     fix undefined behavior in sched.h cpu_set_t usage
     add missing *_unlocked and wcsftime_l prototypes to wchar.h
     fix if_indextoname error case
     fix ifru_data and ifcu_buf types in net/if.h
     fix printf regression with alt-form octal, zero flag, and field width
     fix FFSYNC by changing it to O_SYNC
     verify that ttyname refers to the same file as the fd
     fix pread/pwrite syscall calling convention on sh
     fix regression in tcsetattr on all mips archs
     fix asctime day/month names not to vary by locale


Please share your view on this one :-)

Thanks

-- 
Koen Vandeputte - Software Developer
koen.vandeputte at ncentric.com | +32499736158




From chunkeey at googlemail.com  Thu Dec 22 07:52:46 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu, 22 Dec 2016 13:52:46 +0100
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20ef6da7-8fad-44b6-c6eb-b0d770cfc1f0@ncentric.com>
Message-ID: <2065907.20j34c32dY@debian64>

On Thursday, December 22, 2016 1:19:46 PM CET Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> > - Are there any outstanding changes?
> >
> >    Is there important changes we should wait for before branching the
> >    release? Is there pending stuff in the staging trees which should
> >    absolutely go into the first release?
> >
> Bump musl to a newer head? (or better to backport some fixes?)
> 
> I see a lot of fixes since 1.1.15 on important parts which could 
> influence stability as a lot of packages depend on musl:
> 
> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>      fix build regression on archs with variable page size
>      fix swprintf internal buffer state and error handling
[...]

Well, if anyone is interested, here's a stand-alone patch for building
musl from git [0]. There's a small problem though with using GIT and
not point releases. It's because the musl version is used in the target and
toolchain triplet so unless you want ridiculously long names like
target-arm_cortex-a7+neon-vfpv4_musl-4c487165ff074e2f3fe7116140d1d9cded95b018_eabi

so I opt to just use 1.1.16 which unfortunately has the downside that
it's not getting updated automatically.

[0] <https://github.com/chunkeey/LEDE-IPQ40XX/commit/4c487165ff074e2f3fe7116140d1d9cded95b018>

Regards,
Christian



From yszhou4tech at gmail.com  Thu Dec 29 09:21:53 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 29 Dec 2016 22:21:53 +0800
Subject: [LEDE-DEV] Release planning
In-Reply-To: <20161224144000.GB1589@makrotopia.org>
References: <612e61a0-6664-78a0-b058-58938a31c651@mein.io>
 <20161224144000.GB1589@makrotopia.org>
Message-ID: <CAECwjAhvoxstV+aojfy_sHV9v55Jj8xsa0hc++FtHWB_Y2Siig@mail.gmail.com>

On 24 December 2016 at 22:40, Daniel Golle <daniel at makrotopia.org> wrote:
> Hi!
>
> On Wed, Dec 21, 2016 at 08:13:00PM +0100, Jo-Philipp Wich wrote:
>> ...
>> # Open questions
>>
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
>
> I believe that all targets should at least use the new image building
> code to the point that we can nuke the old (sub-)target profiles.
>
> I've just now touched sunxi (backporting ~ 350 patches to get better
> support for H3 and thus the NanoPi NEO board) and there is quite a lot
> to do there:
>  - convert target/sunxi/image/Makefile to new style and clean up
>    board-naming mess, currently we got:
>    * profile name = U-Boot name (e.g. orangepi_plus)
>      This name is currently also used to name OpenWrt/LEDE images
>    * DTS filename (e.g. sun8i-h3-orangepi-plus)
>    * /proc/device-tree/model, /proc/device-tree/compatible
>    * sunxi_board_name() (e.g. organgepi-plus)
>    ## consistent board names are needed for future sysupgrade
>
>  - rewrite SDcard generation to support dynamicly sized partitions
>    instead of hard-coding the rootfs size. probably it makes sense to
>    unify SDcard generation code from bcm2708, mxs, sunxi and other
>    platforms with similar requirements into a shared script.
>  - use single-partition rootfs-split like x86 does
>    => unlocks F2FS overlay and factory reset support
>
> For obvious reasons the sunxi target hasn't seen much love since the
> fork, and the same might apply for other targets which are maintained
> by OpenWrt/non-LEDE devs. With regard to the upcoming release, how
> should we deal with that situation?
> In the imho likely future re-merge of the LEDE and OpenWrt git trees,
> all remaining OpenWrt devs will be given commit access which will allow
> them to contribute and maintain things. However, I think we at least
> need a dead-line for that to happen or ship the LEDE release either
> without those targets or fix them up ourselves.
>
> Apparently we already got quite a lot of different sunxi boards here at
> the CCC in Hamburg, so maybe this could be a single evening
> joint-effort to lift the target to use state-of-the-art image
> generation and have the result tested on as much hardware as possible.
>

I am working on converting sunxi target to using new image generation
code.  The initial goal is just that preserving what the current code
does, i.e. making fix-sized sdcard images.

I'd like to add another type of image where we have read-only squashfs
rootfs and mkfs.ext4 remaining space at firstboot and using that ext4
fs as rw overlay.  This part may take a while to review and evolve
though and as such may not catch up with the release schedule.

Regards,
                yousong



