Re: Commit changelogs
mån 2006-08-07 klockan 13:04 +0200 skrev Guido Serassio: Yes, I also prefer a solution without any special markup, but this solution warrants that the commiter must know what is doing, and it's a not so big effort like the old 2.5 patch management :-) What about the following simple rule First paragraph must be 20 characers and 120. If it doesnt start with Bug then it must additionally be 40 characers long and it must be followed by a second paragraph further explaining the impact of the change. i.e. a title and a description is required, separated. and to further guide the committer there may be a template commit template message looking something like the following: Bug: Title: Description where the keywords is automatically transformed into the kind of text we have been using up to now.. [Bug #xxx: ]Title.. Description.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Commit changelogs
Hi Henrik, At 13.33 07/08/2006, Henrik Nordstrom wrote: mån 2006-08-07 klockan 13:04 +0200 skrev Guido Serassio: Yes, I also prefer a solution without any special markup, but this solution warrants that the commiter must know what is doing, and it's a not so big effort like the old 2.5 patch management :-) What about the following simple rule First paragraph must be 20 characers and 120. If it doesnt start with Bug then it must additionally be 40 characers long and it must be followed by a second paragraph further explaining the impact of the change. i.e. a title and a description is required, separated. This was my first idea, but the minimum title length could be a problem, just some changelog examples: Memory leak on pinned connections Documentation update Cosmetic linewrap layout fixes Forgot some small changes Preparing 2.6.STABLE2 Ran indent What about an optional tag allowing a minimum length override ? Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
Re: Commit changelogs
mån 2006-08-07 klockan 14:44 +0200 skrev Guido Serassio: What about an optional tag allowing a minimum length override ? If we go to the tagged/guided form there will most likely be no lower limits other than there must be a title and a following description. For now I thinkt I'll just ignore the issue, and instead remind everyone that it's a good idea to write same commit messages. For me it's good enough, and if all goes well the commit rate should continue to decline rapidly in 2.6 now. For Squid-3 it isn't even set in stone which version control tool should be used. The fight is currently between CVS (or maybe SVN to keep with the same philosophy but better engine) and Baz. With CVS we have a server enforcing rules on us, with baz it's less controlled with the benefit of being able to easily branch anywhere in any means desired without loosing track. monotone has already been disqualified, at least in it's current incarnation. It's main benefit compared to baz would be the multihead support which allows delayed conflict resolution allowing any developer to resolve the conflict and not only the last one to commit and seamless flow of information, but it fell badly in cross-branch merge support with no cherrypicking and failure to at all handle files added on two branches in a sane manner, not even providing sane diff capabilities to compare the two copies in such cases. Also the seamless flow of information feels a bit scary for the uninvited. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Commit changelogs
Hi Henrik, At 16.08 07/08/2006, Henrik Nordstrom wrote: mån 2006-08-07 klockan 14:44 +0200 skrev Guido Serassio: What about an optional tag allowing a minimum length override ? If we go to the tagged/guided form there will most likely be no lower limits other than there must be a title and a following description. For now I thinkt I'll just ignore the issue, and instead remind everyone that it's a good idea to write same commit messages. For me it's good enough, and if all goes well the commit rate should continue to decline rapidly in 2.6 now. I agree, but I like to write a little commit guide with some of the topics of this thread: - Bug commit format - Standalone patch commit format But I will do it after the next two weeks: tomorrow will start a very busy period for me ... :-( For Squid-3 it isn't even set in stone which version control tool should be used. The fight is currently between CVS (or maybe SVN to keep with the same philosophy but better engine) and Baz. With CVS we have a server enforcing rules on us, with baz it's less controlled with the benefit of being able to easily branch anywhere in any means desired without loosing track. monotone has already been disqualified, at least in it's current incarnation. It's main benefit compared to baz would be the multihead support which allows delayed conflict resolution allowing any developer to resolve the conflict and not only the last one to commit and seamless flow of information, but it fell badly in cross-branch merge support with no cherrypicking and failure to at all handle files added on two branches in a sane manner, not even providing sane diff capabilities to compare the two copies in such cases. Also the seamless flow of information feels a bit scary for the uninvited. I don't have any particular preference: the only thing that I need is the availability of a Windows port :-) Regards Guido - Guido Serassio Acme Consulting S.r.l. - Microsoft Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: [EMAIL PROTECTED] WWW: http://www.acmeconsulting.it/
