On Tue, Dec 27, 2016 at 08:28:25AM +0100, John Crispin wrote:
> On 27/12/2016 08:08, David Lang wrote:
> > On Mon, 26 Dec 2016, Kathy Giori wrote:
> >> On Wed, Dec 21, 2016 at 11:31 PM, John Crispin <j...@phrozen.org> wrote:
> >>> i am still very much in favour of having 2 trees, one stable and one dev
> >>> tree. this would allow everyone to choose what they think fits their
> >>> needs best.
> >>
> >> I too have liked this idea since I first heard it.
> >
> > tl;dr this is a "I think you should do a lot of boring work" plan.
> > nobody is volunteering to do the work
> >
>
> we already have 2-3 volunteers and will most have a release branch that
> we maintain.
> i think you somewhat misunderstood what the discussion here is.
>
that may well be, but he clearly understood it the same way i did. that
may be because some terms are being used here in somewhat unconventional
ways, and some suggestions (as i understood them) sound really weird to
someone accustomed to usual release processes.
first, stop talking about trees. it's branches. whether a particular
branch lives in a separate repository ("tree") or not isn't relevant
from a technical side, because dvcs. however, it matters a lot from both
the practical and perception sides, so i *strongly* suggest that
anything that the re-merged project considers "official" lives in the
central source.git repository.
essentially as a corollary to that, you *positively* do not give
different branches different project names. specifically, this clearly
eliminates openwrt and lede as branch names.
nobody would contest the use of strictly controlled maintenance branches
which are associated with particular releases. the process for these is
typically cherry-picking a rather limited number of proven fixes from
the development branch, but with some discipline it's also possible to
apply fixes in the maintenance branch first and forward-merge them
subsequently. compare http://wiki.qt.io/Branch_Guidelines
so far, that leaves us with "master", "10.03", "12.09", "14.07",
"15.05", and (prospectively) "17.01".
now, what *seems* to have been suggested (but apparently was not) was
that "lede" would be the name of an *additional* branch which would
essentially be a shared staging branch.
mind you, the git project itself actually has such a thing (even two,
with different degrees of maturity) - see
https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt
however, as david noted - and i totally agree with it - it's entirely
unrealistic to have such a thing in a project with the breadth and size
of a linux distribution.
now, as i'm already writing, i'll also utter an opinion on the project
naming thingie.
openwrt is, indeed, a very strong brand in its market. as somebody else
suggested, even if the project wanted to change it, the brand's power
needs to be leveraged to bootstrap a possible successor.
"openwrt" looks cool in writing, and it sounds cool when said in german.
it's an utter tongue twister when said in "proper" english, which is _a
bit_ of an impediment marketing-wise.
lede is no brand at all, and the designated pronouciation kills any
chance of it becoming a brand. it's just too generic, as also already
noted by somebody else.
now, there is apparently a desire to reposition openwrt in the broader
embedded linux market, basically direct competition with openembedded.
my personal suggestion would be to stay focused. it's nice to support
more diverse hardware, and just fine if it comes basically for free (be
it because it's just so easy, or because a newcomer invested into it),
but for a project with openwrt's resources it simply doesn't make too
much sense to leave its primary niche. and the branding should reflect
that.
so my personal suggestion would be to stay with openwrt, and actually
release "designated driver". let "lede" remain the reboot of the
community (and associated processes), not of the product.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
