[XviD-devel] [!!! DEVELOPERS MUST READ !!!] New development process

[Edouard Gomez]

Hello xvid developers...

A new  era began this evening.  The XviD development will  now be done
with the help of branches. This mail is splited in 4 parts :

 1 - New cvs dev rules
 2 - Small cvs commands set to work on dev branch
 3 - Is there a maintainer volunteer for stable tree ?
 4 - Probable restricted cvs write access.

//////////////////////////////////////////////////////////////////////////////

1st Part : new CVS RULES

The new cvs rules are :

1 - pre Branching tags are named as tag-branching-YYYYMMDD
    (YYYY is  a four digits year,  MM is a 2  digits month, DD  is a 2
     digits day)

2 - Development branches are named as follows :
    dev-api-version, version is a digit following this rule :
      + when branching a new API, "version" is just equal to the major
        API version (eg dev-api-3).
      + when  branching  a  new  minor  API  change, version  must  be
        MAJOR_MINOR (eg dev-api-3_1)

When  dev-api-version becomes  mature, then  we  merge dev-api-version
into CVS_HEAD.

Then do 1- and 2- again...

Developers must intorduce new  features and/or bugs in dev-api-version
branches. The CVS_HEAD  will be the bug fix  branch. Developers commit
*only* fixes  and cleanups to  CVS_HEAD, no new features,  neither big
code changes must be commited.

//////////////////////////////////////////////////////////////////////////////

2nd part : CVS mini RTFM

++ To work on CVS_HEAD (like usual case before) to commit bugfixes :

cvs -d:pserver:devname@cvs.xvid.org:/xvid co xvidcore

++ To work on development branches :

cvs -d:pserver:devname@cvs.xvid.org:/xvid co -R -r dev-api-version xvidcore


Once you have  one branch local copy, all commitments  are done to the
same  branch on  cvs. This  way, new  features will  never  polute the
stable tree...

Normal public  should not be aware  of dev branches, and  i would like
Nic, Koepi and all other who distribute binary forms of XviD, base one
their dlls  on stable tree. You  can provide dlls based  on dev trees,
but you should write in BIG BOLD font "development binary, do not send
unuseful bug  reports like : this  has poor quality...  this sux" (<--
well, here you choose the right words to explain dev tree is available
to have good bug reports that could allow developers to track bugs)

//////////////////////////////////////////////////////////////////////////////

3rd part : Is there a mainter volunteer.

I VOLUNTEERED TO BE THE  STABLE TREE MAINTAINER.  I WOULD LIKE SOMEONE
ELSE TO HELP ME MAINTAINING THE TREE.

We will be co maintainers of stable tree, this will mean in the very near future :
  - remove bframes and qpel and frame drop from CVS_HEAD
  - Add legal headers to *all*  files (copyrights will be solved in at
    a later time)
  - clean the rest of the files

And this means for the rest of the time :
  - track fixes in dev tree to include them in stable releases.
  - optimize code without making big changes
  - fix bugs reported by all "stable" users.

If someone thinks he is the guy to maintain a stable tree (== who does
not like  to use bleeding  edge features and  working on a  rock solid
code) then just answer this email...  i do not know how the maintainer
will be chosen yet.

//////////////////////////////////////////////////////////////////////////////

4th Part : Probable restricted cvs write access.

We  (christoph, pete?,  michael and  i) have  discussed of  a possible
restricted  write access  to CVS.  Patches can  be sent  to xvid-devel
until a patch@xvid.org is created.

/////////////////////////////////////////////////////////////////////////////

Ok that's  all boys (and girls?),  you can check the  dev branch right
now : dev-api-3

Have lot  of fun breaking  things in this  branch while i'm  trying to
make a rock solid and clean XviD core in CVS_HEAD ;-)

Regards.

PS  : Try  to  read the  CVS  manuals/info pages,  it's  full of  good
      examples and you would learn lot of things from them...

--
Edouard Gomez