[nvda-addons] Re: SPL add-on 4.0: release date proposal

  • From: "Joseph Lee" <joseph.lee22590@xxxxxxxxx>
  • To: <nvda-addons@xxxxxxxxxxxxx>
  • Date: Sun, 11 Jan 2015 15:08:06 -0800

Hi Mesar,
When I visit the repo site on Bitbucket, I see that it has 9 branches. I'll
remove some of the unnecessary branches that hasn't seen a useful work for a
while.
The current workflow is as follows:
1. Work is done on topic branches.
2. Merge commits from topic branches to master.
3. For 4.0 only, the topic branches were merged into compatibility release
first before merged into master (there were code changes between branches).
I think this was the issue we see today, and I will remove legacy
(compatibility) branch from the repo as it is no longer needed.
4. I usually leave the topic branch alone until master is merged into stable
(but I can see why it could be a problem). I think part of the reason for
this problem might be that I tend to decommission topic branches later just
in case topic branches need further work.
5. Whenever a major version is out, I create maintenance branches for that
major version e.g. 3.x, designed to commit bug fixes in an isolated
environment before merging it into master. The maintenance branches are
deleted once a newer major version is out.
I'll do some more reading on cleaning up Git history. Sorry for the
inconvenience.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Mesar Hameed
Sent: Sunday, January 11, 2015 2:43 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: SPL add-on 4.0: release date proposal

Hi Joseph,

On Sat 10/01/15,16:30, Joseph Lee wrote:
> As there were not bug reports and commits for a while, I'd like to 
> propose releasing SPL add-on 4.0.

Hopefully constructive criticism, which we also discussed on irc before
christmas.

I am not sure if you will get anyone to review the addon as it stands, as it
will take several hrs.
What workflow are you trying to follow? It seems way overcomplicated, even a
large project such as NVDA has a straightforward and understandable flow to
its branching model.
I thought you said in one of your previous emails that you have simplified
it?

The addon currently has 34 branches, and when commits are cherry-picked
rather than the branch is merged, it make things so much harder to see where
things came from/ended up at, and what has been reviewed previously.

As you know its only really Nolia and I that have been volunteering to
review peoples addons, any time taken reviewing code duplicates is time
taken from doing something more rewarding.

Can you please explain what branching strategy you have been using, and
remove branches that have already been merge/cherry picked.

I don't know how confident you are with git, but you could rewrite part of
your history on some new branches which are equivilent to the existing once,
after you check that they are equivilent then the dirty branches can be
deleted.

If you need Guidance on this let me know.

thanks,
Mesar
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs. 

Community addons are available from: http://addons.nvda-project.org To send
a message to the list: nvda-addons@xxxxxxxxxxxxx To change your list
settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx

----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting 
bugs. 

Community addons are available from: http://addons.nvda-project.org
To send a message to the list: nvda-addons@xxxxxxxxxxxxx
To change your list settings/unsubscribe: 
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx

Other related posts: