How long are we giving for bug fixes docs and stabilizing. Roughly? Chris M
-------- Original message -------- From: Moses McKnight <mo...@mcktex.com> Date: 2019-05-30 8:40 a.m. (GMT-07:00) To: EMC developers <emc-developers@lists.sourceforge.net> Subject: Re: [Emc-developers] 2.8 Release planning There is a release checklist here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ReleaseCheckList Some of the work involves the buildmaster, so I think either Seb will have to do some of that or give someone else access to do it. The live image does need to be made as well. Another thing that will require some work is documenting all the changes from 2.7 to 2.8 You may be right about mailing list over IRC. Taking a few days to discuss something is probably not bad though. Moses On 5/30/19 8:26 AM, John Thornton wrote: > Yep lets do it! > > What else has to be done to get the release out after creating the branch? > > I assume we need to have a 2.8 LiveDVD at some point? > > I think timing is an issue for IRC meetings, one advantage to the mailing list > is you don't have to be there at any specific time. The disadvantage is it can > take a few days to discuss something on the mailing list. > > JT > > On 5/29/2019 8:04 PM, Moses McKnight wrote: >> Hi All, >> >> It seems that there is somewhat of a consensus to release 2.8 with it's >> current features plus bugfixes. >> >> This means that major features such as reverse run would not be in 2.8, but >> would be merged into master as soon as 2.8 is branched off. >> >> So this is kind of a last call for comments - if a majority are for it then I >> or someone will create the 2.8 branch in the next few days. >> >> Rob had some good ideas for improving on releases: >> >> On 5/21/19 4:53 PM, Robert Ellenberg wrote: >>> FWIW, I would also like a more formal release schedule. The team has done a >>> good job of pushing out point releases for 2.7, but it seems like 2.8 is an >>> ever-receding goal. Some ideas for how to improve: >>> >>> - Periodic dev meetings (IRC or via videoconference) to set milestones >>> and document our decisions (so we're not constantly second guessing >>> ourselves or having to re-answer the same questions). >>> - Identify some areas of expertise and/or responsibility (and list them >>> publicly) so that contributors know who to include in their pull >>> requests / >>> code reviews. Bugs in can be assigned to experts to triage / fix, or >>> delegate to someone who can. >>> - Expand test coverage, particularly unit tests. I have some tests >>> implemented in my branches (basic tests for TP and interp), but this >>> would >>> be a long-term effort to get wide coverage, particularly in >>> rarely-touched >>> code >> >> As far as a formal release schedule - I guess we could just say something >> like >> a major release every year and point releases 4 times a year? I suppose >> having a schedule and missing or skipping release dates now and again is >> better than not having a schedule. >> >> There used to be some periodic dev meetings on IRC. I can't remember why we >> quit, but it seemed like there wasn't a whole lot discussed in the few I was >> able to be in. I would vote we start them back up and I would prefer IRC. >> The main thing is that someone would need to do the documenting and we would >> have to have a place to do that (wiki, github issues etc?). >> >> In any case, hopefully we can release the next major version much sooner than >> this one has taken. >> >> Moses >> >> >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > -- And as it is appointed unto men once to die, but after this the judgment: So Christ was once offered to bear the sins of many; and unto them that look for him shall he appear the second time without sin unto salvation. (Hebrews 9:27-28) _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
