[Games] Status update
richih.mailinglist at gmail.com
Fri Nov 28 09:54:07 PST 2008
On Fri, Nov 28, 2008 at 16:11, Dmitry Marakasov <amdmi3 at amdmi3.ru> wrote:
> Seems like both have mailing lists.
> On http://darwinports.com/ though, maillists link seems broken
Do you want to tell them about this list? Feel free to steal my text,
for that. If not, I will do it over the weekend.
> 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?
Yah, that is the beauty of it. As we are basically secondary
upstream, we get rid of a lot of problems. People are welcome
to maintain the rest of whatever they need in there as well, though.
It should be one patch per feature. No matter if it spans one or
a hundred files. Patches which accumulate several features should
be split, if possible.
The layout I have in mind is along those lines. It assumes that
two projects use the repo in question to manage their specific
stuff. Note that those are not directories but git branches (which
is where git is really really nice...)
\- upstream 1.0
|\- patchset for 1.0
||\- distribution foo
|||- distribution bar
|- upstream 1.95
\-patchset for 1.95
> 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).
If you look at the above, you see that you can get pristine and
modified from the same repo.
> 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.
The fdo people asked that we start with only one list. As the
infrastructure within other projects does not match with Debian's,
some assumptions are off. Long story short, I requested a
> Will do, actually I'm the one who made amd64 fixes for FreeBSD port
> of hex-a-hop.
More information about the Games