[OpenWrt-Devel] [LEDE-DEV] 18.06 Status?

Martin Schroeder mkschreder.uk at googlemail.com
Thu Jun 7 04:13:00 EDT 2018

How about you guys vote for a person. Make a list of candidates, mail
it out to the list (people can add their own names if they wish). Then
whoever gets voted in becomes the coordinator.

On Sat, May 5, 2018 at 9:12 PM, Fernando Frediani <fhfrediani at gmail.com> wrote:
> I didn't mention forcing people at any point. Just having someone to be in
> charge in order to organize certain things, get people's availability and
> make more thing happen.
> With regards schedule the lack of one seems not doing much good, so having
> one has the potential to improve things. And again, having a schedule
> doesn't necessarily mean every single point will get done, but certainly
> will get more attention and commitment from most of people around something
> in common. It will not be a big thing if a feature was skipped.
> As mentioned in the other reply perhaps Release Coordinator could do this
> job fine without changing much of the whole thing.
> Regards
> Fernando
> On 05/05/2018 15:55, Alberto Bursi wrote:
>> This isn't a job where you can force people to do anything.
>> Also, I'm not a fan of half-assing or leaving out things for the sake of a
>> schedule.
>> -Alberto
>> On 05/05/2018 20:41, Fernando Frediani wrote:
>>> One characteristic from OpenWrt, different from other projects is the
>>> lack of a leader or a person who can gather others together, make some
>>> decisions or push for them to happen. If one doesn't like this title it can
>>> also be "Project Manager" or "Project Coordinator". This, in my view, makes
>>> a big difference for things to flow in time.
>>> Has anyone heard that saying: "A dog with many owners starves"
>>> Perhaps it is the time to adjust the Rules (https://openwrt.org/rules)
>>> and add something to make it exist in benefit of the project.
>>> Fernando
>>> On 05/05/2018 07:27, Jaap Buurman wrote:
>>>> Hi all,
>>>> I feel like everybody is just waiting for everybody to agree what
>>>> features we want in before coming up with the next step of picking a
>>>> date. Obviously this isn't working out very well. Why not turn things
>>>> around? Pick a date in a few weeks time on which the Master branch
>>>> will be split to a 18.0X branch. If nobody complains before that date
>>>> the branch goes on as planned. People can obviously get in the
>>>> features they want before said date. If somebody deems a particular
>>>> feature very important to be included in this branch, but feels like
>>>> it will not be finished before said date, he/she can request a delay
>>>> stating:
>>>> -What he/she would like to include
>>>> -Why this is so important to be included before the branch.
>>>> -How much extra time this will need by proposing a new date
>>>> -Perhaps a request for help implementing said change
>>>> Should this proposal be accepted, we will reschedule the date from
>>>> there. If the other people don't think it is important enough to
>>>> postpone the release, the old date will stand. This way, we can simply
>>>> move forward if nobody complains about a particular date instead of
>>>> the waiting around for others that is going on right now. What does
>>>> everybody else think of this idea? What seems like a reasonable date?
>>>> And who would be willing to take on the task of splitting the branch
>>>> at said date to make sure we'll be actually moving forward with the
>>>> plan at said date?
>>>> Yours sincerely,
>>>> Jaap Buurman
>>>> On Wed, May 2, 2018 at 4:41 AM, Eric Luehrsen <ericluehrsen at gmail.com>
>>>> wrote:
>>>>> On 05/01/2018 10:47 AM, Hannu Nyman wrote:
>>>>>> I think that the main source tree is in pretty good shape, so
>>>>>> branching
>>>>>> off the 18.0X rather soon might make sense....
>>>>> I would also think its time to branch 18.[something-soon], and rather
>>>>> than
>>>>> focus on work that needs yet to be completed, look to cut hardware and
>>>>> packages that are not ready for a release. There is always some heart
>>>>> ache
>>>>> when such decisions are made, but at a point those decisions do need to
>>>>> be
>>>>> made. Without an official release to punctuate both the core team and
>>>>> other
>>>>> packagers hard work, OpenWrt/LEDE could risk losing support from the
>>>>> community and its limited sponsorship. I imagine this project means
>>>>> something personally to the core team, so those risks should be
>>>>> considered.
>>>>> - Eric
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list