>From my side, I support whatever you (Joachim + Kristian) decide to do
with the organization of apps.

--
Anders


On Tue, May 28, 2013 at 10:55:12AM +0200, Kristian Ølgaard wrote:
>    On 28 May 2013 10:49, Joachim Berdal Haga <[1][email protected]> wrote:
>
>    On 28 May 2013 10:35, Kristian
>    Ølgaard <[2][email protected]> wrote:
>
>    increases the visibility. So I think that adding fenics-apps to
>    Bitbucket would essentially be a common starting point for obtaining
>    the code for the individual apps projects. It is then up to the
>    developers to organise their own project pages. How to do this on
>    Bitbucket, to allow teams of devs to manage subprojects, is the only
>    issue as I see it.
>
>    The "technical" side of things should work out fine, I think. The
>    administrators (whoever: me, or you, or a team; I'm not fussed) will
>    have to create the repo for each project. But the application project
>    will have full administrative rights to the repo from there on, to set
>    up access rights (along with wiki, bug tracker etc). I think it is also
>    possible to set up a repo redirect, if anyone wants to have a presence
>    on [3]bitbucket.org/fenics-apps but has code elsewhere. This is all
>    voluntary and initiated by the app author, of course.
>
>    Why not simply give it a go then, unless anyone strongly objects? If
>    you start with cbc.block, then we try adding FEniCS Plasticity later.
>    Kristian
>
>    -j.
>    On 28 May 2013 10:35, Kristian Ølgaard <[4][email protected]>
>    wrote:
>
>    On 28 May 2013 10:07, Joachim Berdal Haga <[5][email protected]> wrote:
>
>    I'll kick off: The value of fenics-apps in general is in the increased
>    visibility of these projects, and in return in "adding value" to fenics
>    by increasing its scope. But the value of any specific mechanism
>    whereby the apps are grouped or blessed - on [6]fenicsproject.org, on
>    launchpad or bitbucket, in the book - is more fluid. In my opinion,
>    each of these has a potential audience and are worthwhile
>
>    I agree with Joachim on the above. I see the apps as complex demos of
>    what can be solved within the FEniCS framework and this is what the
>    apps does for the community. In return, the apps are listed on
>    [7]http://fenicsproject.org/applications/ which increases the
>    visibility. So I think that adding fenics-apps to Bitbucket would
>    essentially be a common starting point for obtaining the code for the
>    individual apps projects. It is then up to the developers to organise
>    their own project pages. How to do this on Bitbucket, to allow teams of
>    devs to manage subprojects, is the only issue as I see it.
>    In the old mediawiki days, I believe the only requirements for a
>    project to be considered a candidate for FEniCS-Apps was that it used
>    at least one of the core components and that the license was compatible
>    with that of the relevant FEniCS component(s).
>    Kristian
>
>    -j.
>
>    On 28 May 2013 09:55, Garth N. Wells <[8][email protected]> wrote:
>
>    On 28 May 2013 08:35, Joachim Berdal Haga <[9][email protected]> wrote:
>    > I think with the limited interest and disagreements about procedure,
>    I'll
>    > shelve this idea for now.
>    >
>
>      I wouldn't say disagreements - it's a different system so the pros
>      and
>      cons needed to be assessed to make an informed decision. It's also
>      an
>      opportunity to reflect on what with the 'apps' has worked well, and
>      what perhaps hasn't worked well. I think it's a discussion still
>      worth
>      having.
>      Garth
>
>    >
>    >
>    > On 23 May 2013 13:46, Joachim Berdal Haga <[10][email protected]> wrote:
>    >>
>    >> Why, it seems like a perfectly sensible policy to me. The projects
>    listed
>    >> on that page are under the fenics applications umbrella, and hence
>    permitted
>    >> to have repos in the fenics-apps team. The projects that do not want
>    to be
>    >> hosted within fenics-apps are not going to be forced into it, of
>    course!
>    >>
>    >> -j.
>    >>
>    >>
>    >> On 23 May 2013 13:20, Garth N. Wells <[11][email protected]> wrote:
>    >>>
>    >>> On 23 May 2013 12:07, Joachim Berdal Haga <[12][email protected]>
>    wrote:
>    >>> > Yes. I suggest that whatever is listed on
>    >>> > [13]http://fenicsproject.org/applications/ is sanctioned. Which
>    just moves
>    >>> > the
>    >>> > problem elsewhere, but that problem already exists.
>    >>> >
>    >>>
>    >>> That's not a policy.
>    >>>
>    >>> Not all those projects will want to be hosted within a fenics-apps
>    >>> team. What will their status be?
>    >>>
>    >>> Garth
>    >>>
>    >>> > Does anybody else have an opinion on whether 'fenics-apps' should
>    exist
>    >>> > as a
>    >>> > team? In particular, are any of the other projects listed at
>    >>> > [14]fenicsproject.org/applications/ interested?
>    >>> >
>    >>> > -j.
>    >>> >
>    >>> >
>    >>> > On 23 May 2013 12:30, Garth N. Wells <[15][email protected]> wrote:
>    >>> >>
>    >>> >> On 23 May 2013 11:10, Joachim Berdal Haga <[16][email protected]>
>    wrote:
>    >>> >> > True, but I don't see it as significant. The repo can contain
>    >>> >> > multiple
>    >>> >> > development/release/topic branches, and if this isn't
>    sufficient
>    >>> >> > then
>    >>> >> > multiple repos can be created by the team administrators.
>    >>> >> >
>    >>> >>
>    >>> >> Just something to weigh up. The key question is whether having
>    'team'
>    >>> >> is better than individual project teams. For example, maybe the
>    CBC
>    >>> >> collection is better as it's own team with a collection of
>    >>> >> projects/repos rather than as a bunch of repos in a apps team.
>    >>> >>
>    >>> >> If there is one apps team and it's 'sanctioned', there needs to
>    be a
>    >>> >> policy on how a project qualifies, and under what circumstances
>    it
>    >>> >> should be removed.
>    >>> >>
>    >>> >> Garth
>    >>> >>
>    >>> >>
>    >>> >> > (Later, after looking into team access administration:) I see
>    now
>    >>> >> > that
>    >>> >> > repo
>    >>> >> > creation is a separate acl, so it is possible to give creation
>    >>> >> > rights to
>    >>> >> > projects without giving full administrative access.
>    >>> >> >
>    >>> >> > -j
>    >>> >> >
>    >>> >> >
>    >>> >> > On 23 May 2013 11:31, Garth N. Wells <[17][email protected]>
>    wrote:
>    >>> >> >>
>    >>> >> >> On 20 May 2013 21:33, Anders Logg <[18][email protected]> wrote:
>    >>> >> >> > On Mon, May 20, 2013 at 08:13:44PM +0200, Joachim Berdal
>    Haga
>    >>> >> >> > wrote:
>    >>> >> >> >>    I'm about to move cbc.block (which is listed as a
>    fenics
>    >>> >> >> >> application)
>    >>> >> >> >>    from launchpad to bitbucket. I think it would be nice
>    if the
>    >>> >> >> >> repository
>    >>> >> >> >>    could be in a "fenics-apps" team - like the
>    "fenics-group"
>    >>> >> >> >> project
>    >>> >> >> >> on
>    >>> >> >> >>    launchpad. It makes the fenics applications more
>    >>> >> >> >> discoverable,
>    >>> >> >> >> and
>    >>> >> >> >> the
>    >>> >> >> >>    urls more descriptive.
>    >>> >> >> >>    I can of course create this team myself since the name
>    isn't
>    >>> >> >> >> taken,
>    >>> >> >> >> but
>    >>> >> >> >>    I'd prefer it to be decided by somebody more in the
>    loop than
>    >>> >> >> >> I...
>    >>> >> >> >
>    >>> >> >> > I think having a fenics-apps team
>    >>> >> >> > ([19]https://bitbucket.org/fenics-apps)
>    >>> >> >> > would be a good idea. And same as last time, I'd prefer if
>    >>> >> >> > someone
>    >>> >> >> > else took charge of it. Previously, Andy and Kristian did
>    this on
>    >>> >> >> > Launchpad.
>    >>> >> >> >
>    >>> >> >> > So if you volunteer, just go ahead and create the team, but
>    lets
>    >>> >> >> > wait
>    >>> >> >> > to get some more comments, especially from Andy and
>    Kristian.
>    >>> >> >> >
>    >>> >> >>
>    >>> >> >> There are some drawbacks to this. An 'apps' project won't
>    have full
>    >>> >> >> control, e.g. will not be able to create multiple repos. On
>    >>> >> >> Launchpad,
>    >>> >> >> fenics-apps was an umbrella rather than  a team.
>    >>> >> >>
>    >>> >> >> Garth
>    >>> >> >>
>    >>> >> >>
>    >>> >> >>
>    >>> >> >
>    >>> >> >
>    >>> >
>    >>> >
>    >>
>    >>
>    >
>
>      _______________________________________________
>      fenics mailing list
>      [22][email protected]
>      [23]http://fenicsproject.org/mailman/listinfo/fenics
>
> Referenser
>
>    1. mailto:[email protected]
>    2. mailto:[email protected]
>    3. http://bitbucket.org/fenics-apps
>    4. mailto:[email protected]
>    5. mailto:[email protected]
>    6. http://fenicsproject.org/
>    7. http://fenicsproject.org/applications/
>    8. mailto:[email protected]
>    9. mailto:[email protected]
>   10. mailto:[email protected]
>   11. mailto:[email protected]
>   12. mailto:[email protected]
>   13. http://fenicsproject.org/applications/
>   14. http://fenicsproject.org/applications/
>   15. mailto:[email protected]
>   16. mailto:[email protected]
>   17. mailto:[email protected]
>   18. mailto:[email protected]
>   19. https://bitbucket.org/fenics-apps
>   20. mailto:[email protected]
>   21. http://fenicsproject.org/mailman/listinfo/fenics
>   22. mailto:[email protected]
>   23. http://fenicsproject.org/mailman/listinfo/fenics

> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics

_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to