----- Original Message -----
> From: "Ademar de Souza Reis Jr." <[email protected]>
> To: "Marian Krcmarik" <[email protected]>
> Cc: "Chris Evich" <[email protected]>, [email protected], "Virt Test 
> Development Mailing List"
> <[email protected]>
> Sent: Thursday, November 14, 2013 5:16:26 PM
> Subject: Re: [Autotest] RFC: Release management
> 
> 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.
Hi Ademar,

I had mostly API, Convention and repositories layout changes in my mind, not 
really any code changes such as new tests, extended functionality, etc., Maybe 
I did not express myself clearly so short description of my workflow may help.
I take latest "stable" release of autotest/virt-test because I am into creating 
some new tests only and I do not want to care about framework itself (in terms 
of development or debugging possible bugs), I am happily  developing my tests, 
Once I am happy with my tests I pull the latest code (That's the only choice) 
to rebase my patches on, Mostly the time frame is 2-3 months and then I imo too 
often have to deal with some of the problems like:
- my already existing tests are broken meanwhile (Not because of changes in 
tested functionality or test itself).
- layout of repository/branches/administrative changed
- Conventions changed
- Exceptions/Conflicts in/with my code due to API/Structures changes.

I do not argue specific steps proposed by Lucas in this thread I just hijacked 
the thread to express my troubles as well as I do not expect to avoid all the 
problems I mentioned, They are just imo too often and too much for not very 
frequent contributor who wanna use autotest/virt-test for developing tests and 
basically There are no maintained stable versions of autotest so I was very 
close to keep my own fork and not following autotest/virt-test upstream anymore.

Yes, having standard stable maintained releases with stable API would help me I 
believe. There were some plans about stable 1.0 release already almost 2 yrs 
ago:).

Marian

> 
> 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

Reply via email to