Mailing List Archive

Using Release Candidates to minimize user trouble?
Hi,

I was wondering if the use of MythTV release candidates would actually
help MythTV's releases mature before the actual release, or if they
would just hinder the current main focus for MythTV development, which
is major feature enhancements.

I would argue that release candidates would make the release version as
bugfree as possible, but this would imply a increased load on support
questions and the like. So what about an intermediate sollution, which
would be to just tag the CVS reposotory with release-0-14-rcX, in a
greater period of time, so that all developers actually could follow the
last steps of bugfixing a bit more close than a mere 'I'm planning a
release next week.' type of message on the forum?

I'm unsure of wheter this would actually ease the release cycle or put a
larger strain on the MythTV team, so comments on this subject is wery
welcome.

Merry X-mas to all those 'across the pond' ;)
Kenneth
Re: Using Release Candidates to minimize user trouble? [ In reply to ]
On Thursday 25 December 2003 12:12 am, Kenneth Aafløy wrote:
> Hi,
>
> I was wondering if the use of MythTV release candidates would actually
> help MythTV's releases mature before the actual release, or if they
> would just hinder the current main focus for MythTV development, which
> is major feature enhancements.
>
> I would argue that release candidates would make the release version as
> bugfree as possible, but this would imply a increased load on support
> questions and the like. So what about an intermediate sollution, which
> would be to just tag the CVS reposotory with release-0-14-rcX, in a
> greater period of time, so that all developers actually could follow the
> last steps of bugfixing a bit more close than a mere 'I'm planning a
> release next week.' type of message on the forum?
>
> I'm unsure of wheter this would actually ease the release cycle or put a
> larger strain on the MythTV team, so comments on this subject is wery
> welcome.

Well, I'd say that just a release candidate tag kind of defeats the purpose of
doing a release candidate, as people testing with it would not be getting any
bugfixes done since tagging unless the tag was moved after each commit.

I don't really like doing actual release candidates, mainly because of the
time commitment. Takes me quite a while to go through and get everything
ready.. Also, it breaks my version numbering scheme =)

I dunno, I just consider my 'I'm going to put out a release in a week' emails
to be a release candidate type thing.

Isaac
RE: Using Release Candidates to minimize user trouble? [ In reply to ]
On Thursday 25 December 2003 01:19 pm, Isaac Richards wrote:
> On Thursday 25 December 2003 12:12 am, Kenneth Aafløy wrote:
> > I was wondering if the use of MythTV release candidates
> > would actually help MythTV's releases mature before the
> > actual release, or if the would just hinder the current
> > main focus for MythTV development, which is major feature
> > enhancements.
> >
> > I would argue that release candidates would make the
> > release version as bugfree as possible, but this would
> > imply a increased load on support questions and the like.
> > So what about an intermediate sollution, which would be
> > to just tag the CVS reposotory with release-0-14-rcX, in a
> > greater period of time, so that all developers actually
> > could follow the last steps of bugfixing a bit more close
> > than a mere 'I'm planning a release next week.' type of
> > message on the forum?
> >
> > I'm unsure of wheter this would actually ease the release
> > cycle or put a larger strain on the MythTV team, so
> > comments on this subject is wery welcome.
>
> Well, I'd say that just a release candidate tag kind of
> defeats the purpose of doing a release candidate, as
> people testing with it would not be getting any
> bugfixes done since tagging unless the tag was moved after
> each commit.

I might be speaking out of just my head, but wouldn't this
just be a cvs management problem (which developers are
supposed to keep track of), that involves the cvs commands
'cvs up -A', 'cvs up -r <rel>' and 'cvs up -f' to be
used in the correct cases. Since a tag merily match a set
of files, the 'cvs up -f' will force a head tag, which
will include the last set of patches since the last rc.

> I don't really like doing actual release candidates, mainly
> because of the time commitment. Takes me quite a while to
> go through and get everything ready.. Also, it breaks my
> version numbering scheme =)

Actually, with the cvs tag approach, the effect on the version
numbering scheme would be next to none, except for the fact
that those involved in release candidate testing *should* be a
part of the development of mythtv community (or has been).

Also, the cvs tag approach would also limit any binary packages
(hopefully), of any release candidate to reach the web.

This is offcourse the real commitment, on your part, unless
you assign the payload of prepping a release tag to someone
else that might not be as heavily loaded with tasks.

Also, the primary focus (on the first rc, or so) could only
be focused only on the main mythtv program and library,
as it's the largest one yet. Also in this phase any
inconsistencies between the main mythtv module and the
mythtv plugins could be resolved, if any, which would ease
the task of preparing further release (candidates).

This might also have the side effect of waking up the
developer that might be deeply incorperated into a patch
that he or she is working on, and bringing them forth to the
testing phase of the release cycle.

> I dunno, I just consider my 'I'm going to put out a release
> in a week' emails to be a release candidate type thing.

I'm actually unsure myself, but I felt that my own arguements
was so on bordeline that I might as well try to put my points
through on the board instead of my head.

