Licensing update policy
by Max Rees
I recall reading an article or email on LWN a few weeks ago concerning
a distribution's policy for re-auditing licenses for packages and I
wanted to determine what we should use as our policy. As it stands, we
obviously audit the license for each new package that goes into master -
but when should we re-audit the license of a package? I think a
reasonable suggestion would be on every feature update, since every
feature has the potential to bring in code with a different license. As
a caveat, maintainers should also be vigilant for notices of licensing
changes in the changelogs regardless of the type of release.
Any thoughts on this?
Max
2 years, 8 months
Version freeze for 1.0-BETA1
by A. Wilcox
I'd like to have a more concrete understanding of what we want in a
version freeze. Some discussion was already had on IRC.
* No more feature releases.
This would mean 18.08 -> 18.12 for KDE would not happen, for instance.
* Security patches always.
So (for instance) OpenSSL 1.0.2o -> 1.0.2p would always happen.
* Bug fixes?
What about KDE 18.08.2? That would be strictly for crashes and fixes,
not new features.
A few concerns I have...
* We are very close to having Rust. Once we have Rust, we can upgrade
to Firefox 60 ESR. This could be considered a security patch, but it is
also a significant feature release: there are no more XPIs.
* The binutils project has just released 2.31. This is a bugfix release
but it also is technically a feature release as well. We may need it
for some musl fixes, especially on tier3 architectures (which I suppose
are not that important) - I'm unclear on this right now.
* Future musl releases. If 1.1.21 brings us more POSIX conformance, but
also includes the header rewrite and such, what should we do?
Input is greatly appreciated. Thank you.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 8 months
Making 1.0 a non-LTS release
by A. Wilcox
Hello all.
I was thinking that perhaps 1.0 being our first release should not be a
long term support release. That is, it would only be supported for 18
months (until 1.5), not the full 3 years (until 2.0).
Would this be acceptable?
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 8 months