Re: [buckminster-dev] IP-issues and hosting

[Carlos Sanchez <carlos.sanchez@xxxxxxxxxxx>]

I thought I'd write down the discussions we had.

I agree that the IP process is slow and tedious, and we are willing to
help with any information needed to go through it.

In the long term I think the place for the Maven provider is here at
Buckminster, it makes more sense and having it at Apache would have
other problems too as giving commit rights is not easy either.

I'm still considering whether or not it would be good to have it hosted
elsewhere while the IP process is not finished, there were some concerns
on the past about doing this so I'm still gathering some info.

But definitely I think it's a pain we'll have to go through and
hopefully will be mitigated after this first import, and also because
other projects will benefit from having these libraries available and
will likely help getting new versions approved.


Thomas Hallgren wrote:
> Hi,
> Eclipse.org has fairly stringent policies about what can be published.
> Everything has to pass through their IP-review process. During the work
> incorporating the native Maven binaries this has become a very apparent
> problem.
> 
> Problem 1.
> We think that people working on the Maven code-base are best suited to
> author and maintain the Buckminster Maven plug-in but since they are not
> committers, everything they do must be submitted in the forms of patches
> to bugzillas. Any such patch that exceeds 250 lines of code must go
> through an IP-review.
> 
> Problem 2.
> Everything that the new Maven bundle will depend on (transitively) must
> also be IP approved. That means every single line of source that leads
> up to the Maven binaries must be scanned. Eclipsed.org will only scan
> proper releases. Understandable since scanning snapshots would make an
> already heavy workload overwhelming.
> 
> Problem 3.
> Open source software relies heavily on the fact that a large user
> community will test beta-software. Given the problems 1 and 2, it will
> be impossible for us to publish something that doesn't contain proper
> releases of third-party binaries at Eclipse.org and the time between
> when a user reports a bug and we can publish a new version of the
> feature will be very long (two weeks or more). So we get a catch-22
> situation.
> 
> A possible solution?
> I think I might have a solution for this and I want your opinion. Here's
> what I think we could do:
> 
> 1. Move the code-base for a bundle such as org.eclipse.buckminster.maven
> to a host outside of Eclipse.org. Ideally to the same repository where
> the code that it's dependent on is hosted.
> 
> 2. Publish a feature that contains this bundle and its dependencies on
> an update site at a public host. The feature would depend on a core
> Buckminster installation.
> 
> 3. Publish a copy of the public feature at Eclipse.org without
> physically publishing its dependent bundles. Those bundles are instead
> fetched from the public host using the site.xml archive element. This
> copy would be maintained by a Buckminster committer at Eclipse.org and
> be subject to IP.
> 
> The user would not notice a difference.
> 
> From a development perspective, I think this would make things a lot
> easier. No more patches going into the Buckminster Bugzilla unless API
> changes are needed to the Buckminster core features. Patches going in
> the other direction could also be avoided if a Buckminster team member
> had committer rights to the remote repository.
> 
> What do you (the Maven people in particular) think about this?
> 
> Regards,
> Thomas Hallgren