On 09/12/2011 12:02 PM, Vincent Massol wrote: > > On Sep 12, 2011, at 5:50 PM, Sergiu Dumitriu wrote: > >> On 09/12/2011 03:15 AM, Vincent Massol wrote: >>> >>> On Sep 12, 2011, at 9:07 AM, Thomas Mortagne wrote: >>> >>>> On Mon, Sep 12, 2011 at 9:06 AM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> On Mon, Sep 12, 2011 at 9:00 AM, Vincent Massol<[email protected]> >>>>> wrote: >>>>>> >>>>>> On Sep 12, 2011, at 8:49 AM, Thomas Mortagne wrote: >>>>>> >>>>>>> On Mon, Sep 12, 2011 at 8:15 AM, Vincent Massol<[email protected]> >>>>>>> wrote: >>>>>>>> Result: 5 +1, 1 +0 and no -1 >>>>>>>> >>>>>>>> The vote is passed. I'll try to move them today to >>>>>>>> https://github.com/xwiki-contrib/sandbox (note that the calendar >>>>>>>> plugin will be renamed since there's already a xwiki-calendar module >>>>>>>> in there - not sure what it is, probably a GSOC one). >>>>>>> >>>>>>> Why in sandbox ? I would say either in their own repository or in >>>>>>> retired. >>>>>> >>>>>> Because: >>>>>> 1) own repo means that the project is active and someone is an owner of >>>>>> it. We don't have any owner for these projects ATM. They can be >>>>>> graduated from sandbox when someone takes the ownership and release a >>>>>> new version of them. >>>>>> 2) retired mean that these projects are not useful any more and have >>>>>> been replaced by better stuff. I think they're still useful for most of >>>>>> them, at least for: photo album, calendar, exo, alexa, adwords and s5. >>>>>> For workstream it's possible it's not useful anymore with our new >>>>>> message stream. >>>>>> >>>>>> Said differently retired projects means to people: don't even bother >>>>>> about those, they're dead and not useful any more. While sandbox means: >>>>>> these projects are in uncertain states but can still be useful if >>>>>> someone brings a little love to them. >>>>>> >>>>>> At least that's how I view the difference. >>>>>> >>>>>> Of course, these projets use the old plugin technology so we could >>>>>> decide that anything that uses the old plugin tech should be retired. >>>>>> But if we do this we need to decide this for all other projects using >>>>>> plugin tech too, not just these ones and there are lots of plugin >>>>>> projects in their own repos and in sandbox (not mentioning the several >>>>>> plugins that even in platform and that are not retired). We should also >>>>>> consider that some people may be using the photo album or calendar >>>>>> plugins so moving them to retired isn't a good idea IMO. >>>>>> >>>>>> WDYT? >>>>> >>>>> Problem whit moving theses project to sandbox is that sandbox does not >>>>> fits very well project which already have tags and branches and >>>>> several versions already. If a project was graduate from sandbox to >>>>> own repository and because not very active anymore I doubt we would >>>> >>>> s/because/became/ >>>> >>>>> put it back in sandbox. >>> >>> Indeed, that's a good point but we need to find a good general solution >>> because this is what we'd be doing when moving stuff to retired too! :) >>> >>> Maybe we should just have one repo for each project whatever its state >>> (retired, sandbox, etc) and instead indicate its state in a READM file in >>> that module (or maybe in its name with a convention but I don't know how >>> easy/bad it is to rename a repo so a README file sounds easier). >> >> +1, but we'll leave the existing sandbox and retired in place.
...for the moment. > Why? (apart form the fact that it's tedious to move stuff out but this can be > automated I guess). For that reason, and also because many things have been moved without history in retired, so there's not much benefit in moving them in a new repository. > Thanks > -Vincent > >> >>> If we do this then we don't need a notion of sandbox/retired/active >>> anymore. We just need to ensure that we give some visibility for people >>> looking at these repos. >>> >>> For example for plugins we could put in the README something like: "This >>> extension uses the plugin technology which has been deprecated and is now >>> replaced by Components (see …). If someone is interested in improving this >>> extension, we recommend rewriting it as components." >>> OR (for ex for calendar) >>> "This extension hasn't been active for a long time. However it's an >>> interesting extension that could benefit from being contributed to the >>> XWiki platform. However in order for this to happen we would need someone >>> to rewrite using components, make it follow the xwiki platform best >>> practices, add some tests and create a pull request on the XWiki platform >>> git repo" >>> >>> Thanks >>> -Vincent >>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>> On Apr 5, 2011, at 6:55 PM, Vincent Massol wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm proposing to move the following modules from xwiki-platform-core >>>>>>>>> to separate git repos in a xwiki-contrib organization on GitHub: >>>>>>>>> >>>>>>>>> xwiki-platform-calendar >>>>>>>>> xwiki-platform-exo >>>>>>>>> xwiki-platform-adwords >>>>>>>>> xwiki-platform-alexa >>>>>>>>> xwiki-platform-photoalbum >>>>>>>>> xwiki-platform-s5 >>>>>>>>> xwiki-platform-workstream >>>>>>>>> >>>>>>>>> Rationale: >>>>>>>>> * They're no longer working or supported >>>>>>>>> * We can move them back if the xwiki dev team wants to support them >>>>>>>>> again in the future >>>>>>>>> * It's cleaner than having a retired module in the xwiki organization >>>>>>>>> since a) it's not "polluting" the list of repos supported by the >>>>>>>>> xwiki dev team and b) it allows them to be separated in repos >>>>>>>>> >>>>>>>>> Future: >>>>>>>>> * Also move modules currently in svn contrib to xwiki-contrib org. >>>>>>>>> Note that we need to verify if the svn app works with the GitHub svn >>>>>>>>> integration too since several users of svn contrib are using it. >>>>>>>>> >>>>>>>>> Here's my +1 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
