celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy Lenferink <rlenfer...@apache.org>
Subject Re: Use master as development branch
Date Thu, 07 May 2020 17:36:37 GMT
I checked and (maybe after my subsequent push) the problems didn't show up anymore.
The develop branch has just been merged into the master branch. The base branch for the pull

requests is updated as well (develop -> master) and the pull request against celix-site
is merged
as well.

I have opened https://issues.apache.org/jira/browse/INFRA-20242 to remove branch protection
for the develop branch.

On 2020/05/06 18:44:27, Alexander Broekhuis <a.broekhuis@gmail.com> wrote: 
> Approved! There are some failed checks, not sure if that is relevant for
> merging..
> 
> Also, why not use a branch on the repo, but a fork? Coupling apache and
> github account can easily be done via [1]

Just my personal workflow ;) I have setup my apache/github account already. Besides, using
a fork
limits the number of commit notifications. Otherwise you'd receive an e-mail via commits@
about
my commit (on the branch) and an e-mail on dev@ about the opened pull request (and one to

commit@ and dev@ after merging the pull request). 

Using a fork limits this to the e-mail about the opened pull request (dev@) and one when merged

(dev@ & commit@).

When working with multiple people on the same feature (on the same branch) I agree a branch
on the repo is better.

> 
> [1]: https://gitbox.apache.org/
> 
> Op wo 6 mei 2020 om 20:40 schreef Roy Lenferink <rlenferink@apache.org>:
> 
> >
> >
> > On 2020/05/06 06:17:05, Alexander Broekhuis <a.broekhuis@gmail.com>
> > wrote:
> > > Hi Roy,
> > >
> > > Totally missed your earlier email, my apologies!
> > >
> >
> > No problem!
> >
> > > Regarding the diagram, I'm missing a few things:
> > >
> > > * Currently the tag is done on master, but I think it makes sense to do
> > > this on the release branch itself.
> > >   With the current model, regular (non-release) dev cannot do anything on
> > > master until the release is done. I don't think that is the right way.
> > > * Some feature branch/commit/merge action on master while a release
> > branch
> > > is active makes sense IMO.
> > >
> > > This is similar to what you already did for the hotfix branches, tag on
> > the
> > > branch itself, not on master.
> > >
> > > I've updated the diagram, please take a look if that makes sense.
> >
> > Both changes look good and make sense to me.
> >
> > >
> > > Moving this diagram tot he site is a next step I guess?
> >
> > Indeed. I have just opened the following pull request to the celix-site
> > repo [1]. Feel free to review/
> > approve. If it looks good I'll update our main repo to use the master
> > branch as default branch.
> >
> > [1] https://github.com/apache/celix-site/pull/9
> >
> > >
> > > Op zo 3 mei 2020 om 15:17 schreef Roy Lenferink <rlenferink@apache.org>:
> > >
> > > > Alexander,
> > > >
> > > > Were you able to have a look at the proposed workflow I visualized on
> > the
> > > > wiki page [1][2]? If so, what
> > > > did you think of it and does this change your -1 to a +1 ?
> > > >
> > > > If not, what else is missing before we can move this forward?
> > > >
> > > > [1] https://cwiki.apache.org/confluence/x/MwwRCQ
> > > > [2]
> > > >
> > https://lists.apache.org/thread.html/r179ab76820ca6c156967c2c8af09e197aaa9c221b3d5c76a587c597c%40%3Cdev.celix.apache.org%3E
> > > >
> > > > Roy
> > > >
> > > > On 2020/04/23 04:34:00, Alexander Broekhuis <a.broekhuis@gmail.com>
> > > > wrote:
> > > > > I'm not against this. But would like some more info on how we are
> > going
> > > > to work with this.
> > > > >
> > > > > What is your proposal wrt feature, bugfix and release branches?
> > > > > One concern I have is that last one. With a dev/master split, a
> > release
> > > > branch can be used to prepare a release to master, while dev is used to
> > > > continue merging new features to.
> > > > > How should we do that now?
> > > > >
> > > > > Before doing the actual change, can you draft up a developer page
> > for it?
> > > > >
> > > > > Because of this, for now a -1. Will gladly change to a +1 if things
> > are
> > > > clear!
> > > > >
> > > > > --
> > > > > Met vriendelijke groet,
> > > > >
> > > > > Alexander Broekhuis
> > > > > On 22 apr. 2020 19:22 +0200, Roy Lenferink <rlenferink@apache.org>,
> > > > wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I'd like to propose the idea of using the 'master' branch as
our
> > > > development branch. Why?
> > > > > > - ASF releases are promoted through the ASF mirroring system.
Our
> > > > website is built on top of this
> > > > > > allowing the user to select a mirror for downloading the release.
> > > > Cloning the git repository is not
> > > > > > the first thing a user does. Even if users plan to use the git
> > > > repository they can use a specific tag.
> > > > > > - The ASF allows committers to use a so-called .asf.yaml file
[1]
> > for
> > > > changing repository settings.
> > > > > > However, changes to this file are only propagated when made
on the
> > > > master (or trunk) branch.
> > > > > >
> > > > > > IMO our current workflow with develop/master just adds extra
> > > > complexity. Other ASF projects are
> > > > > > using the master branch as their development branch as well,
e.g.
> > > > Spark [2], Dubbo [3], Flink [4] &
> > > > > > HBase[5].
> > > > > >
> > > > > > If no objections within 72 hours I'll merge the 'develop' branch
to
> > > > our 'master' branch, update the
> > > > > > current open pull requests to have 'master' as base branch,
open a
> > > > ticket to remove branch
> > > > > > protection for the develop branch & update the website to
point to
> > the
> > > > master branch for changes
> > > > > > instead of the develop branch.
> > > > > >
> > > > > > See also [6] for a short discussion on this topic already.
> > > > > >
> > > > > > Best,
> > > > > > Roy
> > > > > >
> > > > > > [1] https://s.apache.org/asfyaml
> > > > > > [2] https://github.com/apache/spark
> > > > > > [3] https://github.com/apache/dubbo
> > > > > > [4] https://github.com/apache/flink
> > > > > > [5] https://github.com/apache/hbase
> > > > > > [6]
> > https://github.com/apache/celix/pull/202#issuecomment-616429007
> > > > >
> > > >
> > >
> > >
> > > --
> > > Met vriendelijke groet,
> > >
> > > Alexander Broekhuis
> > >
> >
> 
> 
> -- 
> Met vriendelijke groet,
> 
> Alexander Broekhuis
> 

Mime
View raw message