[Xorg] next steps with the xorg tree

[Roland Mainz]

Egbert Eich wrote:
>  > Is there no way to automate this and get a cron job create the changelog
>  > ?
> 
> Not a cron job but some script that cvs triggers with a commit.
> I need to see how this can be done though. Until then I'd encourage
> everybody to use this changelog.

I am not sure whether this is a good idea. I can imagine that this may
bring the machine down if many people start to commit many things...

>  > Actually this leads to the next issue: What about setting-up a
>  > "commit"/"checkin"-policy that issues should be commited to the CVS in
>  > "one-issue per commit" mode and each change MUST have a matching
>  > bugzilla URL (in the commit message) where the change is described (e.g.
>  > similar like mozilla.org and many companies manage their tree) ? The
>  > advantage would be that CVSblame could be used to lookup the bugzilla
>  > bug and people could look there for additional information or drop
>  > comments there...
> 
> Yes, thank you. I've been advocating to have a commit policy for
> a long time.
> I would not encourage strict requirements such as:
> - MUST have a bugzilla entry
>   We need to see: maybe a trouble ticket system is the way to go.
>   On the other hand having problems finding anything in bugzilla
>   myself I don't see a point in having this for every commit.
>   Instead the log entry should be conclusive and point to the
>   ticket number if one exists.

I usually commit stuff like this:
% cvs commit -m 'Fix for
http://xprint.mozdev.org/bugs/show_bug.cgi?id=5336 - Build failure on
Solaris 2.8/SPARC'
% cvs commit -m 'Fix for
http://xprint.mozdev.org/bugs/show_bug.cgi?id=4787 - ft2pt1 font
download code may not download the first two glyphs in a (sub-)font
(refix for 16bit fonts/attachment 1498)'
etc.
that way a URL reference to the bug and has the bugzilla attachment
number (if one bug has multiple patches).

> - one issue per commit.
> When fixing little issues it may take longer to generate this entry
> than making the fix.

I know... it's just a matter of discipline (take a look at the Xprint
CVS, nearly EVERY commit was done that way - one commit per issue. The
only exception are the Xprint FAQ updates and the
DocBook-->HTML/manpage/txt updates) ... :)) ... sometimes anoying but it
has huge advantages when you have to hunt for errors in the code someone
wrote a few years ago... then such a policy will help a lot.
And it helps people who want to port exactly _one_ _single_ change to
their own tree. I always have to spend a lot of time dismanteling old
Xfree86 changes since they have comitted many changes in one step. And
that costs LOTS of time just to extract the change I want to port and
avoid pulling other unrelated changes with it. Therefore I beg here for
a policy which demands on one-issue-per-commit that future users of the
tree won't have to suffer... :)

> Also one issue per commit may not be feasable. From my experience I
> sometimes fix several small issues per day and only do one commit.

Take a look at mozilla.org and how they manage their tree (the policy
outlined above is just a stripped version of how they maintain their
tree) ...

> The general guidelines should be:
> - Put untested new stuff into your own branch.

Yup.

> - If you fix things and are not sure what you are doing *ASK*.

Agreed :)

> - Not every newbie should be allowed to throw things into the
>   CURRENT branch - unless they are either obvious or someone
>   has reviewed the stuff.

Agreed. BTW: It would be nice to upgrade the current bugzilla version to
the one mozilla.org is currently be using - that version can send review
requests via email around... :)

[snip]
>  > BTW: Is it possible to import the Xfree86 sources in a way that the
>  > "commit messages" in the Xfree86 tree are preserved ?
> 
> Unlikely. What will be preserved is the CHANGELOG.

That may cause problems when someone tried to hunt bugs and has to look
back into time when a certain line of code was changed (see
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=&cvsroot=/cvsroot)
for an example what I mean (and why I am think it's VERY important to
preserve the CVS commit messages) ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 2426 901568 FAX +49 2426 901569
 (;O/ \/ \O;)