Rich Brown <richb.hano...@gmail.com> wrote:
> - Having a firm feature freeze date decreases stress. If a particular
> feature is done/substantially working, it goes in. If it's not quite
> ready, it can skip this release, and get into the next release. (The
> alternative is what I think happened with DSA. It was a big change:
> there were a large number of problems that took a long time to iron
> out. That kept pushing out the date...)
I think you are bang on here.
And it needs to be socially acceptable to skip.
And yet the release is the forcing function.
In order to get things sorted for things like DSA, in an ideal world it
would be a choice of two different packages. The safe one as the default,
and the unstable one as a patch.
Of course, that's hard to do for many things.
In working backwards on dates, identifying the things that might be a
problem and having a "developer beta" from an easily rebased branch
would help for stuff like DSA.
> - Customers (our users, our industry partners) gain confidence in
> projects that can meet their deadlines. Imre noted that "industry is
> using the snapshots..." but I suspect the extended schedule just
> worries other vendors.
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
