Le lundi 30 octobre 2006 21:39, chris guirl a =E9crit=A0:
> On 10/30/06, Gon=E9ri Le Bouder <goneri@...> wrote:
> > First I want to precise that I got Matthew agreement when I began to
> > package
> > VDrift and I used the work he did (Saddly I had to remove his great cdbs
> > script).
>
> That's OK, I think I remember this too. By the way, I think cdbs will work
> again; right after the 7-8 release Matthew did a lot of work updating the
> SCons system to relieve the problems that broke our deb build before.
> Unfortunately I had already done the source release, so you didn't get
> these changes.
We had a discution about CDBS in the Team and we decide to remove it from=20
every packages:
http://wiki.debian.org/Games/ToolsDiscuss
That's why I decided to remove it.
> Well, my main concern is with consistency. If we build packages here,
> and you build a different package, that confuses users
> who might get our package, or might get yours from their
> repository...so I guess if you want to keep it on Debian Games SVN, we
> need to find a way we can apply the changes made to your build to our
> deb builder, so that we can have the same structure as the ones you
> release. How
> can we achieve this?
You are welcome in the team :).
Joining the time as easy as creating an account on alioth.debian.org and=20
asking for the inclusion in the Team.
We use very common tools like svn-buildpackage to make things easy.
I don't want to impose this but I really think it's the best way to keep=20
things stantard.
Best regards,
Gon=E9ri

Le lundi 30 octobre 2006 15:47, Matthew A. Nicholson a =E9crit=A0:
> chris guirl wrote:
> > One thing that I'd also like to see with the Debian package if possible
> > is to do some package maintenance
> > upstream (in VDrift SVN
> > repository). This would allow us to do Debian builds when we do regular
> > VDrift releases, and thus debs would be available immediately when we
> > release. What do you think about this Gon=E9ri, Matthew and others?
>
> I have always like maintaining packages upstream. As long as the
> upstream developers are responsive, it takes one more step out of the
> process.
=46irst I want to precise that I got Matthew agreement when I began to pack=
age=20
VDrift and I used the work he did (Saddly I had to remove his great cdbs=20
script).
In the Debian Games Team there is some Debian and Ubuntu Developpers or=20
Maintainers that do collaborative works. The main adventage are :
- bug can be fixed and upload more quickly (everybody in the team gets th=
e=20
bug report)
- the team give a global review of the package (e.g: translation or bug=20
fix). This is the current changelog of vdrift.
http://packages.debian.org/changelogs/pool/main/v/vdrift/vdrift_0.0.2006.10=
=2E06-1/changelog.html
- we use tools to have an overview of the packages issues
http://nana.rulezlan.org/~goneri/pkg-games/html/pkg-games-devel_at_lists.al=
ioth.debian.org.html
I'm convinved that Debian Games svn is the best place to comaintain vdrift =
and=20
it's still possible to prepare prepackage (beta, svn release).
Best regards,
Gon=E9ri

chris guirl wrote:
> One thing that I'd also like to see with the Debian package if possible
> is to do some package maintenance
> upstream (in VDrift SVN
> repository). This would allow us to do Debian builds when we do regular VDrift releases, and thus debs would be available immediately when we release. What do you think about this Gonéri, Matthew and others?
I have always like maintaining packages upstream. As long as the
upstream developers are responsive, it takes one more step out of the
process.
--
Matthew A. Nicholson
matt-land.com

Thinking about our data packages, there is some overlap in the data sets:
Full: (cars: (3S, AX2, CO, CS, FE, FF, G4, GT, M3, M7, MC, MI, RG, SB, T73,
TC, TL, XG, XM, XS, Z06), tracks: (Brands Hatch, Circuit de Pau, Detroit,
Laguna Seca, Le Mans, Monaco, Monza, N=FCrburgring Nordschleife, Road Atlan=
ta,
Ruudskogen, Spa Francorchamps, Weekend Drive, Zandvoort) )
Minimal: (cars: (CO, FF, TL, XS), tracks: (Laguna Seca, Zandvoort) )
You can see that the full package has the cars that are in the minimal
package already, which is of course redundant.
Gon=E9ri apparently noticed this when he was setting up his Debian
package, because vdrift-full does not include any of the data that is
already in vdrift-minimal. If
a user wants *all* the data, they have to install all three packages.
This seems like a better idea, because it reduces our full data set by
about 30 MB. In any case the user does not download any redundant
data.
So the question is, should I set the Autopackages up this way too? The othe=
r
question that comes to mind is should we just include the minimal data with
the game, and make the full data always be an add-on
package? Or does it still make sense to split even the basic data out
of the executable package? If the minimal data is always required,
would it make more sense to call it common data than minimal data?

On 30 Oct 2006 12:53:59 -0000, Goneri Le Bouder <goneri@...> wrote=
:
>
> >* Decide what to do about Debian package(s)
> Debian package for the 2006.07.08 release is in Debian unstable. The
> package is maintained on Debian Games SVN and I invite Matthiew to join
> us.
> http://packages.debian.org/vdrift
Excellent! Thanks for your work on this end Gon=E9ri. I see that you have =
the
packages split into three (two data, one executable). I like this setup
because it's consistent with how we release the game. Just a thought, do yo=
u
think that maybe the names of the data packages would be more clear as
"vdrift-data-full" and "vdrift-data-minimal"? Also, I see that
vdrift-minimal is required by vdrift, and vdrift-full is
optional. I also see that vdrift-full is not in conflict with
vdrift-minimal, as I'd expect (if it was set up like the regular
VDrift data packages); in
fact, it requires it. This gets me thinking about our data package
structure...but I'll start a new thread about that.
One thing that I'd also like to see with the Debian package if possible is
to do some package maintenance
upstream (in VDrift SVN
repository). This would allow us to do Debian builds when we do
regular VDrift releases, and thus debs would be available immediately
when we release. What do you think about this Gon=E9ri, Matthew and
others?

Hi all,
>* Decide what to do about Debian package(s)
Debian package for the 2006.07.08 release is in Debian unstable. The
package is maintained on Debian Games SVN and I invite Matthiew to join
us.
http://packages.debian.org/vdrift
Regards,
Gon=E9ri

Welcome, everyone, to the new VDrift-Devel list. I think everyone who is
going to join right now has done so, so I guess it's time to start using
it...
Just as a summary of what's been going on lately, there's been a good bit of
work since the last release on fixing bugs and adding little features we've
been wanting to for some time. Details of what's been done is posted here: <
http://vdrift.net/Forum/viewtopic.php?t=374&gt; and there's always the SVN log:
<http://svn.vdrift.net/viewvc.py/trunk/?view=log&gt; if you want way too much
detail.
Looking ahead, we'll probably shoot for another release mid to late
November. There are a
few sizable tasks to be completed between now and then. Here are the
things I think are most important:
* Getting all tracks and cars prepared for bumpy/slippery surfaces
* Fix problems with Windows build
* Decide what to do about Debian package(s)
* Simple custom parts menu
Here are some other things that would be very nice but are less important:
* Original tracks: parking lot, dirt/rally track
* Per-car custom gauge textures
* Working in-dash gauges
* Player Profile + multiple lap times
* New menu skin
Please share your ideas on priorities, other important things that need to
be fixed, etc. If you have a particular issue from the list which you'd like
to discuss in depth, start a new thread. Thanks...

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details