>Well, I think the reduction in the use of "externals" in the svn >repository may help a little; it's easier to create branches now. > >But the major work is still a matter of ensuring that patches for bugs >are applied to both a branch and the trunk, or of someone trawling >through all patches applied to trunk and "back-porting" them to a bugfix >branch. That's not really related to the build system at all.
Are there policies for committers on this? There is a subtle difference between committing the fix and closing the issue, vs. creating a patch, attaching it to the issue, committing the change and then closing the issue. The second makes it easier for "back-porting", which is something both MyFaces or an external organization may want to do. >And unfortunately there's just so much exciting work to be done in this >young project on the trunk that it's hard to work up enthusiasm for this >kind of maintenance work. > >One nice think about the way JSF is designed, though, is that it's >always possible to override the implementation of standard components >and renderers. People can therefore fix individual components and >renderers if necessary without having to roll their own myfaces-api.jar >or myfaces-impl.jar. And components/renderers is where most of the bugs are. I agree. And there is a decent argument that too much policy and the associated costs might actually be a bad thing for a young project. Kind of like a young person ;)
