4 Apr
2011
4 Apr
'11
6:36 p.m.
On Apr 4, 2011, at 6:21 PM, Vincent Massol wrote:
On Apr 4, 2011, at 6:16 PM, Denis Gervalle wrote:
Note that there's still the github/svn integration so someone who really doesn't
want the history can still get the source without the history using the svn integration.
Last, we also publish source code in our maven repo and thus it's possible for someone
just to get the sources for the version he wants to patch/build if size is really an issue
(like if he's building xwiki on his iphone for example).
Thanks
-Vincent
On Mon, Apr 4, 2011 at 17:12, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
I don't agree about removing any history.
It looks to me that using git means using a lot of disk space (since you get a local repo
with full history), we need to live with that or not use git at all. On 04/04/2011 03:49 PM, Fabio Mancinelli wrote:
I am not sure it really worse to consume that bandwidth for such
information.
But how could we keep it online for reference in case we need to check it ? On Mon, Apr 4, 2011 at 3:04 PM, Vincent
Massol<vincent(a)massol.net>
wrote:
> Hi,
>
> After brainstorming with Thomas, Sergiu and Fabio we came to the
following
idea:
>
> Proposal
> =======
>
> * Don't have top level extension git repositories and instead put all
extensions/modules in the top level platform repository
> * This means releasing all modules/extensions
under the *same* version
(the platform version)
>
> ^^^^^^^^
> This is the important part!
>
+1 for me
I just had a thought about the granularity... Having everything in a
big repo will make people clone more than 200Mb of source code even to
hack a little module (currently xwiki-trunks on github downloads 277Mb
of code). But maybe this is not really an issue.
Most of it (140M) comes from xwiki-core, which is not a real module yet.
Thanks
-Vincent
> Denis
>
>
>> And most of it comes from the very early history when we had all the
>> libs in the svn.
>>
>> So, we could decide to drop the history before the introduction of
>> maven, or we could move the core in its own repository and push for a
>> faster migration to components.
>>
>> Or we can just learn to live with it, we have a long history and we're
>> proud of it.
>>
>>> -Fabio
>>>
>>>> Pros
>>>> ====
>>>>
>>>> * Much simpler release process
>>>> * Much simpler JIRA organization (1 project instead of 50 or so)
>>>> * Much simpler for the user: simpler to log a new issue in jira +
>> they'll know what version of a module they're using vs having to guess
that
>> XE 3.0 uses the Lucene plugin v 1.45) and for contributors
>>>>
>>>> Directory org
>>>> ==========
>>>>
>>>> platform/
>>>> |_ modules/
>>>> |_ xwiki-platform-search/
>>>> |_ xwiki-platform-search-lucene/
>>>> |_ xwiki-platform-search-application/
>>>> |_ xwiki-platform-url/
>>>> |_ xwiki-platform-skin-colibri/
>>>> |_ xwiki-platform-wysiwyg/
>>>> |_ ...
>>>> |_ tools/
>>>> |_ distribution/
>>>>
>>>> Details:
>>>>
>>>> * Modules contains a flat list of directories, each directory
>> representing a "feature". Everything corresponding to a feature is
under
>> that feature's directory, independently of the underlying technologies used
>> (be it plugins, components, xar, etc)
>>>> * Maven modules previously located in platform/web are moved in
>> platform/modules. Except platform/web/standard which goes in
>> platform/distribution. wysiwyg modules go in xwiki-platform-wysiwyg/ (we
>> need to decide if gwt-dom and gwt-user modules go in there too or if we want
>> to have a xwiki-platform-gwt module - Marius?)
>>>>
>>>> Migration details
>>>> =============
>>>>
>>>> * Change the current org in git
>>>> * Move several jira projects to retired
>>>> * Modify platform jira project to have one jira component per feature
>> (ie per platform/modules module). Note that since the old xwiki-core
>> contains lots of stuff I propose to have one jira components for each
>> "feature" it contains. For example for anything related to the model
it
>> would go in the "model" jira component. For things going in the user
>> management it would go in a "user and group" component, etc. I'll
make a
>> proposal for the full list of jira components later on if this vote is
>> passed.
>>>> * Future: decide if we keep extensions.xwiki.org and if so what we put
>> in there (maybe just user extensions and move platform features in
>> platform.xwiki.org).
>>>>
>>>> Here's my +1 (meaning I'll help perform this move)
>>>>
>>>> Thanks
>>>> -Vincent