Kenneth
Re: Using Release Candidates to minimize user trouble? [ In reply to ]
On Thursday 25 December 2003 07.17, Isaac Richards wrote:
> On Thursday 25 December 2003 12:12 am, Kenneth Aafløy wrote:
> > Hi,
> >
> > I was wondering if the use of MythTV release candidates would actually
> > help MythTV's releases mature before the actual release, or if they
> > would just hinder the current main focus for MythTV development, which
> > is major feature enhancements.
> >
> > I would argue that release candidates would make the release version as
> > bugfree as possible, but this would imply a increased load on support
> > questions and the like. So what about an intermediate sollution, which
> > would be to just tag the CVS reposotory with release-0-14-rcX, in a
> > greater period of time, so that all developers actually could follow the
> > last steps of bugfixing a bit more close than a mere 'I'm planning a
> > release next week.' type of message on the forum?
> >
> > I'm unsure of wheter this would actually ease the release cycle or put a
> > larger strain on the MythTV team, so comments on this subject is wery
> > welcome.
>
> Well, I'd say that just a release candidate tag kind of defeats the purpose
> of doing a release candidate, as people testing with it would not be
> getting any bugfixes done since tagging unless the tag was moved after each
> commit.

I am using CVS branches to do this right now in another project. For example
for the next release:
* Split off a rel-0_14 branch (CVS don't like dots in the tag names)
* Only do bugfixes in that branch
* Tag and release as rel-0_14_0, rel-0_14_1
* Continue "bleeding-edge" development in the HEAD branch
* Merge bugfixes from the branch into HEAD at each release


> I don't really like doing actual release candidates, mainly because of the
> time commitment. Takes me quite a while to go through and get everything
> ready.. Also, it breaks my version numbering scheme =)

Agreed, takes more time but brings better order. See above about extended
version numbers :-)


> I dunno, I just consider my 'I'm going to put out a release in a week'
> emails to be a release candidate type thing.

Good enough for me since I normally run the CVS version :-)

/ Tobbe
Re: Using Release Candidates to minimize user trouble? [ In reply to ]
On Thursday 25 December 2003 01:53 am, Kenneth Aafløy wrote:
> I might be speaking out of just my head, but wouldn't this
> just be a cvs management problem (which developers are
> supposed to keep track of), that involves the cvs commands
> 'cvs up -A', 'cvs up -r <rel>' and 'cvs up -f' to be
> used in the correct cases. Since a tag merily match a set
> of files, the 'cvs up -f' will force a head tag, which
> will include the last set of patches since the last rc.

Yeah, but then people are just using CVS head and not the tagged RC. Might as
well just use CVS head =). Then, of course, there's making an actual branch,
and not just a tagged version:

On Thursday 25 December 2003 12:27 pm, Tobias Blomberg wrote:
> I am using CVS branches to do this right now in another project. For
> example for the next release:

If it were going to be a longer 'getting stable' period than a week or so, I
might go for branches.. As it is, I really don't like doing a branch unless
it were absolutely necessary, as the eventual merge is just extra work.

On Thursday 25 December 2003 01:53 am, Kenneth Aafløy wrote:
> Also, the primary focus (on the first rc, or so) could only
> be focused only on the main mythtv program and library,
> as it's the largest one yet. Also in this phase any
> inconsistencies between the main mythtv module and the
> mythtv plugins could be resolved, if any, which would ease
> the task of preparing further release (candidates).

<shrug> I'm pretty careful about changes that involve all plugins -- I rarely
have had things broken for more than a day or two.. Wouldn't expect it to be
an issue in the future.

Ah well. Anyone else that participates in development want to comment? I'm
fairly happy with the status quo, but...

Isaac
Re: Using Release Candidates to minimize user trouble? [ In reply to ]
> Ah well. Anyone else that participates in development want to comment? I'm
> fairly happy with the status quo, but...
>
> Isaac

Ditto, I think there's enough people using CVS head to catch most problems,
and we're still only at a 0.1x version anyway. I haven't installed a "release"
version in over a year myself even before I started developing on Myth. My
dev system runs CVS head and I usually upgrade my "production" systems
whenever there's a change that breaks frontend/backend communications so I
can still use my dev box to connect to the master backend.

--

Chris
RE: Using Release Candidates to minimize user trouble? [ In reply to ]
Hi,

Chris Pinkham wrote:
> Isaac Richards wrote:
> > Ah well. Anyone else that participates in development want
> > to comment? I'm fairly happy with the status quo, but...
>
> Ditto, I think there's enough people using CVS head to catch
> most problems, and we're still only at a 0.1x version anyway.
> I haven't installed a "release" version in over a year myself
> even before I started developing on Myth. My dev system runs
> CVS head and I usually upgrade my "production" systems whenever
> there's a change that breaks frontend/backend communications so
> I can still use my dev box to connect to the master backend.

Would not this reference more of your personal preference than
what would benefit the user the most?

What the general concept would be, is that once users (of the
previous release) notices that the CVS version has been tagged
with release candidate status, a larger part of the user base might
be attracted to upgrade to the CVS version.

And, yea, we are at version .1x, but the codebase is getting larger
every day, and fixing every bug in every release without more testing
by the users of MythTV, will get harder as time goes by. My point
beeing that eventually it will be needed, whether or not to
start now is not up to me...but the users, really...

Kenneth
Re: Using Release Candidates to minimize user trouble? [ In reply to ]
> Would not this reference more of your personal preference than
> what would benefit the user the most?

That's the key... As Isaac and others have stated several times,
Myth isn't developed for the users, it's developed for the
developers. When a developer wants a new feature they code it
up. When a user wants a new feature they wait until either they
can code it or a developer decides they want it enough to code it.

--

Chris
RE: Using Release Candidates to minimize user trouble? [ In reply to ]
Chris Pinkham wrote:

> > Would not this reference more of your personal preference than
> > what would benefit the user the most?
>
> That's the key... As Isaac and others have stated several times,
> Myth isn't developed for the users, it's developed for the
> developers. When a developer wants a new feature they code it
> up. When a user wants a new feature they wait until either they
> can code it or a developer decides they want it enough to code it.

So, I should wait then.

Happy New Year,
Kenneth.