www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Clarification on the release requirements
Date Thu, 30 Apr 2009 00:32:50 GMT

On Apr 29, 2009, at 4:34 PM, Nathan Beyer wrote:

> On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl  
> <jvanzyl@sonatype.com> wrote:
>>
>> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>>
>>>>> Anything that (essentially) matches the contents of svn and can be
>>>>> built to produce the other release artifacts is IMHO fine as a  
>>>>> source
>>>>> release.
>>>>>
>>>>
>>>> I agree and this is generally standard practice by SCM teams. It's
>>>> predicated on immutable tagging and the SCM being reliable. I can  
>>>> see why
>>>> Roy wants it done from the source archive here because we've  
>>>> never setup
>>>> CVS
>>>> or SVN to follow SCM best practices and it's not uncommon for SVN  
>>>> to be
>>>> out
>>>> for unacceptable periods of time. So I can see where Roy's  
>>>> methodology
>>>> came
>>>> from. I've seen lots of diddled tags (though this is pretty much
>>>> impossible
>>>> with mvn -B release:prepare release:perform) and SVN has been  
>>>> unavailable
>>>> more often then I would like to admit to the outside world.
>>>
>>> It's not only a problem of SVN not being available : there is no way
>>> you can guarantee that SVN hasn't been compromized if you base your
>>> build on a tag.
>>
>> I don't think this argument carries any weight because where did  
>> you get
>> your source archive from? A tag most likely. So if you wake up in the
>> morning and pull a tag to create a source archive and then  
>> release,  or
>> alternatively do "mvn -B release:prepare release:perform" there's no
>> difference. The freak chance a second after you prepare the SCM  
>> goes down is
>> slim. If we wait a length of time between each step then yes it could
>> happen.
>>
>>> OTOS, a source package can be signed, thus can't be
>>> compromized without being detected.
>>>
>>
>> That's not related to making the source archive and it's integrity  
>> if you do
>> both operations in rapid succession.
>
> I believe this is flawed though - 'rapid succession' is not a
> guarantee of atomicity. When you can't rely on atomicity, then you
> need verification in between, which is where the signed artifact comes
> in.
>

Everyone's saying "source artifact" but I don't get it.  I think we  
want a known set of "source" with known provenance.  The only source  
of known provenance I'm aware of is svn.  IIUC with svn the contents  
of a path into the repo + a revision number is immutable.  Seems to me  
like if we're serious about knowing what we're releasing and where it  
came from we have to use the svn location as the base of the vote.   
I'd hope that artifacts such as some kind of source distro and  
optionally binary artifacts that are produced by a documented process  
from the svn location would be included in the vote but leaving out  
the only thing that has traceability seems nuts to me.

I see Jason VanZyl says git provides a similar or perhaps better  
capabiity using checksums.  So git would also provide something known  
to base a vote on.

To beat a dead horse over its head using a mixed metaphor, there's no  
way to know what's in a "source archive" some RM comes up with unless  
you know where it came from and how it got into the "source archive".

david jencks

> -Nathan
>
>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel L├ęcharny
>>> www.iktek.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>>  -- Jakob Burckhardt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message