www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <nbe...@gmail.com>
Subject Re: Clarification on the release requirements
Date Thu, 30 Apr 2009 00:06:57 GMT
On Wed, Apr 29, 2009 at 6:57 PM, Jason van Zyl <jvanzyl@sonatype.com> wrote:
>
> On 29-Apr-09, 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.
>
> I never said anything about it being atomic.

I know, but I brought it up because we're talking about distributed
systems and guaranteed consistency. We need to guarantee consistency.
Rapid succession won't guarantee it and we don't have atomicity to
rely on.

>
> A planned release with myself as the release manager has never had someone
> else try to alter a tag while I was releasing it. It's not likely.
>
> It's about as likely as you pulling from your tag to create your source
> archive, and then someone changing your tag which has corrections that
> should be released but you missed it and didn't include it. It's not likely.
>
> What matters is the validation of what was pulled indeed works. Which is why
> the release plugin after pulling the tags does the build again to make sure
> all the tests pass before you attempt to make the actual release. This
> catches almost all mistakes but theoretically someone could make a behavior
> change that still passed tests not good enough which leaks something bad
> given a lengthly enough span between the two phases.
>
> The only way to absolutely guarantee what's tagged and what's used is with a
> system like GIT that employ hierarchical checksums. If I tag and take the
> checksum and store it. I can come back a month later and if the checksum at
> the top of the structure is the same the contents are guaranteed to be
> identical. So we could guarantee content identity, run the build like we
> always do with the release plugin and then you're certain. We actually take
> the algorithm out of JGIT and add it to the release plugin to check the
> checked out structure ... that would actually work well.

That's not the only way to guarantee it, the use of source archives
that are signed archives also works. This is possibly a way to
guarantee it using SCM systems.

>
>> When you can't rely on atomicity, then you
>> need verification in between, which is where the signed artifact comes
>
> If you want to consider your SCM unreliable then sure.

It's a distributed/networked system, you have to assume it will be unreliable.

>
>> in.
>>
>> -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
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
>  -- Thoreau
>
>
> ---------------------------------------------------------------------
> 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