Gluon v2020.2 Tracking Issue

[mweinelt]

Gluon v2020.2 is due at the end of this month according to what we decided last year. We have quite the bunch of exciting features, so we'd like to stabilize our current featureset and invite everyone to start testing.

TODOs:

• Release notes https://md.darmstadt.ccc.de/hQbpAjJiQXSrfAAzCjZgKw
• Evaluate open milestone entries https://github.com/freifunk-gluon/gluon/milestone/16

If I missed anything, please speak up.

[rotanid]

i don't agree with any new major Gluon release which again postpones work first sent for review by @christf in part over a year ago, three PRs come to my mind.
Although i don't personally need this work, this is not how we should deal with contributors.

In other words, i'm against fixed release dates ubuntu-style and pro-"it's done when it's done"-debian-style.

EDIT: and apart from that, i'm against such short release cycles, most Gluon-Framework-Users can't keep up with this pace.

[mweinelt]

i don't agree with any new major Gluon release which again postpones work first sent for review by @christf in part over a year ago, three PRs come to my mind.

I review everything I feel capable of reviewing. Particularly:

• introduce XLAT, native IPv4 for clients #1808
  • Reviewed by me 18 days ago.
• gluon-mesh-babel: Reduce load in respondd #1799
  • I don't feel capable of reviewing that, do you?
• Add Wireguard Support to gluon #1534
  • Review happened several times by me and others.
  • The latest sentiment is that the broker code should be externalized,
  • IMO the broker code just does not have the quality required for merging it right now.

There is nothing actionable from my POV.

Although i don't personally need this work, this is not how we should deal with contributors.

I agree that our reviews of these PRs are sometimes lacking, but that is far from intentional. We lack reviewing skills and resources when it comes to a) C code and b) large pull requests, that is neither a new nor a surprising fact.

In other words, i'm against fixed release dates ubuntu-style and pro-"it's done when it's done"-debian-style.

Yet that is what we decided last year, that is why we created the milestones with these dates. Unforrtunately I can't find the related protocol … meh.

EDIT: and apart from that, i'm against such short release cycles, most Gluon-Framework-Users can't keep up with this pace.

So what is your proposal now?

I'm personally against delaying releases much due to pulls that are not in shape yet. I'm however fine with delaying the release by up to 6 weeks. We do have lots of prominent features already.

[rotanid]

after looking at the PRs again and reading your comment, i agree that at the moment we can't do much, it would be up to the author or neoraider in part to get on with them.
Looking at the history of the PRs though, most of the time went by waiting for someone to review, not for the author to react.

I'd like to note that i neither blamed you personally nor did i say it is intentional.
The one thing which we could clearly do better in the future though is communication, as i know that the criticism which was voiced lately in one of the PRs wasn't really new, but hasn't been written down earlier. Especially if we have somewhat fundamental concerns about a change, we really need to address this early.

I think the meeting you're missing the protocol of is the one i couldn't attend, therefore i may have not known about this decision.
As you may very well know yourself, what i wrote above is true though: most Gluon-Framework-Users can't keep up with this pace, if we would keep it up and have like 3 or even 4 releases this year...

maybe we have blocking issues btw, e.g. #1982 or #1943 ?

[blocktrron]

We most likely won't worsen things with #1982 . So i would give that a pass.

For #1943 I'm still waiting for anyone to react. Otherwise I'm for removing this device (or adding the BROKEN flag).

[rotanid]

1943, fine with me.
1982, in my opinion releases should not be there to push features early and often...

[rotanid]

i marked two issues as release blockers. EDIT: they are fixed.
apart from what we already got in the milestone, i think we should look at the following PRs which could be nice to have in the release:
#2011 @NeoRaider - DONE
#2028 @blocktrron - DONE
#2033 @NeoRaider - DONE
#2037 @NeoRaider - DONE
#2041 @Sprinterfreak - DONE

[rotanid]

we (@NeoRaider @mweinelt ) decided on IRC to do this release in the next week or so, if nothing new pops up

[rotanid]

@blocktrron suggested to backport #2068 and @NeoRaider confirmed

[rotanid]

apart from #2068 we also wanted to include #2074 , both have yet to be backported

[blocktrron]

Backported both just now.