Difference between revisions of "AlliedModders Planning"

From AlliedModders Wiki
Jump to: navigation, search
m
m
Line 99: Line 99:
 
We really, really still need a CMS to make this packaging, mirroring, etc business much more streamlined.  But this phase is so far in the future I expect other phases to creep in before it.  This is more a mind dump than anything, but here goes --
 
We really, really still need a CMS to make this packaging, mirroring, etc business much more streamlined.  But this phase is so far in the future I expect other phases to creep in before it.  This is more a mind dump than anything, but here goes --
  
*Moving from flyspray to bugzilla.  After using bugzilla, I'm convinced that its massive feature set far outweights the few permissions issues we ran into.  flyspray is severely lacking, and even though bugzilla isn't the nicest looking tool, it's templated and professionally done.  It has little things that really count, like..
+
*<strike>Moving from flyspray to bugzilla.  After using bugzilla, I'm convinced that its massive feature set far outweights the few permissions issues we ran into.  flyspray is severely lacking, and even though bugzilla isn't the nicest looking tool, it's templated and professionally done.  It has little things that really count, like..</strike>
**The input system isn't broken and convoluted like Flyspray's embedded dokuwiki (which seems to be less a product than a bunch of bugs someone coded)
+
**<strike>The input system isn't broken and convoluted like Flyspray's embedded dokuwiki (which seems to be less a product than a bunch of bugs someone coded)</strike>
**A much, MUCH better attachment system that allows for attachment reviews
+
**<strike>A much, MUCH better attachment system that allows for attachment reviews
**More focused on triaging and patch management than flyspray, which is simply a list of tasks with some basic statistics
+
**More focused on triaging and patch management than flyspray, which is simply a list of tasks with some basic statistics</strike>
 
*Moving from MediaWiki, which (I view) as a very, very outdated piece of software.  From version 1.5 to 1.10 I have noticed no real usability or feature set changes, and the installation/upgrade process is always very buggy for us.  Its administration and permissions model is laughably limited.  A possible target for this is DekiWiki which Mozilla is supposedly converting to.  It's open source and it's actually a CMS, which (perhaps) could kill two birds with one stone.
 
*Moving from MediaWiki, which (I view) as a very, very outdated piece of software.  From version 1.5 to 1.10 I have noticed no real usability or feature set changes, and the installation/upgrade process is always very buggy for us.  Its administration and permissions model is laughably limited.  A possible target for this is DekiWiki which Mozilla is supposedly converting to.  It's open source and it's actually a CMS, which (perhaps) could kill two birds with one stone.

Revision as of 23:00, 14 September 2008


This is sort of a major push for AlliedModders to be a bit more streamlined. We're encountering growth problems, especially as our personnel has dwindled quite low recently. This document discusses some changes I'm proposing. Anyone is free to discuss this on the forums or add comments into this document.

Everything related to source code management in this document refers to Metamod:Source and SourceMod. AMX Mod X is considered "mature" and is no longer maintained except for critical or high priority bugs. If and when we do a move past Subversion, it is unlikely AMX Mod X will follow.

The Problems

Short Term

  • We're finding it hard to manage multiple projects in a unified way.
  • There are site disparities, Metamod:Source and SourceMod and AMX Mod X each have entirely different backends.
  • Similarly, each site has a different version of the mirror system script.
  • Subversion doesn't cut it -- Mercurial might handle things better. Subversion basically has no branching or tagging support, and it has no real branch merging capabilities. This is a real problem for SourceMod which has pretty active development.
  • The packaging system is disorganized and fundamentally broken. It's inconsistent, inaccurate, and takes up 1.7GB of wasted space and growing.

Long Term

  • AlliedModders has plans past SourceMod. We need to be able to grow our project base without adding exponential amounts of work.
  • We still don't have a main site
  • MediaWiki still has authentication problems since its handling of usernames is broken
  • Flyspray is buggy, definitely non-production, and doesn't get maintained frequently
  • It's impossible to maintain the AMXX/SM/MM:S sites right now


Mercurial

Subversion doesn't let us branch nicely or create user-specific branches without forever mucking up the central repository. It's difficult to do merges.

