fixing for both 3.0 and 3.1 is the same amount of work as just fixing
it for 3.1...
2.0... I hope we won't be having any more releases of that (and that's
Ant based!!)
Andrus
On Aug 16, 2010, at 10:14 PM, Mike Kienenberger wrote:
> So what do we need to do?
>
> Fix it for this point release? Make an exception for old point
> releases, and only fix it for 3.1?
>
> Fix our latest point releases for each currently maintained branch?
>
> My opinion is that we should fix all of the latest point releases, but
> I personally won't be able to do the work -- as I mentioned a couple
> months back, I'm in the middle of a go-live deployment of a three-year
> project for the next month or two, and I'm maven-ignorant.
>
> Second best would be to fix the 3.x branches.
>
> Third best would be to fix only 3.1.
>
> On Mon, Aug 16, 2010 at 3:04 PM, Andrus Adamchik <andru..bjectstyle.org
> > wrote:
>> So again, I am convinced by your argument and the history trail of
>> reasoning
>> behind it. Just feels that the solution that we might use (and that
>> others
>> are using) and the desired ideal are pretty far apart from each
>> other.
>>
>> Andrus
>>
>>
>> On Aug 16, 2010, at 9:43 PM, Andrus Adamchik wrote:
>>
>>> Yeah I vaguely remember this discussion -
>>> http://markmail.org/thread/njray5dbazwcdcts and I have to agree
>>> with Roy's
>>> logic, which convinces me better than a mention of "policy" :-)
>>>
>>> Ok, so say we have a Maven build system that exports buildable
>>> source with
>>> poms... which, considering the reliance on a public Maven repo for
>>> dependencies may not be that "buildable" 6 months from now :-/ Even
>>> open-source Apache-licensed (but not ASF-managed) packages may
>>> disappear.
>>> How far can we go with that? (a good experiment would be to take a
>>> year old
>>> existing ASF package and trying to build it, say Geronimo or
>>> something of
>>> that level of complexity..)
>>>
>>> Andrus
>>>
>>>
>>> On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
>>>>
>>>> It's one thing to state that it may not be a requirement to provide
>>>> buildable source, but it's quite a stretch to claim that we do
>>>> provide
>>>> buildable source immediately after a message stating "It is
>>>> practically impossible to do that as the build system is ... well,
>>>> complex" Taken to extremes, you could say that a jar file full of
>>>> classes is buildable source, since, with the right tools, you can
>>>> decompile the class files back to java code.
>>>>
>>>> But if you want to say that we're meeting the source build
>>>> requirement, consider this. It would mean that everyone voting +1
>>>> on a
>>>> release has somehow thrown a home-grown build-system on top of the
>>>> source release and successfully built it. Because that's the only
>>>> way an evaluator can be sure that the release has met the condition
>>>> and the release manager hasn't accidentally left out some required
>>>> piece of source. We wouldn't say that we know that the release
>>>> has a
>>>> valid checksum without checking it ourselves or that the release
>>>> has a
>>>> valid signature without checking it ourselves. Same goes for
>>>> building it.
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org
>>>> >
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided
>>>>>> they have
>>>>>> access to the appropriate platform and tools. The source
>>>>>> package must
>>>>>> be cryptographically signed by the Release Manager with a
>>>>>> detached
>>>>>> signature; and that package together with its signature must be
>>>>>> tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with
>>>>>> the
>>>>>> detached signature file (at the Release Manager's discretion)
>>>>>> prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a
>>>>> working
>>>>> pom.xml or build.xml, just the source that is matching the
>>>>> binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile,
>>>>> but a Java
>>>>> developer will be able to build the source regardless (e.g. by
>>>>> writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org
>>>> >
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided
>>>>>> they have
>>>>>> access to the appropriate platform and tools. The source
>>>>>> package must
>>>>>> be cryptographically signed by the Release Manager with a
>>>>>> detached
>>>>>> signature; and that package together with its signature must be
>>>>>> tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with
>>>>>> the
>>>>>> detached signature file (at the Release Manager's discretion)
>>>>>> prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a
>>>>> working
>>>>> pom.xml or build.xml, just the source that is matching the
>>>>> binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile,
>>>>> but a Java
>>>>> developer will be able to build the source regardless (e.g. by
>>>>> writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 19:19:12 UTC