commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)
Date Sun, 23 Jun 2013 19:42:17 GMT
On 23 June 2013 20:35, Mark Thomas <markt@apache.org> wrote:
> On 23/06/2013 20:28, sebb wrote:
>> On 23 June 2013 19:56, Benedikt Ritter <beneritter@gmail.com> wrote:
>>>
>>> Am 23.06.2013 um 20:16 schrieb sebb <sebbaz@gmail.com>:
>>>
>>>> On 23 June 2013 16:10, Jörg Schaible <joerg.schaible@gmx.de> wrote:
>>>>> sebb wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> But we still need to resolve:
>>>>>> - where in SVN these tools belong
>>>
>>> Let's just create a new top level folder under http://svn.apache.org/asf/commons.
release-tools or something like that seems intuitive.
>>>
>>>>>> - how to ensure the tools are readily available to RMs
>>>>>
>>>>> Well, don't we have the possibility to publish these plugins somewhere
on
>>>>> the web site? All that Maven actually needs is a structure that looks
like a
>>>>> repo.
>>>>
>>>> That's very good news.
>>>> Presumably the RM would just need to add the repo to their
>>>> settings.xml and they would then have access to the plugins?
>>>> That would avoid the manual install step, and make it easier to provide updates.
>>>>
>>>> How easy is it to install plugins in such a repo?
>>>> Ideally we could use a part of the Commons SVN tree.
>>>> Since our SVN is accessible over http that could be used as the repo URL.
>>>
>>> SVN should not be used to manage binaries. Maybe we should ask the Maven ML how
to organize the plugins. Or maybe INFRA can help?
>>
>> SVN is used to manage binaries in the dist.apache.org repo.
>
> With my infra hat on, using svn for binaries is fine. I'd say having
> these binaries in the same part of the tree as the source is a bad idea.

I was thinking of a separate top-level folder in commons, but elsewhere is fine.

> The other options are the /dist repo or the website.
>
> The website isn't really the right place either.

+1

> I don't like /dist/release/commons since these are not releases and they
> shouldn't be on the mirrors.

+1

> /dist/dev/commons could work.

Good idea.

I'll set up some initial entries and see how it works.

> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message