On Thu, Nov 14, 2013 at 09:52:59AM -0500, Marian Krcmarik wrote: > > > > On 11/13/2013 01:11 PM, Lucas Meneghel Rodrigues wrote: > > > TL/DR; > > > > So in a nut-shell, from an ordinary dev's perspective (not release > > management or maintainer) it's kind of like we're just renaming "next" > > to "master", correct? > > > > Documentation-wise then, where would we suggest somebody's initial > > experience come from, master or latest release? > > > > In general I think this is a good idea, however I'd caution against > > perceiving any urgency with this change. I think it would be healthier > > to set some future date, advertise it far and wide, maybe include a > > PR-freeze also, along with "countdown" announcements along the way. > > > > Essentially try to limit the "surprise" factor for people who may not > > keep up with ML or hangouts more than once or twice every few weeks. > > For some, the project is important, but keeping up with news may be > > fairly low on their list. Just a suggestion. > I take the opportunity of this thread and I would like to > stress out this point made by Chris. As regular user of > autotest with virt-test and less frequent contributor I do have > troubles to keep up with all the frequent and often massive > changes in autotest especially this year (mostly around virt > area), I understand the changes are driven by an effort to > simplify usage of autotest for new comers but It naturally > increases the "surprise" factors for regular but not very > frequent contributors. > Simply said I would appreciate lower speed of various changes - > in core code, API, conventions, repository and branches layout, > ... I try to push changes made by group I am part of every 2-3 > months and I always have to deal with various API, > repos/branches, convention changes, which is possible but takes > time which I would like to spend on writing tests themselves.
Hi Marian. The high speed of changes is a good sign, at least when we're talking about code changes. It shows that autotest and virt-test have active contributors and a healthy community. Just as with mainstream projects such as the Linux kernel or QEMU, a high rate of code changes is good, as long as we're moving forward and not introducing unexpected instability or gratuitous back and forth changes. Nevertheless, I take your point that we should not forget about these users who expect stability and can't keep up with the development pace. In this case, what we can offer is stable releases and clear documentation of the changes. Let's focus on improving that. I believe the new release process proposed by Lucas is a good move in simplifying things and keeping up with expectations for newcomers. Thanks. - Ademar -- Ademar de Souza Reis Jr. Red Hat ^[:wq! _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
