devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Volkan Yazıcı <volkan.yaz...@gmail.com>
Subject Re: [DISCUSS] SVN, versioning, and namespace
Date Mon, 20 Apr 2015 18:41:32 GMT
Hrm... I really think this is the right time to put the knife, but I
suppose you are more concerned about getting a 2.x ready within the next 6
months, which sounds logical. Anyway, as long as development continues and
DM advances, I am even ok with sharing .patch files via mail.

On Mon, Apr 20, 2015 at 8:35 PM, Reza Naghibi <rezan@apache.org> wrote:

> I agree that git should be a part of this project (I cant imaging managing
> a codebase without it), but im going to go ahead and express my opinion
> that we should punt the git transition to another time. Pretty much
> everything we have done up to this point infrastructure wise has been SVN
> based, so transitioning to git would require significant changes to our
> processes and I think we would be more successful if we treat it as its own
> isolated enhancement. I would like to focus on this effort on the task at
> hand, which is sorting out our codebase and products.
>
> So lets put git on ice and bring it up again in 6 months?
>
> On Mon, Apr 20, 2015 at 2:28 PM, Volkan Yazıcı <volkan.yazici@gmail.com>
> wrote:
>
> > Hello Reza,
> >
> > That is a really good plan. I think this will also enable each "party" to
> > evolve individually. One thing that I really would like to see in this
> list
> > is to move to Git, please.
> >
> > Best.
> >
> > On Mon, Apr 20, 2015 at 8:06 PM, Reza Naghibi <rezan@apache.org> wrote:
> >
> > > Moving this to a clean thread.
> > >
> > > If we can reach agreement here, I will start a [VOTE] thread with all
> the
> > > details listed out and upon a successful vote, we will implement said
> > > details (and enforce them moving forward).
> > >
> > > Feel free to add any points you think are relevant. As always, refrain
> > from
> > > using names, just technology and practices.
> > >
> > >
> > > On Mon, Apr 20, 2015 at 1:30 PM, Reza Naghibi <rezan@apache.org>
> wrote:
> > >
> > > > Bertrand, PMC members, et al,
> > > >
> > > > So I had a few out of thread conversations with people and it turns
> > out a
> > > > these people are very committed to DeviceMap and by leaving this
> > project
> > > I
> > > > would be kind of letting them down. This was never my intention and
> so
> > Im
> > > > willing to take Bertrands offer and apply some kind of code partition
> > > > policy.
> > > >
> > > > So here is what I would be willing to work with. I will explain the
> > > > standard SVN layout with an addition to accommodate the ODDR branch:
> > > >
> > > > https://svn.apache.org/viewvc/devicemap/
> > > >
> > > > *tags* - this folder is for Apache DeviceMap released snapshots and
> is
> > > > obviously used for archiving and branch sourcing purposes. Any
> software
> > > > that is unreleased under Apache rules will be cleared out.
> > > >
> > > > *branch* - this folder is open to anyone to work on new releases or
> > > > experimental features. Just make sure to put your code in a proper
> sub
> > > > directory.
> > > >
> > > > *trunk* - this folder is only for development of currently released
> > > > software. If said software is unreleased, then it needs to go into
> > branch
> > > > or the ODDR folder. *This will require significant cleanup since we
> > have
> > > > the marriage of 1.x and ODDR in here. I repeat, unreleased code and
> > their
> > > > dependencies, specifically ODDR will be moved into
> > > > their appropriate folders.* When we release a major version, the
> > release
> > > > branch and move to trunk and the prior major version will switch to
> > > branch
> > > > (and tags will be made). This way we can support old and new but
> trunk
> > > will
> > > > always be our release head.
> > > >
> > > > *oddr* - we need a separate repo to house ODDR artifacts. Adding a
> > folder
> > > > to our SVN root should be enough to accommodate ODDR dev.
> > > >
> > > > The other request I have is agreement on an ODDR name space and
> > version.
> > > *Had
> > > > I anticipated this situation, our 1.x release would be 2.x, the
> > proposed
> > > > 2.x would be 3.x, and ODDR could hold the 1.x version. This was a
> > mistake
> > > > and that ship has sailed.* My concern is that I dont want currently
> > > > released software to be up-revved in repositories and cause package
> > > > confusion since we are all sharing the DeviceMap name space. So we
> need
> > > to
> > > > properly name and version ODDR so if it does get released and
> > maintained,
> > > > it can be done without causing confusion with regard to the 1.x, 2.x,
> > 3.x
> > > > release path we seem to be going down. I would be willing to give
> ODDR
> > > the
> > > > 0.x version space since thats a pretty standard practice. Im open to
> > > ideas
> > > > here.
> > > >
> > > > Since we dont really have the ability for grainular folder access, I
> > > think
> > > > we have to ask that if you did not create or work on a particular
> code
> > > > base, ask permission before committing otherwise you can expect your
> > code
> > > > to be reverted by the maintainers.
> > > >
> > > > Finally, any sort of marketing or presentations must clearly state
> the
> > > > product (codebase) and version as to not cause product and version
> > > > confusion.
> > > >
> > > > If we can all come to agreement here and then implement the SVN
> > changes,
> > > > then I would feel very comfortable that we can move this project
> > forward
> > > in
> > > > a more partitioned fashion.
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message