On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert 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. >
Jesse, You are certainly not alone. I have always been of an option that the content of the SVN repository is what truly represents the source code of ASF software, with packaged releases merely being versioned snapshots officially endorsed by the project committers and the respective PMC and recommended for use by the end users. I am not a legal expect by any stretch of imagination but I think ASF may be equally liable for any given revision in its official SVN repository as for its packaged releases. In Commons HttpClient / HttpComponents land we historically voted on SVN revisions and published release packages based on a lazy consensus if no one raised complaints about the content of the release packages. Oleg > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
