Re: Jenkins Builds

[Peter Ansell <an...@gmail.com>]

Hi Stian,

Maven Central now has HTTPS available, and Maven will use it by
default if you are using 3.2.3 or later:

http://central.sonatype.org/pages/consumers.html#apache-maven

That was the main reason for me to update to 3.2.3.

Cheers,

Peter

On 1 April 2015 at 02:58, Stian Soiland-Reyes <st...@apache.org> wrote:
> (RANT below! :) )
>
> I would love to see some tool for actually somewhat verifying that
> some bytecode release is possible to create from a given source
> release, and specially that there are no "extra bits" in it.
>
> If Apache binaries were automatically produced through a properly
> sandboxed, INFRA-managed machine (not as widely write-accessible as
> the current Jenkins), then that would also make a trustworthy system.
>
>
> If I have time and it is managable - I do at least an unzip of the
> deployed JARs and see that the file list compare with what I find in
> the compiled JAR. It is not secure in the sense that the binary
> bytecode could theoretically be doing something widely different from
> the source, but it could uncover say that the deployment used some
> local files not being checked in or similar.
>
>
> The source code is what matters -- to be secure you should compile
> from signature-verified source.
>
> Compiling *everything* from source is usually reserved to a couple of
> Debian enthusiasts and security-aware companies. Most Java developers
> will happily pull the binaries from Maven Central and rely just Maven
> checking the sha1 hashes (pulled from the same place over an
> unencrypted line).
>
>
>
> On 30 March 2015 at 11:24, Andy Seaborne <an...@apache.org> wrote:
>> On 29/03/15 23:57, Peter Ansell wrote:
>>>
>>> On 30 March 2015 at 06:10, John D. Ament <jo...@apache.org> wrote:
>>>>
>>>> On Sat, Mar 28, 2015 at 9:34 PM Peter Ansell <an...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 29 March 2015 at 11:57, John D. Ament <jo...@apache.org> wrote:
>>>>>>
>>>>>> Great question/comment! I always look forward to this part with new
>>>>>> podlings.
>>>>>>
>>>>>> On Sat, Mar 28, 2015 at 5:32 PM Peter Ansell <an...@gmail.com>
>>>>>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> That is fine with me.
>>>>>>>
>>>>>>> I am not overly fascinated by internal Apache infrastructure though so
>>>>>>> I would like to keep the .travis.yml file and the references to
>>>>>>> coveralls if possible as there is nothing broken with that system
>>>>>>> right now for CI and code coverage.
>>>>>>>
>>>>>>
>>>>>> It's weird that you feel this way (from my point of view).  Part of why
>>>>>> projects seek out the ASF is to leverage the infrastructure in place
>>>>>
>>>>> that's
>>>>>>
>>>>>> provided.  It's generally expected that the in house services will be
>>>>>> leveraged.
>>>>>>
>>>>>> http://www.apache.org/dev/services.html
>>>>>
>>>>>
>>>>> That perspective is very reduced these days by the free set of
>>>>> services that non-Apache projects generally rely on these days.
>>>>>
>>>>> Ie, a project can (and virtually all of my other projects that I am
>>>>> active with do so) run quite comfortably just with free (for open
>>>>> source code) providers:
>>>>>
>>>>> * GitHub or BitBucket for code hosting, wiki
>>>>> * GitHub for HTTP hosting and possibly issue tracking
>>>>> * Free Jira issue tracking license and hosting on Atlassian
>>>>> Cloud/OnDemand for OSS projects
>>>>> * TravisCI for continuous integration
>>>>> * Sonatype OSS Nexus repositories for snapshots and releases
>>>>> * Coveralls for code coverage
>>>>> * Google Groups for mailing lists
>>>>>
>>>>> In reality, the main reasoning for going to Apache is probably solely
>>>>> the brand these days, which overcomes the administrative overhead in
>>>>> the case of mature projects, or in our case, fairly short-lived
>>>>> projects (in terms of active development, we want to maintain a
>>>>> consistent core after a short term of stabilisation).
>>>>>
>>>>
>>>> I think this is the most troubling part of your post from my point of
>>>> view.  One of the things we need to be extremely careful about in the
>>>> incubation process isn't the fact that people are consumed with the
>>>> Apache
>>>> brand.  If the goals here are simply to get the name Apache put in front
>>>> of
>>>> the project, it's probably not going to grow that well.
>>>
>>>
>>> We don't expect a community to grow around the code itself, which was
>>> part of the reason for wanting it to be located within the broader
>>> Commons community in preference to a TLP. The reasoning is that there
>>> will be minimal changes to the APIs which make up the code, once it is
>>> stabilised, by design. Other than the pure Java interfaces which make
>>> up the API, we only have a single implementation that we will be
>>> developing against it. The only reasoning for having the simple
>>> implementation is to check the contract tests against a system that
>>> has no dependencies and is produced for the sole purpose of being a
>>> test harness. Given its status as a test harness, it doesn't need to
>>> be optimised, but it does need to fulfill the contracts, so if the
>>> contracts change, the test harness will need to reflect the change.
>>> Once the contracts are finalised, the simple implementation will be
>>> basically as static as the APIs.
>>>
>>> Part of the reasoning for starting out on GitHub was to attract a
>>> broad initial discussion, which, before we had a dedicated mailing
>>> list here, wasn't as simple as GitHub Issues and PRs for collaboration
>>> and quick commenting on the overall design. Since everyone has GitHub
>>> accounts, but not everyone wanted to subscribe to the deluge of emails
>>> going through the commons dev mailing list, it was the logical
>>> solution for the initial discussion. In addition, we had two
>>> approaches to the commons community last year but both seemed to fail
>>> during negotiation on the point that we required a dedicated mailing
>>> list inside of the Commons TLP, which is why we ended up here in the
>>> Incubator, essentially.
>>>
>>> I am personally ambivalent to whether this project is hosted within
>>> Apache, to gain the brand recognition, or whether it exists on GitHub
>>> as an independent project there, but the other main contributors
>>> heavily favour Apache and are fine with handling the administrative
>>> overhead that comes with that choice.
>>>
>>>> While it is true there are many services out there to leverage, we're
>>>> expected to use Apache services.  That doesn't mean solely Apache
>>>> services.  You can use Travis, Coveralls, Cloudbees, GitHub wiki, etc all
>>>> you want.  One limitation we do have is that you can't download binaries
>>>> from those sites that don't point to an Apache mirror'd location.
>>>
>>>
>>> That sounds fine, although I thought that Apache didn't have any
>>> control measures around binaries, with all releases only formally
>>> containing the source, with the binaries incidental? We will be using
>>> Maven Central as the main point of access for downloads, so that
>>> should be fine, given that every other Apache Java project also does
>>> that.
>>>
>>> Cheers,
>>>
>>> Peter
>>>
>>
>> For me personally, I see the move to Apache as giving the project long term
>> (e.g. 10 year) stability separate from github (a commercial company that
>> might change at any time (unlikely, but then FoundationDB was a big
>> surprise), and separate from specific people.
>>
>> Any long term OS project needs to have a governance structure.  Many have
>> their own foundations; that's a big overhead for small(er) projects. ASF
>> provides assurance that the IP is setup correctly.  IP, and legal issues
>> generally, seem a burden at times but if done right initially then
>> everything runs smoothly.  Unlike code, going back and trying to fix an
>> early problem is much harder in legal.
>>
>> I think using all the tools around to improve the output of this activity is
>> good.  ASF infrastructure and process first and foremost insures the
>> integrity of releases (source and binary).  The development assist is very
>> useful as well.  As a small activity, many different ways of doing that work
>> for us.
>>
>> Branding the technology is, for me, not a significant part of the move.
>>
>>> Apache didn't have any
>>> control measures around binaries
>>
>> A community can define what it agrees over and above the minimum at Apache
>> and Java makes it somewhat different to the C world.  Any binaries in a
>> release process must correspond to the source which is what one would expect
>> of any OS project. Publishing to maven is part of the release process for
>> Java projects.
>>
>> (I also find some of the language around releases vs snapshots too extreme
>> as well.  It seems to reinforce an artificial barrier between user@ and dev@
>> for the Java world which is not where it's at.)
>>
>>         Andy
>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718