cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Clean up old and obsolete branches
Date Mon, 18 Dec 2017 13:39:28 GMT
any workable procedure (including yours, Rafael) will do but let's be
extremely patient and lenient. I think we can start deleting a lot of old
branches (RC-branches and merged PRs to start with)

On Mon, Dec 18, 2017 at 2:23 PM, Marc-Aurèle Brothier <marco@exoscale.ch>
wrote:

> +1 for me
>
> On the point 5, since you can have people working together on forks, I
> would simply state that no other branches except the official ones can be
> in the project repository, removing: "If one uses the official repository,
> the branch used must be cleaned right after merging;"
>
> On Mon, Dec 18, 2017 at 2:05 PM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
> > Guys, this is the moment to give your opinion here. Since nobody has
> > commented anything on the protocol. I will just add some more steps
> before
> > deletion.
> >
> >    1. Only maintain the master and major release branches. We currently
> >    have a system of X.Y.Z.S. I define major release here as a release
> that
> >    changes either ((X or Y) or (X and Y));
> >    2. We will use tags for versioning. Therefore, all versions we release
> >    are tagged accordingly, including minor and security releases;
> >    3. When releasing the “SNAPSHOT” is removed and the branch of the
> >    version is created (if the version is being cut from master). Rule (1)
> > one
> >    is applied here; therefore, only major releases will receive branches.
> >    Every release must have a tag in the format X.Y.Z.S. After releasing,
> we
> >    bump the pom of the version to next available SNAPSHOT;
> >    4. If there's a need to fix an old version, we work on HEAD of
> >    corresponding release branch;
> >    5. People should avoid using the official apache repository to store
> >    working branches. If we want to work together on some issues, we can
> > set up
> >    a fork and give permission to interested parties (the official
> > repository
> >    is restricted to committers). If one uses the official repository, the
> >    branch used must be cleaned right after merging;
> >    6. Branches not following these rules will be removed if they have not
> >    received attention (commits) for over 6 (six) months;
> >    7. Before the removal of a branch in the official repository it is
> >    mandatory to create a Jira ticket and send a notification email to
> >    CloudStack’s dev mailing list. If there are no objections, the branch
> > can
> >    be deleted seven (7) business days after the notification email is
> sent;
> >    8. After the branch removal, the Jira ticket must be closed.
> >
> >
> >  I will wait more two days. If we do not get comments here anymore, I
> will
> > call for a vote, and then if there are no objections I will write the
> > protocol on our Wiki. Afterwards, we can start removing branches
> (following
> > the defined protocol).
> >
> > On Thu, Dec 14, 2017 at 5:08 PM, Daan Hoogland <daan.hoogland@gmail.com>
> > wrote:
> >
> > > sounds lime a lazy consensus vote; +1 from me
> > >
> > > On Thu, Dec 14, 2017 at 7:07 PM, Rafael Weingärtner <
> > > rafaelweingartner@gmail.com> wrote:
> > >
> > > > Guys,
> > > >
> > > > Khosrow has done a great job here, but we still need to move this
> > forward
> > > > and create a standard/guidelines on how to use the official repo.
> > Looking
> > > > at the list in [1] we can clearly see that things are messy.  This
> is a
> > > > minor discussion, but in my opinion, we should finish it.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > >
> > > > I will propose the following regarding the use of the official
> > > repository.
> > > > I will be waiting for your feedback, and then proceed with a vote.
> > > >
> > > >    1. Only maintain the master and major release branches. We
> currently
> > > >    have a system of X.Y.Z.S. I define major release here as a release
> > > that
> > > >    changes either ((X or Y) or (X and Y));
> > > >    2. We will use tags for versioning. Therefore, all versions we
> > release
> > > >    are tagged accordingly, including minor and security releases;
> > > >    3. When releasing the “SNAPSHOT” is removed and the branch of the
> > > >    version is created (if the version is being cut from master). Rule
> > (1)
> > > > one
> > > >    is applied here; therefore, only major releases will receive
> > branches.
> > > >    Every release must have a tag in the format X.Y.Z.S. After
> > releasing,
> > > we
> > > >    bump the pom of the version to next available SNAPSHOT;
> > > >    4. If there's a need to fix an old version, we work on HEAD of
> > > >    corresponding release branch;
> > > >    5. People should avoid using the official apache repository to
> store
> > > >    working branches. If we want to work together on some issues, we
> can
> > > > set up
> > > >    a fork and give permission to interested parties (the official
> > > > repository
> > > >    is restricted to committers). If one uses the official repository,
> > the
> > > >    branch used must be cleaned right after merging;
> > > >    6. Branches not following these rules will be removed if they have
> > not
> > > >    received attention (commits) for over 6 (six) months.
> > > >
> > > > I think that is all. Do you guys have additions/removals/proposals so
> > we
> > > > can move this forward?
> > > >
> > > > On Mon, Dec 4, 2017 at 7:20 PM, Khosrow Moossavi <
> > kmoossavi@cloudops.com
> > > >
> > > > wrote:
> > > >
> > > > > I agree Erik. I updated the list in CLOUDSTACK-10169 with more
> > > > information
> > > > > (last updated, last commit, HEAD on master and PR status/number)
to
> > > give
> > > > us
> > > > > more immediate visibility of the status of those branches. So any
> > > > branches
> > > > > can
> > > > > be deleted if:
> > > > >
> > > > > - which its HEAD exists on master
> > > > > - its PR was merged or closed (which surprisingly are not so many)
> > > > > - it's old (last updated in 2015 or before?)
> > > > >
> > > > > and the rest of them can be deleted after more examination (if need
> > > be).
> > > > >
> > > > >
> > > > > On Mon, Dec 4, 2017 at 6:37 AM, Rafael Weingärtner <
> > > > > rafaelweingartner@gmail.com> wrote:
> > > > >
> > > > > > I thought someone might bring that up. The problem with using
> > > branches
> > > > in
> > > > > > the official repo is that only committers will be able to commit
> > > there.
> > > > > So,
> > > > > > we would restrict the group of people that might be able to
> > > participate
> > > > > in
> > > > > > this type of cooperation. I do not see the difficulty for a
> > > > > > contributor/committer to give permissions for others in their
own
> > > > > > repository that is a fork from our official one. I have done
that
> > > with
> > > > > some
> > > > > > friends before.
> > > > > >
> > > > > > Also, do not worry Erik; the idea is not to delete anything
right
> > > away.
> > > > > We
> > > > > > are only bringing the topic for a broader discussion here.
> > > > > >
> > > > > > On Mon, Dec 4, 2017 at 8:58 AM, Erik Weber <terbolous@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > > > > > <kmoossavi@cloudops.com> wrote:
> > > > > > > > Hi Community
> > > > > > > >
> > > > > > > > I would like to start the discussion around deleting
old and
> > > > obsolete
> > > > > > > > branches on github repository. This will help newcomers
> > > (including
> > > > > > > myself)
> > > > > > > > to keep track of which branches are important and
which are
> > not.
> > > > And
> > > > > > > since
> > > > > > > > almost everyone's working on their own forks there
is no need
> > to
> > > > keep
> > > > > > > > feature/bugfix/hotfix branches around in the main
official
> > > > > repository.
> > > > > > > >
> > > > > > > > I've created an issue which contains full list of
branches in
> > > > > > > > GH/apache/cloudstack repo as of time of writing this
email
> and
> > > the
> > > > > > > > proposition of which one of them can be deleted.
> > > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > > > > > >
> > > > > > > > I would appreciate your questions, comments, suggestions.
> > > > > > >
> > > > > > > Do note that there might be branches with unmerged changes,
I
> > don't
> > > > > > > think we should just automatically delete those without
> > reflecting
> > > > > > > over its content.
> > > > > > > Although these branch might be stray now, there could be
pieces
> > > there
> > > > > > > that someone else could use at a later point.
> > > > > > >
> > > > > > > As for old feature/fix branches that has been merged, I'm
+1 to
> > > > > > > cleanup up those.
> > > > > > >
> > > > > > > --
> > > > > > > Erik
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rafael Weingärtner
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Rafael Weingärtner
> > > >
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Daan

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