+1
On 5/23/2016 12:45 PM, Donald Sharp wrote:
+1
donald
On Sat, May 21, 2016 at 3:31 PM, Lou Berger <lber...@labn.net
<mailto:lber...@labn.net>> wrote:
So in thinking about the problems we are discussing this and a
little bit more, considering the comments made on the list as well
as the ubuntu link I sent yesterday[1] a few things struck me:
([1] https://wiki.ubuntu.com/TimeBasedReleases)
1) Having stable release is most import to some in the community
2) Having a way of getting fixes/changes/new features in a release
in a predictable time frame is most import to some in the
community
3) We are not leveraging those in the community with an "adventurous
spirit" [1] who are willing to review/test the most current
development version
4) Others have been down this road before, and we/I could learn from
them
While #1 and #2 seem to be in conflict of each other, I think the
ubuntu community has a fine answer to this i.e., two editions. So
what do folks think about following a similar approach and having:
- Long Term Edition (LTE)
- Cutting Edge Edition (CE)
LTE could live in /releases/LTE/... branch tree, follow the
existing/old process, including in release schedule. LTE versions
could be based on the current scheme e.g., 1.0.20160309, or simply
year based 2016.<rev#>.
CE could live in /releases/CE/... branch tree, follow the new
process (some details still to be documented), and be released every
N months -- Ubuntu uses N=6, I was hoping for 4 -- and have
maintenance
releases as needed. Release numbers could increment on each time
based release (2.0 is the next one) and the number after the decimal
place could be used for maintenance. "rcN" would be used for
release candidate branches assuming there is a pre-release
stability branch/period.
To address #3 above, master could be the place where patches go
once acked in the new process, and /release-candidate/CE/<rel#>.rc0
could be branched from master every N months. Once there is a
release could be tagged and placed in /releases/CE/<rel#> which
would also as the head for any maintenance releases. RC branches
could be deleted on release, or left around for a period of time.
There would also need to be a /releases/LTE/master that contains
patches acked per the existing/old process.
BTW the related quote from [1] on this topic is great and something I
think worth aspiring to:
Ubuntu users are a diverse bunch, and given the chance, history
shows that they will test new features thoroughly simply by
using and experimenting with their systems. You should take
advantage of the adventurous spirit of users who track the
development branch, and give them a chance to help you test.
Obviously this is just an outline / straw man at this point, but
I'd nonetheless be very interested in thoughts/reactions to this.
So please disagree/agree/improve/comment/etc.
Lou
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net <mailto:Quagga-dev@lists.quagga.net>
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
