On Jan 18, 2008, at 12:14 PM, Angela Byron wrote:
I'm +1 to its removal, but defer to dww since he knows a lot better than me (or probably most of us ;)) what would be involved here, and how much work it would actually cost/save.
I don't care. Certainly for phase 1 we can live without. I think everyone understands patches in the issue queue, and many of the benefits (including PIFT ("project issue file testing" -- the automated sending of .patch and .diff files to a simpletest server)) would still work without it. It doesn't let us do automated testing *all* of the security-related patches for a given release of core *at the same time*, to make sure they don't break each other in any interesting and unexpected ways. But, we've made it this far without such automated tests, we can live longer without them (though, sadly, the track record on the recent core security releases has been pretty bad in terms of QA, and we've had to rev "whoops, sorry we broke that" releases a lot more often than I think anyone would like). That said, if I wasn't spending my time defending my ideas on this list, I could probably whip up the CVS rsync code in a few hours. The code to dump a CVSROOT/passwd file based on the data in the cvs access tab is also a few hour job at most, that one's actually more like 1 hour. So, it's not like it would have to take weeks of work to get the per-project private CVS repos working. Regardless, I can't answer the "how much work would it actually save" question. It basically boils down to how likely is it that developers would use it, how much additional confusion/potential for mistakes would it introduce, and how helpful for QA would it be. If people won't use it, it's obviously not worth doing. -Derek (dww)