[Games] Status update

[Dmitry Marakasov]

* Richard Hartmann (richih.mailinglist at gmail.com) wrote:

> > with it's AUR [3]. Search shows it has 889 games as of now, so I
> > guess it's worth contacting as well [4].
> Does OpenBSD even accept something like this? Do you know
> which lists we could contact wrt OpenBSD and Darwin?
Seems like both have mailing lists.
http://www.openbsd.org/mail.html
On http://darwinports.com/ though, maillists link seems broken

> And we want to be bold. If we need to throw away half a dozen repos,
> so what? The real work, the patches, will still be there. And we will
> then be able to use a layout, techniques etc which are known to
> work for everyone.
Then any repo will do for now.

> > So the layout I propos is as follows:
> >
> > tuxracer/
> >  freebsd-64bit-support/
> >    patch-src-main.c
> >    patch-src-engine-number.c
> >    patch-src-engine-string.c
> >  ubuntu-dotdir-fix/
> >    dotdirfix.patch
> > xmines/
> >  gentoo-powerpc-fix/
> >    ppc.diff
> >  debian-gcc4x-fix/
> >    patch-1
> >    patch-2
> This poses a very interesting question: Would you want to
> maintain your specific stuff in this repo? I know that Fedora people
> can not do this for tool-chain and administrative reasons.
> Our plan was to only put the merged patches in the repo (along
> with a oldpatches/debian, etc) and have everyone pull into their
> own repo from there.
I.e. being more upstream than repos. Now I understand, that seems
reasonable. Sorry, I didn't get the idea completely the first time.
Then I see even less problems - for each game we'll have repo
directory and a wiki page. Files layout may also be discussed -
will patch per file or all-in-one patch be better?

I also see an inconvenience in handling patches to patches in the
repo. Is importing whole upstream source a possibility (i.e. keeping
2 branches, one with vanilla source, one patched, and getting a
full patch with one command)? Actually only relevant files may be
imported (I.e. source and build scripts, but not docs and data).

> > Trivial merging (two or more similar patchsets, or just renaming
> > distro-specific patchset to common-something) may be just done by
> > whomever interested, more complex tasks (like where there are
> > different ways to fix a problem) should be discussed in the maillist.
> Yes. We should try to get a system into place with which a code
> review by members of at least two projects go over 'final' patches.
> We basically trust everyone, but there's no need to be uncautious.
Commit messages (with diffs included) from the repo may be mailed
to the list, so every commit is visible to others and can be easily
looked through. But it may spam a list pretty much.

> I know Miry is planning to start a test balloon with hex-a-hop soon.
> That is packaged for FreeBSD already, so you, Dmitry, might want
> to poke jamie at bishopston.net to see if there is any interest in this.
> Or the two of you agree on a different game to start playing with.
> Yes, pun intended :)
Will do, actually I'm the one who made amd64 fixes for FreeBSD port
of hex-a-hop.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru