Hi Anca, On Apr 5, 2011, at 7:24 PM, Luca Anca wrote:
> On Mon, 2011-04-04 at 18:34 +0200, Vincent Massol wrote: >> On Apr 4, 2011, at 4:53 PM, Luca Anca wrote: >> >>> On Mon, 2011-04-04 at 15:04 +0200, Vincent Massol 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! >>>> >>>> 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/ >>>> |_ ... >>> >>> Platform here contains only features which are bound with the platform, >>> right? (e.g. in the current extensions I noticed the photoalbum >>> application, for example, which is not). >> >> Nope :) >> >>> So I agree with this only if under platform modules are only the things >>> bundled in the platform. Otherwise it doesn't make sense releasing >>> everything. >> >> Platform means any module that can be used to build a runtime product (XE, >> XEM, watch, etc). A runtime product doesn't have to use all modules from the >> platform. >> >> Said differently platform contains all the bit and pieces that can be reused >> to build a full-fedged runtime application. >> >> Note that this is the current definition and this proposal keeps that >> definition. > > So we release everything everytime? even things that haven't changed a > bit and that noone uses? Yes. We're already doing this a lot, we're just expanding the scope and at the same time certifying that everything released works together. > I'm not sure this is clearer than having independent versioning of > things. It's clearer because when you use XWiki Enterprise 3.0 you have no clue what version of the Administration app you're using and if you find an issue you have no clue what version to use in jira for the affects field. However the main reason for this proposal is to ease release management. > Also, this creates a bit of work, because hopefully we'd want to be able > to say that 3.6 of the photoalbum works on 3.6 of platform, for example. > Otherwise it doesn't make sense to release it. Yes that's the point too: be better at certifying what works on what. We're reducing the # of combinations but improving the quality of the few versions we release. I'd suggest you propose yourself as release manager for 3.1 to understand what it means to release XE! :) Thanks -Vincent PS: I'm not sure we're going in the right direction. It's possible that in the future we change track and separate everything again. What I'm sure of though is that this new organization will greatly simplify release management and user issue reporting. >>>> |_ 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. >>> >>> Why? >>> >>> It would be great if we could put webapp resources under >>> platform/modules as well (such as js & css), each for its feature, and >>> make them endup in the distribution webapp. >> >> Yes definitely. I was talking about the distribution part (the creation of >> the WAR). I agree that the templates and web resources in general should be >> under platform/modules too. >> >>> For all the other aspects, with the little knowledge that I have about >>> the git model, I guess I agree with Fabio that 277 megs for a guy that >>> only needs to patch a module rebuild it and drop it in his classpath is >>> a bit too much, so we might want independent repos (but I am not sure). >> >> Well if git is "bad" then we shouldn't used it but I'd hate to choose to >> make our life really hard just because git has a model that is >> disk-space-hungry. If we don't want to waste disk space we shouldn't use git >> at all! Imagine: we're 15 committers and we'll have 15 times the whole >> history. That's disk space waste and is the downside of other nice features >> of git. >> >> Personally I think we're beyond disk space nowadays in 2011 and I don't see >> it as a problem (note that just using XWiki requires 164MB). > > It's not disk space, it's bandwidth. And even if that is no longer such > a big concern nowadays, it still takes some time. And time is money. > > Thanks, > Anca > >> >> Thanks >> -Vincent >> >>> Overall 0. >>> >>> Thanks, >>> Anca >>> >>>> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
