devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: [DISCUSS] SVN, versioning, and namespace
Date Mon, 20 Apr 2015 19:05:14 GMT
Volkan,

The recent vote though it just had the minimum of 3 PMC members passed, so
it is up to you if you want to accept it of course, but you're eligable of
a committer account (within the time it takes infra, but it shouldn't be 6
months I assume;-)

Especially if we have dedicated "modules" (looking at tomcat again, it too
has some very separate parts like "native") and/or some also allow syncing
up with Git, it seems more efficient if some who showed they are dedicated
via patches or JIRA posts for  some time (like you did, the "commit" logs
since graduation show everything you posted) plus got the necessary
paperwork are able to commit. Otherwise somebody else always has to pick it
up and commit on their behalf.
Not only using Git there are methods for peer-review like Gerrit, which
even a fairly small team may use as long as there are at least 2-3 people
actively involved. So one can review changes of others. Of course there's
always the release ballot where everyone who votes gets a chance to do the
same.

Werner

On Mon, Apr 20, 2015 at 8:41 PM, Volkan Yazıcı <volkan.yazici@gmail.com>
wrote:

> 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