Re: Creating a branch for ATF pre-release code

["Julio M. Merino Vidal" <jmmv84%gmail.com@localhost>]

On Wed, Jan 14, 2009 at 3:06 PM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
> What you propose doesn't seem wrong, but it's effort that I am not sure
> is necessary.
>
> It seems like you are jumping through hoops to synchronize testing on
> multiple platforms.  What if you go ahead and publish a release and say
> that it's tested/verified only on NetBSD, and that testing on other
> platforms is appreciated or in progress, and then release 0.6.1 when
> other platforms are confirmed.
>
> The flaw in your logic seems to be that if you declare something a
> release then the rest of the world will import it to their repos, use
> it, etc. without thinking, so that therefore you can't.  What you're
> doing with prerelease branches seems a bit like working around that from
> the other end.

Well, I don't like publishing something knowing that it is probably
broken!  More so with a program that's supposed to help in testing ;)

The issue here is that updating to 0.6 is not easy because I also have
to migrate stuff to external/bsd, and this requires changes
everywhere.  It is not just simply updating a 3rd party package to a
newer version.  Maybe I can benefit from the branch now and not so
much in the future.

Also, the issue is that, as I mentioned, oftentimes you'll need to add
a new version to atf itself to use it later in your tests.  But you
have to hold back these tests until the new atf is released.  It'd
make sense if you'd put that code somewhere in the meantime.  This is
effectively the case with this specific release, because it will allow
me to import Lukasz' code later.  But, at the moment, I haven't got
his tests in place so it might happen that I publish the release,
import it and soon after realize that I forgot to add something to
make it really work with the new tests.

> Alternatively, find a way to build and install ATF from the ATF repo on
> a netbsd system and use that instead, perhaps with MKATF=no and doing it
> on the side.  I use this technique with upstream packages that are in
> pkgsrc, doing a build --prefix=/usr/pkg and overwriting the package.
> Not 100% clean, but easy for testing and very little work.

Yup, that's also a possibility that I've used in the past.  But it
becomes annoying and error prone.  You can't easily make sure that
everything will work when you do the real thing and submit it to src.

So yeah... maybe I'm seeing the need of a branch just because, this
time, I have to change lots of stuff.  Probably it won't be so in
further releases.

-- 
Julio M. Merino Vidal <jmmv84%gmail.com@localhost>