+1 donald
On Sat, May 21, 2016 at 3:31 PM, Lou Berger <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 > 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
