Hello,
I'll toss in my 0,013 €... I guess its a question of benefit. At the
moment, maintaining any customizations/extensions against a package
namespace that is moving will be incurred by our users. We want to limit
that cost as much as possible for the 1.x lineage. Thus I do not see a gain
in our jumping quickly onto the package renaming bandwagon. I would promote
using it in two areas:
1.) Our modules project space for contributed and modularized projects:
http://scm.dspace.org/svn/repo/modules/
2.) Including our work on DSpace 2.0
http://scm.dspace.org/svn/repo/dspace2
Given these are not yet adopted/modified strictly by the community, the cost
of adjusting these now is much lower.
Cheers,
Mark
On Mon, Nov 23, 2009 at 11:58 AM, Chris Wilper <[email protected]>wrote:
> Just to clarify, "Fedora Commons" the non-profit business entity has
> been subsumed by DuraSpace. The *community* of "Fedora Commons" is
> very much alive. But also see Thorny's recent announcement about
> "Fedora Create". (Interesting that it can also be abbreviated
> "fc"....but I digress...)
>
> A couple practical points on using duraspace.org:
>
> + Fedora is the only project under the DuraSpace umbrella that is
> currently at a *natural* package-renaming point. Mulgara, DSpace, and
> DuraCloud have all established thier own package naming conventions,
> and they are all based on a projectname.org style convention. Akubra
> now uses this as well. Although the vote on the table is not for a
> DuraSpace-wide naming convention, it's nice to be consistent with our
> conventions across the major projects where possible.
>
> + Having the same base package name for a group of projects does not
> improve their ability to interoperate.
>
> - Chris
>
> On Mon, Nov 23, 2009 at 10:44 AM, Asger Askov Blekinge
> <[email protected]> wrote:
> > Hi Brad
> >
> > I would like to refer you to
> > http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.7
> >
> > It suggest the following:
> > You form a unique package name by first having (or belonging to an
> > organization that has) an Internet domain name, such as sun.com. You
> > then reverse this name, component by component, to obtain, in this
> > example, com.sun, and use this as a prefix for your package names, using
> > a convention developed within your organization to further administer
> > package names.
> >
> > And true, this is just a suggestion, not a demand for java.
> >
> > There are components to this. It requires that you have the
> > corresponding domain, in order to use the namespace. It suggest that you
> > use the namespace of your organization, not just some domain you own.
> >
> > I am unclear if fedora-commons is an organisation, or fedora is a
> > project under the duraspace organisation. This, to me, is the deciding
> > factor about which namespace we should use.
> >
> > In short, we should use the primary organisational domain name as the
> > namespace. At the moment this is probably
> > fedora-commons.org and we should thus use org.fedora_commons
> >
> > Regards
> >
> >
> >
> >
> > On Mon, 2009-11-23 at 15:37 +0100, Bradley McLean wrote:
> >> Excuse me, please, for jumping in with a non-voting opinion.
> >>
> >> I'm not sure I see direct value in inserting 'duraspace' into each
> >> individual project's naming schemes. I'd like to hear more, or see an
> >> example of projects using different domain names for code and "official
> >> information" where it becomes a problem. Similarly, I'd like to hear
> >> more about how changing the naming scheme is going to help code sharing
> >> without creating many issues related to release scheduling, packaging,
> etc.
> >>
> >> There is a distinction to be made between the Duraspace organization,
> >> and the projects that are currently under it's banner. Projects can and
> >> do move across organizational boundaries (DSpace has done so twice now
> >> in three years). While we certainly hope that we'll continue to hold
> >> the projects together, the projects are independent from each other, and
> >> have separate governance models, so the future isn't guaranteed.
> >>
> >> Achieving a consensus on a uniform set of org.duraspace prefixes
> >> involves at least four distinct groups (fedora committers, dspace
> >> committers, mulgara committers, duraspace organization) coming to
> >> internal and external agreement. There is a similar issue with merging
> >> websites together, or to go farther, wiki sites, mailing lists, and the
> >> like.
> >>
> >> So my opinion is that it is premature to start carving up and allocating
> >> duraspace.org namespace, especially on the timeframe required for the
> >> fedora package renaming vote.
> >>
> >> I've changed the Subject so as not to pollute the vote with this
> >> discussion, and I very much do want to hear those examples of projects
> >> for which separated names are an issue - we may have something to
> >> learn. Also, I applaud attempts to encourage code sharing, but I'd like
> >> some debate on whether renaming helps in this case.
> >>
> >> Thanks for allowing the intrusion. I'll completely identify myself for
> >> clarity below, but let me emphasize that this is a non-voting personal
> >> opinion, and not any sort of official (or officious!) mandate.
> >>
> >> -Brad
> >>
> >> Bradley McLean, CTO, DuraSpace.
> >>
> >> Kåre Fiedler Christiansen wrote:
> >> > Hi list,
> >> >
> >> > +1 on org.duraspace.
> >> >
> >> > We currently have a majority among non-committers for this one :-)
> >> >
> >> > Especially, I agree with Matthias about obscure abbreviations, and I
> >> > _really_ like the idea about using existing well-known domain names.
> >> > Also, code sharing seems like a good reason for this naming scheme.
> >> >
> >> > I know of a few project using different domain names for their code
> and
> >> > their "official information", and it always confuses me where I need
> to
> >> > go look for code and information. Fedora already has far too many
> >> > different websites and domain names. With the death of fedora.info it
> >> > seems we got a new situation with fedora-commons.org and
> duraspace.org.
> >> > Perhaps it would be a good idea to merge the websites on
> >> > "http://fedora.duraspace.org";, "http://dspace.duraspace.org"; etc.? Or
> at
> >> > least start planning for it.
> >> >
> >> > My second choice would be "org.fedora-commons.repository", if
> agreement
> >> > can't be reached with the rest of duraspace.
> >> >
> >> > Best,
> >> > Kåre
> >> >
> >> > On Sat, 2009-11-21 at 18:26 +0100, Razum, Matthias wrote:
> >> >
> >> >> g_baseurl="
> http://excluster.fiz-karlsruhe.de/exchange/Matthias.Razum/Entw%C3%BCrfe/AW:%20[Fedora-commons-developers]%20call%20for%20vote%20on%20package%20renaming.EML/1_text.htm
> ";
> >> >> org.duraspace.fedora
> >> >> org.duraspace.dspace
> >> >> org.duraspace.duracloud
> >> >> org.duraspace.mulgara
> >> >> ...
> >> >>
> >> >> A bit verbose, but has a clear association with the new
> >> >> organization, allows for shared code packages, and has no ugly and
> >> >> misleading abbreviations in it.
> >> >>
> >> >> But as I am not a committer, my vote won't count ;-)
> >> >>
> >> >> Matthias.
> >> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> >> trial. Simplify your report design, integration and deployment - and
> focus on
> >> what you do best, core application coding. Discover what's new with
> >> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> Fedora-commons-developers mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Fedora-commons-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
> >
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