An excellent tutorial for how Mercurial works is here.


Phases

Phase 0

DONE: We've eliminated build numbers and are back on the x.y.z system. SVN builds have "-svn" on them. We'll branch and remove those for releases. version.rc still has the fourth number so we can use fetchdlls and debug easily.

  • Apply new versioning scheme, whatever it may be.

Phase 1

DONE: We're now on a new box.

Move from Sente to Iroh so we can get away from ThePlanet and clean up/optimize some infrastructure. This is documented at Iroh Migration.

Phase 2

Expected date: Mid-July

  • Redo automation so the "packaging" versus "sending upstream" processes are fundamentally separate.
  • Redo "sending upstream" process so it simply sends over FTP.
  • Use an SSH tunnel to notify of new packages, so we don't have to do something idiotic like mirrors.pl for the mirror system, or using post-commit scripts on the Packages repository.
  • Redo the package system so only 30 days worth of builds are available.
  • Write a script to help users diff between packages?
  • Remove the Packages repository entirely (transitioning AMX Mod X to this will be trivial).
  • Update symbol server to include binaries and maybe even sourcecode? Removes the need for fetchdll's.

Phase 3

Expected date: End of 2009

  • Transition C# build tool to vs2k8 project that targets .NET Framework 2.0.
  • Transition SourceMod and Metamod:Source to vs2k8.

Phase 4

DONE: Two months late -- symbol store is no longer in SVN.

  • Move the pdbstore to be centralized client-side. This can be accomplished by making a more advanced symstore wrapper that will remove anything older than 30 days, and then (in a similar SSH tunnel method as above), rsync all changes upstream to the webserver. The exact mechanism is still up in the air, but rsync would probably suffice (as long as we can stomach cygwin).
  • Remove the Symbols repository.
  • Rewrite fetchdlls to support the new layout.

Phase 5

DONE!

  • Add hg.alliedmods.net pointing to our "repository roots," which will be per-project. For example, hg.alliedmods.net/sourcemod.
  • From there, import trunk as "sourcemod."
  • Branch every major release off as separate repositories, from the appropriate revisions.
  • Tag minor releases.
  • Update all links we can find on the site and in the docs.

Phase 6

(Assuming Phase 3, No real date in mind, before 2009)

  • Add /metamodsource, import trunk and branches.
  • Branch every major release off as separate repositories, from the appropriate revisions.
  • Tag minor releases.
  • Update all links we can find on the site and in the docs.
  • Create new repositories for the hl2sdk stuff. This way, the AlliedModders root organization will look like:
    • hl2sdk
      • hl2sdk
      • hl2sdk-ob
    • metamodsource
      • metamodsource
      • metamodsource-1.0
      • metamodsource-1.1
      • metamodsource-1.2
      • metamodsource-1.3
      • metamodsource-1.4
      • metamodsource-1.6
    • sourcemod
      • sourcemod
      • sourcemod-1.0

Phase 7

Expected date: End of 2008

We really, really still need a CMS to make this packaging, mirroring, etc business much more streamlined. But this phase is so far in the future I expect other phases to creep in before it. This is more a mind dump than anything, but here goes --

  • Moving from flyspray to bugzilla. After using bugzilla, I'm convinced that its massive feature set far outweights the few permissions issues we ran into. flyspray is severely lacking, and even though bugzilla isn't the nicest looking tool, it's templated and professionally done. It has little things that really count, like..
    • The input system isn't broken and convoluted like Flyspray's embedded dokuwiki (which seems to be less a product than a bunch of bugs someone coded)
    • A much, MUCH better attachment system that allows for attachment reviews
    • More focused on triaging and patch management than flyspray, which is simply a list of tasks with some basic statistics
  • Moving from MediaWiki, which (I view) as a very, very outdated piece of software. From version 1.5 to 1.10 I have noticed no real usability or feature set changes, and the installation/upgrade process is always very buggy for us. Its administration and permissions model is laughably limited. A possible target for this is DekiWiki which Mozilla is supposedly converting to. It's open source and it's actually a CMS, which (perhaps) could kill two birds with one stone.