1. Messages
  2. OpenDaylight TSC] project names

Re: OpenDaylight TSC] project names

Phil Robb
 

The lead administrator for the OpenDaylight tools is Andrew Grimberg (cc-ed).

In short, I would suggest making this a forward looking policy as opposed to an immediate implementation.

I.e. keep the existing names for the code that is already in the repo with a plan of giving the result of our combining/merging/picking a single core-controller code base a new and conforming name.  Andy can perform that name change as per his comments below.  For new code contribution proposals it would be best to pick a name that can persist through the project's life within OpenDaylight.  We should endeavor to make project names changes the exception as opposed to the rule.

Phil.

 --Andrew Grimberg wrote --
1:30 PM (24 minutes ago)


EEK!!! just saying.

I have an "easy" means of doing the name changes.

1) Project names (and descriptions!) are allocated by the TSC
2) Pending changes for projects are completed / merged and no new
commits are accepted for some amount of freeze time
3) I generate the new code repositories (and associated service silos
during the freeze)
4) The current repository is taken out of service (hard freeze, no more
merges allowed)
5) I take a full clone of repository and do a forced import of the
entire commit history into the new repository

This is going to completely kill Gerrit history though and the only
surviving history is the commits themselves in the the git repository.
There's also fallout to Bugzilla bugs as they are going to be referring
to things that may or not exist anymore ;)

This is a lot of work of course. The alternative is that I do some weird
git rename bingo and somehow (I don't know how) get all the internal
Gerrit information in sync too. I'm far less sure I can pull this off
than the above steps.

-Andy-


On Fri, May 3, 2013 at 1:16 PM, David Meyer <dmm@...> wrote:


In discussing this with Phil he pointed out that we need to bring the developer tools admins into this conversation before we make any decisions. Basically we need to know what is possible with our tool chains. In particular, changing existing names and/or creating a naming paradigm that requires changes when a project changes state (e.g.,  bootstrap2core) may cause issues across the various tool chains.

Phil, who are the right people?

--dmm


On Thu, May 2, 2013 at 1:02 PM, Thomas Nadeau <tnadeau@...> wrote:


From: David Meyer <dmm@...>
Date: Thursday, May 2, 2013 2:51 PM
To: "tsc@..." <tsc@...>
Subject: Re: [OpenDaylight TSC] OpenDaylight TSC] project names


Chris,

>> I've been meaning to bring this up for some time now...
>> 
>> I believe we should establish some guidelines on project names.
>> The current bootstrap projects have named themselves in ways
>> that are not appropriate and create confusion.

Thank you for raising this. I too have been thinking about this for some time now and came to similar conclusions.

>> The code under "controller" project is named "OpenDaylight Controller."
>> The code under "net-virt-platform" project is named "OpenDaylight SDN
>> Controller Platform."  While those projects may aspire towards those
>> names, they haven't, IMO, earned those names yet.
>> 
>> I suggest that names should be more like codenames (with appropriate
>> trademark vetting still done).
>> 
>> I suggest that the current names be changed to reflect the above
>> sentiment.
>> 
>> I suggest that the project lifecycle document be updated to take this
>> into account.  Perhaps as part of Graduation review, we'd allocate a
>> ODP-wide name that's no longer just the code name.
>> 
>> So, for example, we'd have proposal named HotSidewalk, which upon Graduation
>> (based on it's functionality) becomes OpenDaylight EggFryer.
>> 
>> Thoughts?

I agree. However,  this does suggest that we need a way to manage names, both initially and after Graduation. As you suggest this should likely be part of the lifecycle document. Others?

Agree. The names should perhaps indicate their status too (I.e.: bootstrap, etc…).  

We should also make sure that project names, and any internal object naming is stripped of any commercially named or licensed names to avoid the obvious issues. I think that is specified in the governing documents, but its ultimately up to the TSC to enforce this policy. 

--Tom


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
Join {TSC@lists.opendaylight.org to automatically receive all group messages.