[wd-isf] ChangeLog

[Benoit Grégoire]

On Monday 14 February 2005 08:13, Philippe April wrote:
> I'm developing a lot on the auth server and I don't ChangeLog everytime, I
> have to admit.
>
> One reason for this is because we run an always cutting edge CVS copy in
> prod.

I don't follow you, ChangeLogs are even MORE important as we run a prod server 
damn near CVS head.

> I'd like to bring (again) the urgency of having dev instances (with an 's,
> so people can develop in parallel). Either at people's place, or I don't
> mind hosting them.

That's a separate issue.  the reason there were uncommited Changes on the live 
server was because I was making urgent quick changes to the live server (CVS 
export for the wifi directories, which is quite hard to do without a dataset) 
that I didn't have time to finish.  As the code was not yet functionnal and 
unlikely to be worked on by someone else, I didn't commit it.

Then I received the updated translations right before last meeting (where we 
were to talk about it) and didn't have time to touch the code ever since 
(other emergencies, such as the damn orders).  Otherwise I would have 
commited the .po file only.  I DID hovever send an email that I put it on the 
live server.

> The reason for this is to not make tons of small commits to CVS (like I
> do right now). It makes CVS just an updated copy of what's going on,
> but we are never committing big changes.

A commit withoout ChangeLog is simply never justified.  I don't understand why 
you care if there are 10 commits a day, this is the reason CVS exists!  Every 
projects have commits such as "Fixed spelling in a bunch of files", and 
that's fine.  "Major changes to (subsystem), DETAILLED derscription not 
listing all the affected files" is also fine (assuming it's also copied in 
the log message off course.  Adding new files without a ChangeLog simply 
isn't.  

All commits must have a ChangeLog, usually with short description ans affected 
files, otherwise it's damn near impossible to know what someone else did, and 
WHY.

> I hate playing in production and risk fudging something up when I play
> with templates and all.

So do I.

> Also, I would love to start tagging releases of the auth server,
> although right now a lot of development and changes are going on.

It's just not worth it as long as we don't release.

> Once we agree it's cool, we cvs update to the release we want.
>
> Another benefit, once we tag releases and we want to make schema
> changes, we can put in some SQL files that will alter the tables to
> bring things up to date to the new release. Right now, it's not
> versionned so we can't really do that.

That will be very hard (but not impossible) to do.  If it's simply to add a 
field to a table, then it's easy.  If it moves data around or add new initial 
data you need to also write a PHP file to actually move the data around.  You 
then need two snapshots to test it, else you can pretty much destroy 
somebody's live server.  This will probably become a mandatory part of making 
a release, but as it's several hours of work, let's wait untill we have 
actual releases.
  
> So, Benoit, I'm sure you won't want to develop on my box at home because
> you have a server already, but still I offer you an account on my server
> at home for this. I would like to start this "new way" now because it's
> getting risky to play in prod. Just yesterday I wanted to work on the
> latest files from the auth server and found a couple of un-committed
> files sitting on the auth server.

Thank you, but I already DO have a development instance on another machine 
(DUH)!  I find disturbing that you tought that I did all major changes right 
on the live server, with people logged on...

I do make all my schema changes on the live server, but that's to ensure that 
the data is always safe (as the schema is auto-generated from the actual 
database).  I also, (like you I may add) sometimes do minor changes right on 
the live server, but only when I know it's safe to do so.

> That wouldn't normally be a problem, but what happens if I want to
> commit at home, then update the version in prod and stumble on merging
> problems because newer code existed..

There are ALWAYS merge problems with .po files (unless everyone uses the same 
tools, end even then).  That file should never have been left uncommited, was 
never meant to be left uncommited.  I explained above why it has.  As for 
conflicts in general, they are a part of life, and a very small price to pay 
for allowing several developers to work on a project at the same time.

-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://philippeapril.com/pipermail/wifidog/attachments/20050214/b7105aff/attachment.pgp