On 10/08/2009 03:15 PM, Vincent Massol wrote:
>
> On Oct 8, 2009, at 2:08 PM, Anca Paula Luca wrote:
>
>> On 10/06/2009 04:08 PM, Thomas Mortagne wrote:
>>> On Tue, Oct 6, 2009 at 14:45, Jerome Velociter<[email protected]>
>>> wrote:
>>>> For the repository organization, I propose the following :
>>>>
>>>> xlet/ (http://svn.xwiki.org/svnroot/xwiki/xlet/)
>>>> |__applications/
>>>> |__trunk/
>>>> |__xapp1/
>>>> |__xapp2/
>>>> [...]
>>>> |__xappN/
>>>> |__branches/
>>>> [...]
>>>> |__tags/
>>>> [...]
>>>> |__extensions/
>>>> [...]
>>>> |__macros/
>>>> [...]
>>>> |__modules/
>>>> [...]
>>>> |__plugins/
>>>> [...]
>>>> |__skins/
>>>> [...]
>>>>
>>>> Each of the first level sub-directory (applications, extensions,
>>>> macros,
>>>> etc.) having the same meaning of is currently defined on
>>>> code.xwiki.org
>>>>
>>>> WDYT ?
>>>
>>> I'm not sure it's the right way, i think i would prefer to have the
>>> projects directly under xlet/ and have each project decide its own
>>> organization. It's a real pain currently to release plugin and
>>> applications which for lot of them should be released together, we
>>> should try to go the right way this time for a new repository.
>>
>> +1,
>>
>> I think that this kind of organization also matches the normal
>> discovery /
>> exploration path. It happens often enough that an extra
>> functionality on top of
>> xwiki requires application, plugin/module/component and why not a
>> bit of skin.
>> It would be easier, for who would want to find out more about such an
>> application, to go to a single place (contribution/washingdishesapp)
>> and
>> discover all sources in one place, without having to know from the
>> beginning
>> that it's a plugin and then some pages (most of the times when
>> you're interested
>> in an application, this is not the first thing you find out),
>> hopefully it would
>> be able to find that out by looking at the sources and digging
>> further.
>>
>> baseline is that it would make it easier to learn for contributors
>> and more
>> natural, even if for us, the experts, another organization might
>> seem better.
>>
>> For the record, I consider this annoying on code.xwiki.org, the fact
>> that if you
>> want to add extra functionality on top of xwiki, you have to go to
>> several
>> different categories of code to finally find how to add it -- it
>> should be all
>> in a single place, with instructions about how to make it happen.
>
> Anca, as soon as you start to have lots of items I think it's a mess
> if you have no hierarchy. You can't list them anymore.
true, but we could categorize from a functionality / user pov, not a technical
implementation pov.
> We have a search, using the search you get a flat hierarchy.
probably, but the fact that, when searching for 'washing dishes application",
one would get 3 results (one for the app, one for the underlying plugin and one
for the skin), is puzzling ("wha' there's more than 1 app for washing dishes?
which one I need to install? I want an application, I don't want the
plugin.damn
it doesn't work. and why doesn't it look like the screenshot? ah, I need a
skin").
search would only point you in various places of the non-flat hierarchy and
you'd still need to understand the whole hierarchy to figure out why, and how
these dots connect together.
when I first tried to use the code.xwiki.org to install an application, I hit
these problems, and I did have some experience with xwiki at that point.
Thanks,
Anca
>
> Actually I agree with you to transform code.xwiki.org home page by
> having a single live table with column filtering on the type column
> (where type = snippet, macro, etc).
>
> + maybe a what's new with aggregated types listed.
>
> Thanks
> -Vincent
>
>>
>> Thanks,
>> Anca
>>
>>>
>>>>
>>>> Jerome.
>>>>
>>>> Jerome Velociter wrote:
>>>>> Hi all,
>>>>>
>>>>> The subject has been discussed already, see for example
>>>>> http://markmail.org/message/h5e2qinrhsf2slww
>>>>>
>>>>> The idea is to create a new top level project for modules
>>>>> (modules in
>>>>> the sense of everything applications, macros, components,
>>>>> plugins, skin
>>>>> extensions, etc.) that are not part of any products (or the
>>>>> platform)
>>>>> and that are not necessarily contributed by the XWiki development
>>>>> team.
>>>>>
>>>>> The difference with the sandbox is that sandbox is a place for
>>>>> modules
>>>>> being incubated, and that are not in a finished state. Thus, I
>>>>> think one
>>>>> of the rule for introducing new modules in the xlet repository
>>>>> would be
>>>>> that a functional version of the module should be released and
>>>>> available
>>>>> for download (for example on code.xwiki.org).
>>>>>
>>>>> The name "xlet" is the name we've use historically to talk about
>>>>> this
>>>>> repository, this is open for discussion. (personally I like the
>>>>> name -
>>>>> we have to agree this is how we want to name a XWiki "pluggable
>>>>> module"
>>>>> in the large sense).
>>>>>
>>>>> Here is my +1 for the above
>>>>>
>>>>> I would also like to propose that we create a new category of JIRA
>>>>> projects : "XWiki Contributed Xlets" (or equivalent name) for such
>>>>> projects that desire to track issues for their released module,
>>>>> and have
>>>>> the tracker hosted by XWiki.org. I believe this will make easier
>>>>> to have
>>>>> real release cycles for such modules (for example, we can link to
>>>>> the
>>>>> JIRA project from the code.xwiki.org "module" page so that users
>>>>> can
>>>>> report issues instead of using the comments, we can use JIRAs
>>>>> changelog
>>>>> for release notes on the download page, etc.)
>>>>>
>>>>> And my +1 for this second proposal
>>>>>
>>>>> Please, let me know what you think
>>>>> Jerome.
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
