[LEDE-DEV] Stability & release plans

[Jo-Philipp Wich]

Hi

> 2. When looking at lede I'm somewhat missing the release engineering 
> part. This has nothing to do with infrastructure or build setups or
> even coding. When looking at Debian they have a release team taking
> care of freezing, planning and releases. - or take Theo de Raadt's
> job in OpenBSD for instance.

We have to start somewhere, and having the technical base available to
actually build releases is a good first step.

I agree that eventually there needs to be a release engineering team but
it makes no sense to have that in place when nobody is actually able to
build releases. Also code freezes or branches make less sense when no
one is able to produce suitable, updated binary artifacts - that is the
main reason why we try to solve the technical hurdles first.

> IMHO From a release engineering point of view it's good to do release
> if a software is reasonable better then the one released before. From
> a developer's point of view, it's good to release, if he or she feels
> confident with his or her work and all annoying bugs are fixed.

Yes.

> IMHO planning a lede release is worth the effort if it's reasonable 
> better then the last OpenWRT-Release, no matter what bugs,
> refactorings or infrastructure issue are outstanding, still. Having a
> fixed schedule (every 6/8/12 months) or so will ease discussion on
> when to release and what features to include, since freeze-dates,
> commit-handling etc. are more or less fixed.

Yes.

> IMHO it is an interesting idea to announce a release in six months or
> so (one year after its founding :-) ), make a plan on freezing /
> branching / etc. and stick to fixed schedule (every n months)

I will feel much more confident about this once we actually did a
release test (means a test on how to build a binary release, not a
release for testing binaries) - then we can start planning schedules.

In the past, building OpenWrt binary releases was a painful, manual and
time consuming task which took between 4 to 8 weeks to pull of.

> I offered help on this to nbd on 2012's (2013 .. maybe) Wireless 
> Community Week and my offer is still stands. Not being a OpenWRT /
> lede veteran  I'm not interesting in taking the lead here. I'm not
> interested in bossing somebody around of becoming a ego-manic project
> lead ..,. Back in 2012, there was hardly any interest in this kind of
> help, but I'm not sure, if the lede split has changed anything here.

Help is pretty much appreciated in, any direction :)

> 3. I think, gluon is doing an good job here. They're taking the
> OpenWRT / lede codebase and release it in a concise way.
> Unfortunately - due to releasing no binary artifacts - they address
> power-users instead of novices. And gluon - in its current form - can
> hardly be used to just flash and use a SOHO router for whatever is
> interesting.

I cannot tell much about Gluon, I never used it myself but I did notice
that it has a rather continuous and solid development model. Also with
Matthias on board I am confident that some experience can be shared here
in the long run.

> I don't know much about tcatm's plans for gluon. I don't know, if
> binary releases are on its map or if synchronizing gluon and lede
> releases is a good idea. But ... IMHO it's worth thinking about
> this.

Sure, it might make sense to leverage synergies here (sorry for the BS
phrase) but for example I think that Gluon has a good testing exposure
and valuable community feedback which are things LEDE can certainly
benefit from.

> That's it. I'll be at the 33c3 by the end of the year, so if you're
> interested discussing this in person, I'm available ;-).

I'm sure some people will attend the 33c3 - for the rest we can maybe
stage a video conference or something to exchange ideas. Personally I'll
likely not able to be there but I would appreciate some discussions
nonetheless.


Regards,
Jo