On 3/19/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
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.
sure. and the SVN repo has protections that releases do not: commits
are sent to a mailing list for oversight and archival. they are kept
in a central place that is easy to control and not distributed
widely. the consequences for problems are small and easily remedied.
the actual bits that are distributed as an officially endorsed release
do not have the luxury of diffs sent to the development lists, nor are
they easily controlled from a central location. the releases are
extensively mirrored by servers all over the place. releases are nigh
impossible to recall. thus, with the broader audience, the
consequences for problems are greatly magnified and are not easily
remedied.
i can understand complaints about the process, but let's not pretend
that releases do not need an extra measure of protection that the
repositories do not.
that said, i would love to see some more automation of
signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe
Henk Penning does have some automated signature checking set up, but
that's all i know of, and it only happens after the release is out.
anyone frustrated with the process is quite welcome to step up and
hack up something to ease the frustration. :)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
