I think we have to remember that the ASF provides an important legal umbrella here. By setting policies which we follow (which of course can be debated), it prevents us from being sued if an SCO-type situation develops. This would be a low-probability, but extremely catastrophic event, especially since developers could be sued directly if they were operating independently. The PMC plays an important role in shielding individual developers from liability by approving releases according to defined policies.
WILL On 3/19/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Sure, of course it's ok for the ASF to dictate policies - I just hope it's ok for me to question them / point out their flaws. So the real problem as far as I can tell is making sure a release is legitimately licensed. There are other things like software quality, but I guess it's assumed (by me at least) that we're all trying to release as high a caliber of software as we are able given our resources / time. Somehow this still doesn't feel like a legitimate problem, or at least it is not consistent with the rest of our daily practices. ..Like committing a change to subversion. As far as I can tell there is no legal difference between subversion repositories and released software - is there? Isn't the end goal to prevent any naughty code coming out of apache period? Non conforming code sitting in subversion would appear to be just as guilty as anything else...So given your current logic shouldn't we all be required to have a PMC vote for each commit made into the repo? It just feels like we're being treated a little bit like incompetents in some way. Like maybe someone accidentally made a bad release once or twice and so we must all suffer the same solution that they have. Ehh...Obviously I'm alone in my opinion so I'll shut up now, just wanted to make sure I got my two cents in. On 3/19/07, J Aaron Farr <[EMAIL PROTECTED]> wrote: > "Jesse Kuhnert" <[EMAIL PROTECTED]> writes: > > > You have to be kidding me.. > > > > The only problem I see is that people are all caught up in policies / > > processes but I've yet to hear what the actual root "problem" is. I'm > > sure it's intended to somehow prevent something nasty that has > > happened in the past but these policies don't have any logic that I'm > > able to follow. Why does the ASF need to dictate how we vote on > > releases? > > > > Maybe I'm just having a bad morning, but for some reason this really > > rubs me the wrong way and feels extremely inefficient. > > The problem is that Vote-Then-Release leaves opportunities for the > small details to get missed and you end up with a sloppy release. > Examples include non-signed distributables, incomplete legal notices, > missing or incorrect hashes. The worst is someone slipping in some > malicious code in between the time the vote is cast and the release is > made. > > When a PMC votes on a release they should be approving the exact bits > that hit the mirrors. That vote binds the ASF to be _legally_ > responsible. The only way to have sufficient and appropriate > oversight is to give the PMC a chance to check that these final steps > of a release have been properly handled. Otherwise the PMC risks > releasing a half baked product. > > It is completely appropriate for the ASF to set guidelines on release > procedures. > > -- > jaaron (who is not on the Jakarta PMC) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Forio Business Simulations Will Glass-Husain 415 440-7500x89 [EMAIL PROTECTED] www.forio.com
