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
