----- Original Message ----- From: "Simon Kitching" <[EMAIL PROTECTED]> Sent: Thursday, May 26, 2005 3:16 AM
> Hi Niall, > > In general the patches we are applying are likely to be small; they are > bugfixes for bugzilla reports not new features. > > So I wouldn't have thought that posting patches separately would be > useful. After all, every subversion commit automatically generates a > patch file that gets emailed to the list anyway. If someone queries the > patch they see in a commit mail then we can talk about it and > potentially back it out again. > > The commit-first approach would seem to save a large amount of time over > posting a patch then waiting a few days to see if anyone comments on it. > > Obviously if the developer has any concerns about the patch they are > applying then posting first is a good idea. Yes you're right its not always necessary - its a judgement call. If a change affects "backwards compatibility", it would be my preference to see it discussed first. > If you have filtering set up for beanutils mails, then I would recommend > that you make sure that filter also picks up commit emails containing > "commons/proper/beanutils" in the subject, so that you don't miss any > commit emails. I already see the beanutils commits. > I would expect that when we roll a release candidate for beanutils we > would run the struts unit tests using that beanutils RC jar to see if > any problems occur. And likewise for digester. And for any other > significant beanutils-using projects if someone tells me about them. > Hopefully we will get a struts developer or two to join the beanutils > maintenance (I've posted on [email protected]), in which case that > person could run beanutils HEAD during their struts development to pick > up any problems. I am also a struts committer. > But I'm open to arguments on this... > > Regards, > > Simon Niall P.S. It is good to see you and James prepared to work on beanutils :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
