Re: [FFADO-devel] New rc/release soon?

[Jonathan W. <jw...@ph...>]

> On Friday 04 December 2009 15:45:28 Patrick Noffke wrote:
> > On Fri, Dec 4, 2009 at 5:45 AM, Arnold Krille <ar...@ar...> wrote:
> > > And as you are the one with Motu devices at your hands, you will probably
> > > be the one to forward-port the stuff affecting these code-paths.
> > For what it's worth, I have a MOTU 896 HD, and if there is specific testing
> > you need, I'd be happy to help.  I do not use my device all that much
> > lately, but it's there if you need something.  I also have a PCI Lynx card,
> > but I've since trashed my machine that I used it with (sniffing would
> > require a re-install of some distro).
> 
> If I understand Jonathan correctly, there was bug-fix and new device support 
> done in 2.0-branch and major infrastructure rewrite done in trunk.

Not quite, sorry for the misunderstanding.  This was how the situation
*could* have developed, but I chose not to go down that path because of the
difficulty in eventually merging the multiple branches back together (the
infrastructure wasn't "rewritten" though - it was more just added to).

Initially only MOTU bugfixes went into 2.0-branch, or tables to support
additional devices which were very closely related to those we already
supported.  Then the "mark3" devices appeared and I was faced with an issue. 
If I wrote the infrastructure to support the mk3 devices in trunk then trunk
and 2.0-branch would diverge significantly, making it less than trivial to
merge the 2.0-branch changes back to trunk at some point in the future.  So
I went with the other option - put this additional infrastructure into 2.0
to make the eventual forward port of this stuff much easier.

I agree it wasn't the best theoretical solution, but at the time it seemed 
to be the easiest way of keeping track of everything, especially since
fairly significant improvements were being made to other areas of the ffado
infrastructure in 2.0-branch.

> Bringing them back together is imho only possible with a) a working motu
> device and b) deep knowledge of the code-base.

I suspect not in this case; because I basically kept 2.0-branch as the
"current" version the merging should be mechanical (which was part of the
reasoning behind doing things this way).

> But after all these forward-ports are no reason to delay 2.0.

Not at all - I'm certainly not suggesting that.  It's just an issue that I
wanted to bring up to make sure that I knew what Pieter and others planned
in relation to it, in part to prevent duplicated effort.

> The release is also not a reason to stop bugfixes to go into the branch

I agree - that's why there's a branch.  But once a release is made it *is*
strictly bugfixes and there's no confusion as to where developement is done.
Things got a bit grey about 6 months ago.

> I think the main reasons to delay 2.0 at this time are a) if there are
> changes in ffado necessary to make it work with a new libraw1394 on juju
> and maybe b) to change the timer source to something that is not
> influenced by ntpd. But b) could also be "fixed" by a note "stop ntpd".

I agree that (b) isn't *that* big a deal.  Using ffado with the new
libraw1394 is of course an issue, but given how long 2.0 has dragged on I
think I'm with Pieter - let's just get it out there and do the juju thing in
2.1 (with a *much* shorter branch time).

Regards
  jonathan