You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Khosrow Moossavi <km...@cloudops.com> on 2017/11/30 20:05:36 UTC

Clean up old and obsolete branches

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.

Thanks

Khosrow Moossavi

Cloud Infrastructure Developer

CloudOps

Re: Clean up old and obsolete branches

Posted by Wido den Hollander <wi...@widodh.nl>.
> Op 3 december 2017 om 12:54 schreef Rafael Weingärtner <ra...@gmail.com>:
> 
> 
> I agree with everything Khosrow said.  Additionally, the branches CID can
> be deleted, they are branches referencing problems found/pointed out by
> Coverity scans. These Coverity problems are enumerated as CID-XXXXX.
> https://scan6.coverity.com/reports.htm#v39957/p10672
> 
> I have one extra thing to comment regarding people creating branches in the
> official repository; well, currently there is no rule. However, I do not
> understand why committers cannot work in their own repository and then
> propose the changes via pull requests (this seems to be the natural way for
> proposing something into our code base). For me, it feels sloppy/untidy all
> of those branches and we have no idea what they are used for and if they
> are useful for something; it is the same feeling when I see tons of dead
> code, unused method and dependencies.

I partly agree. With the new SSVM template for Debian 9 Rohit used a branch in the official repository. This allowed me (and other committers) to work on the same branch and add commits while working on it.

That might be a reason why people push branches there.

Wido

> 
> On Fri, Dec 1, 2017 at 2:52 PM, Khosrow Moossavi <km...@cloudops.com>
> wrote:
> 
> > @Daan That's a good point, I'll try to update the list to
> > CLOUDSTACK-<number> wherever applicable. But the majority of branches are
> > 4.1.x to 4.6.x, which might be able to be cleaned up easily.
> >
> > - I feel we might be able to delete everything 4.1.x, 4.2.x, 4.3.x, 4.4.x,
> > 4.5.x, 4.6.x (almost blindly).
> > - the only branches of 4.7.x are the RCs (should be safe to be deleted)
> > - the only branches of 4.8.x are the RCs (should be safe to be deleted)
> > - the only branches of 4.9.x are the RCs and 3 develop branches (should be
> > safe to be deleted)
> > - there are bunch of CID-<number> which I don't know what they are. There
> > are no corresponding CLOUDSTACK tickets for those number. (might be safe to
> > be deleted)
> >
> > @Rafael I agree which this approach. We can have master and release
> > branches with names as "major.minor.micro.x" (e.g. 4.11.0.x) in which their
> > HEAD's pom version always have SNAPSHOT (e.g. 4.11.0.1-SNAPSHOT) and on
> > releasing:
> >
> > - remove the SNAPSHOT from pom
> > - tag it (with full qualified pom version)
> > - bump pom version on the branch to next available SNAPSHOT
> >
> > and if there's a need to fix on older releases, one can either 1) create a
> > branch out of that tag 2) fix on HEAD of corresponding release branch. (I,
> > personally, like the second approach better)
> >
> >
> > Khosrow Moossavi
> >
> > Cloud Infrastructure Developer
> >
> > t 514.447.3456
> >
> > <https://goo.gl/NYZ8KK>
> >
> >
> >
> > On Fri, Dec 1, 2017 at 5:05 AM, Daan Hoogland <da...@gmail.com>
> > wrote:
> >
> > > also I think we can tolerate collective work on our repo. Not everything
> > > has to go on forks.
> > >
> > > On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland <da...@gmail.com>
> > > wrote:
> > >
> > > > Rafael, I don't think that works. the versions in the pom.xml files are
> > > > updated to non snapshot versions on per release mini branches. I like
> > the
> > > > principle but be carefull not to remove the GA branches.
> > > >
> > > > On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> > > > rafaelweingartner@gmail.com> wrote:
> > > >
> > > >> Thanks for the initiative and the hard worki Khosrow!
> > > >>
> > > >> In my opinion, we should only maintain the master and major release
> > > >> branches. Then, for minor versions, we can keep track of them using
> > > tags.
> > > >> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so
> > > forth.
> > > >> Instead, we should keep only the branch 4.4, and the minor versions
> > are
> > > >> built on top of that branch (the branch would always have the top
> > minor
> > > >> version of the major version). The versioning is done using tags, and
> > > not
> > > >> branches. Moreover, people should not use the official apache
> > repository
> > > >> to
> > > >> store working branches. Working branches should be kept at the
> > > developer’s
> > > >> personal repository on Github.
> > > >>
> > > >> To the initial list, I would also remove things such as GA-4.4.1,
> > > >> GA-4.4.2,
> > > >> and so on. As I said, we only need on branch per major release. The
> > > >> versioning is executed through tags, and fixes on past releases should
> > > be
> > > >> done in the branch of the release. Also, there are things like
> > > >> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> > > >> “debian9-systemvmtemplate”; none of them should be there. They are
> > > working
> > > >> branch from contributors/committers. These branches can be at their
> > own
> > > >> personal forks.
> > > >>
> > > >> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <
> > daan.hoogland@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > thanks for that list Khosrow,  Also very usefull for cleaning people
> > > to
> > > >> > clean their own fork.
> > > >> > I think you can start with the lowest pom versions but I changed one
> > > >> > because the referred ticket isn't closed. It's my own and I'll have
> > a
> > > >> look
> > > >> > later today. For a lot of the branches the ticket aren't clear
> > because
> > > >> only
> > > >> > <the number> or CS-<the number> is in the titel. Only when
> > > >> CLOUDSTACK-<the
> > > >> > number> is in the titel you can see immediately that it is closed by
> > > the
> > > >> > automatic strikethrough that happens. just a heads-up.
> > > >> >
> > > >> > +1
> > > >> >
> > > >> >
> > > >> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> > > >> > gabrascher@gmail.com
> > > >> > > wrote:
> > > >> >
> > > >> > > Thanks for the initiative, Khosrow.
> > > >> > >
> > > >> > > +1 on removing obsolete branches.
> > > >> > >
> > > >> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <
> > kmoossavi@cloudops.com
> > > >:
> > > >> > >
> > > >> > > > 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.
> > > >> > > >
> > > >> > > > Thanks
> > > >> > > >
> > > >> > > > Khosrow Moossavi
> > > >> > > >
> > > >> > > > Cloud Infrastructure Developer
> > > >> > > >
> > > >> > > > CloudOps
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Daan
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Rafael Weingärtner
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Daan
> > > >
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> 
> 
> 
> -- 
> Rafael Weingärtner

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
I agree with everything Khosrow said.  Additionally, the branches CID can
be deleted, they are branches referencing problems found/pointed out by
Coverity scans. These Coverity problems are enumerated as CID-XXXXX.
https://scan6.coverity.com/reports.htm#v39957/p10672

I have one extra thing to comment regarding people creating branches in the
official repository; well, currently there is no rule. However, I do not
understand why committers cannot work in their own repository and then
propose the changes via pull requests (this seems to be the natural way for
proposing something into our code base). For me, it feels sloppy/untidy all
of those branches and we have no idea what they are used for and if they
are useful for something; it is the same feeling when I see tons of dead
code, unused method and dependencies.

On Fri, Dec 1, 2017 at 2:52 PM, Khosrow Moossavi <km...@cloudops.com>
wrote:

> @Daan That's a good point, I'll try to update the list to
> CLOUDSTACK-<number> wherever applicable. But the majority of branches are
> 4.1.x to 4.6.x, which might be able to be cleaned up easily.
>
> - I feel we might be able to delete everything 4.1.x, 4.2.x, 4.3.x, 4.4.x,
> 4.5.x, 4.6.x (almost blindly).
> - the only branches of 4.7.x are the RCs (should be safe to be deleted)
> - the only branches of 4.8.x are the RCs (should be safe to be deleted)
> - the only branches of 4.9.x are the RCs and 3 develop branches (should be
> safe to be deleted)
> - there are bunch of CID-<number> which I don't know what they are. There
> are no corresponding CLOUDSTACK tickets for those number. (might be safe to
> be deleted)
>
> @Rafael I agree which this approach. We can have master and release
> branches with names as "major.minor.micro.x" (e.g. 4.11.0.x) in which their
> HEAD's pom version always have SNAPSHOT (e.g. 4.11.0.1-SNAPSHOT) and on
> releasing:
>
> - remove the SNAPSHOT from pom
> - tag it (with full qualified pom version)
> - bump pom version on the branch to next available SNAPSHOT
>
> and if there's a need to fix on older releases, one can either 1) create a
> branch out of that tag 2) fix on HEAD of corresponding release branch. (I,
> personally, like the second approach better)
>
>
> Khosrow Moossavi
>
> Cloud Infrastructure Developer
>
> t 514.447.3456
>
> <https://goo.gl/NYZ8KK>
>
>
>
> On Fri, Dec 1, 2017 at 5:05 AM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > also I think we can tolerate collective work on our repo. Not everything
> > has to go on forks.
> >
> > On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland <da...@gmail.com>
> > wrote:
> >
> > > Rafael, I don't think that works. the versions in the pom.xml files are
> > > updated to non snapshot versions on per release mini branches. I like
> the
> > > principle but be carefull not to remove the GA branches.
> > >
> > > On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> > > rafaelweingartner@gmail.com> wrote:
> > >
> > >> Thanks for the initiative and the hard worki Khosrow!
> > >>
> > >> In my opinion, we should only maintain the master and major release
> > >> branches. Then, for minor versions, we can keep track of them using
> > tags.
> > >> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so
> > forth.
> > >> Instead, we should keep only the branch 4.4, and the minor versions
> are
> > >> built on top of that branch (the branch would always have the top
> minor
> > >> version of the major version). The versioning is done using tags, and
> > not
> > >> branches. Moreover, people should not use the official apache
> repository
> > >> to
> > >> store working branches. Working branches should be kept at the
> > developer’s
> > >> personal repository on Github.
> > >>
> > >> To the initial list, I would also remove things such as GA-4.4.1,
> > >> GA-4.4.2,
> > >> and so on. As I said, we only need on branch per major release. The
> > >> versioning is executed through tags, and fixes on past releases should
> > be
> > >> done in the branch of the release. Also, there are things like
> > >> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> > >> “debian9-systemvmtemplate”; none of them should be there. They are
> > working
> > >> branch from contributors/committers. These branches can be at their
> own
> > >> personal forks.
> > >>
> > >> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <
> daan.hoogland@gmail.com>
> > >> wrote:
> > >>
> > >> > thanks for that list Khosrow,  Also very usefull for cleaning people
> > to
> > >> > clean their own fork.
> > >> > I think you can start with the lowest pom versions but I changed one
> > >> > because the referred ticket isn't closed. It's my own and I'll have
> a
> > >> look
> > >> > later today. For a lot of the branches the ticket aren't clear
> because
> > >> only
> > >> > <the number> or CS-<the number> is in the titel. Only when
> > >> CLOUDSTACK-<the
> > >> > number> is in the titel you can see immediately that it is closed by
> > the
> > >> > automatic strikethrough that happens. just a heads-up.
> > >> >
> > >> > +1
> > >> >
> > >> >
> > >> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> > >> > gabrascher@gmail.com
> > >> > > wrote:
> > >> >
> > >> > > Thanks for the initiative, Khosrow.
> > >> > >
> > >> > > +1 on removing obsolete branches.
> > >> > >
> > >> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <
> kmoossavi@cloudops.com
> > >:
> > >> > >
> > >> > > > 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.
> > >> > > >
> > >> > > > Thanks
> > >> > > >
> > >> > > > Khosrow Moossavi
> > >> > > >
> > >> > > > Cloud Infrastructure Developer
> > >> > > >
> > >> > > > CloudOps
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Daan
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Rafael Weingärtner
> > >>
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Rafael Weingärtner

Re: Clean up old and obsolete branches

Posted by Khosrow Moossavi <km...@cloudops.com>.
@Daan That's a good point, I'll try to update the list to
CLOUDSTACK-<number> wherever applicable. But the majority of branches are
4.1.x to 4.6.x, which might be able to be cleaned up easily.

- I feel we might be able to delete everything 4.1.x, 4.2.x, 4.3.x, 4.4.x,
4.5.x, 4.6.x (almost blindly).
- the only branches of 4.7.x are the RCs (should be safe to be deleted)
- the only branches of 4.8.x are the RCs (should be safe to be deleted)
- the only branches of 4.9.x are the RCs and 3 develop branches (should be
safe to be deleted)
- there are bunch of CID-<number> which I don't know what they are. There
are no corresponding CLOUDSTACK tickets for those number. (might be safe to
be deleted)

@Rafael I agree which this approach. We can have master and release
branches with names as "major.minor.micro.x" (e.g. 4.11.0.x) in which their
HEAD's pom version always have SNAPSHOT (e.g. 4.11.0.1-SNAPSHOT) and on
releasing:

- remove the SNAPSHOT from pom
- tag it (with full qualified pom version)
- bump pom version on the branch to next available SNAPSHOT

and if there's a need to fix on older releases, one can either 1) create a
branch out of that tag 2) fix on HEAD of corresponding release branch. (I,
personally, like the second approach better)


Khosrow Moossavi

Cloud Infrastructure Developer

t 514.447.3456

<https://goo.gl/NYZ8KK>



On Fri, Dec 1, 2017 at 5:05 AM, Daan Hoogland <da...@gmail.com>
wrote:

> also I think we can tolerate collective work on our repo. Not everything
> has to go on forks.
>
> On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > Rafael, I don't think that works. the versions in the pom.xml files are
> > updated to non snapshot versions on per release mini branches. I like the
> > principle but be carefull not to remove the GA branches.
> >
> > On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> > rafaelweingartner@gmail.com> wrote:
> >
> >> Thanks for the initiative and the hard worki Khosrow!
> >>
> >> In my opinion, we should only maintain the master and major release
> >> branches. Then, for minor versions, we can keep track of them using
> tags.
> >> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so
> forth.
> >> Instead, we should keep only the branch 4.4, and the minor versions are
> >> built on top of that branch (the branch would always have the top minor
> >> version of the major version). The versioning is done using tags, and
> not
> >> branches. Moreover, people should not use the official apache repository
> >> to
> >> store working branches. Working branches should be kept at the
> developer’s
> >> personal repository on Github.
> >>
> >> To the initial list, I would also remove things such as GA-4.4.1,
> >> GA-4.4.2,
> >> and so on. As I said, we only need on branch per major release. The
> >> versioning is executed through tags, and fixes on past releases should
> be
> >> done in the branch of the release. Also, there are things like
> >> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> >> “debian9-systemvmtemplate”; none of them should be there. They are
> working
> >> branch from contributors/committers. These branches can be at their own
> >> personal forks.
> >>
> >> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <da...@gmail.com>
> >> wrote:
> >>
> >> > thanks for that list Khosrow,  Also very usefull for cleaning people
> to
> >> > clean their own fork.
> >> > I think you can start with the lowest pom versions but I changed one
> >> > because the referred ticket isn't closed. It's my own and I'll have a
> >> look
> >> > later today. For a lot of the branches the ticket aren't clear because
> >> only
> >> > <the number> or CS-<the number> is in the titel. Only when
> >> CLOUDSTACK-<the
> >> > number> is in the titel you can see immediately that it is closed by
> the
> >> > automatic strikethrough that happens. just a heads-up.
> >> >
> >> > +1
> >> >
> >> >
> >> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> >> > gabrascher@gmail.com
> >> > > wrote:
> >> >
> >> > > Thanks for the initiative, Khosrow.
> >> > >
> >> > > +1 on removing obsolete branches.
> >> > >
> >> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <kmoossavi@cloudops.com
> >:
> >> > >
> >> > > > 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.
> >> > > >
> >> > > > Thanks
> >> > > >
> >> > > > Khosrow Moossavi
> >> > > >
> >> > > > Cloud Infrastructure Developer
> >> > > >
> >> > > > CloudOps
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Daan
> >> >
> >>
> >>
> >>
> >> --
> >> Rafael Weingärtner
> >>
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Daan
>

Re: Clean up old and obsolete branches

Posted by Daan Hoogland <da...@gmail.com>.
also I think we can tolerate collective work on our repo. Not everything
has to go on forks.

On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland <da...@gmail.com>
wrote:

> Rafael, I don't think that works. the versions in the pom.xml files are
> updated to non snapshot versions on per release mini branches. I like the
> principle but be carefull not to remove the GA branches.
>
> On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
>> Thanks for the initiative and the hard worki Khosrow!
>>
>> In my opinion, we should only maintain the master and major release
>> branches. Then, for minor versions, we can keep track of them using tags.
>> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
>> Instead, we should keep only the branch 4.4, and the minor versions are
>> built on top of that branch (the branch would always have the top minor
>> version of the major version). The versioning is done using tags, and not
>> branches. Moreover, people should not use the official apache repository
>> to
>> store working branches. Working branches should be kept at the developer’s
>> personal repository on Github.
>>
>> To the initial list, I would also remove things such as GA-4.4.1,
>> GA-4.4.2,
>> and so on. As I said, we only need on branch per major release. The
>> versioning is executed through tags, and fixes on past releases should be
>> done in the branch of the release. Also, there are things like
>> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
>> “debian9-systemvmtemplate”; none of them should be there. They are working
>> branch from contributors/committers. These branches can be at their own
>> personal forks.
>>
>> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>
>> > thanks for that list Khosrow,  Also very usefull for cleaning people to
>> > clean their own fork.
>> > I think you can start with the lowest pom versions but I changed one
>> > because the referred ticket isn't closed. It's my own and I'll have a
>> look
>> > later today. For a lot of the branches the ticket aren't clear because
>> only
>> > <the number> or CS-<the number> is in the titel. Only when
>> CLOUDSTACK-<the
>> > number> is in the titel you can see immediately that it is closed by the
>> > automatic strikethrough that happens. just a heads-up.
>> >
>> > +1
>> >
>> >
>> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
>> > gabrascher@gmail.com
>> > > wrote:
>> >
>> > > Thanks for the initiative, Khosrow.
>> > >
>> > > +1 on removing obsolete branches.
>> > >
>> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <km...@cloudops.com>:
>> > >
>> > > > 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.
>> > > >
>> > > > Thanks
>> > > >
>> > > > Khosrow Moossavi
>> > > >
>> > > > Cloud Infrastructure Developer
>> > > >
>> > > > CloudOps
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: Clean up old and obsolete branches

Posted by Daan Hoogland <da...@gmail.com>.
Rafael, I don't think that works. the versions in the pom.xml files are
updated to non snapshot versions on per release mini branches. I like the
principle but be carefull not to remove the GA branches.

On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:

> Thanks for the initiative and the hard worki Khosrow!
>
> In my opinion, we should only maintain the master and major release
> branches. Then, for minor versions, we can keep track of them using tags.
> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
> Instead, we should keep only the branch 4.4, and the minor versions are
> built on top of that branch (the branch would always have the top minor
> version of the major version). The versioning is done using tags, and not
> branches. Moreover, people should not use the official apache repository to
> store working branches. Working branches should be kept at the developer’s
> personal repository on Github.
>
> To the initial list, I would also remove things such as GA-4.4.1, GA-4.4.2,
> and so on. As I said, we only need on branch per major release. The
> versioning is executed through tags, and fixes on past releases should be
> done in the branch of the release. Also, there are things like
> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> “debian9-systemvmtemplate”; none of them should be there. They are working
> branch from contributors/committers. These branches can be at their own
> personal forks.
>
> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > thanks for that list Khosrow,  Also very usefull for cleaning people to
> > clean their own fork.
> > I think you can start with the lowest pom versions but I changed one
> > because the referred ticket isn't closed. It's my own and I'll have a
> look
> > later today. For a lot of the branches the ticket aren't clear because
> only
> > <the number> or CS-<the number> is in the titel. Only when
> CLOUDSTACK-<the
> > number> is in the titel you can see immediately that it is closed by the
> > automatic strikethrough that happens. just a heads-up.
> >
> > +1
> >
> >
> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> > gabrascher@gmail.com
> > > wrote:
> >
> > > Thanks for the initiative, Khosrow.
> > >
> > > +1 on removing obsolete branches.
> > >
> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <km...@cloudops.com>:
> > >
> > > > 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.
> > > >
> > > > Thanks
> > > >
> > > > Khosrow Moossavi
> > > >
> > > > Cloud Infrastructure Developer
> > > >
> > > > CloudOps
> > > >
> > >
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
Thanks for the initiative and the hard worki Khosrow!

In my opinion, we should only maintain the master and major release
branches. Then, for minor versions, we can keep track of them using tags.
There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
Instead, we should keep only the branch 4.4, and the minor versions are
built on top of that branch (the branch would always have the top minor
version of the major version). The versioning is done using tags, and not
branches. Moreover, people should not use the official apache repository to
store working branches. Working branches should be kept at the developer’s
personal repository on Github.

To the initial list, I would also remove things such as GA-4.4.1, GA-4.4.2,
and so on. As I said, we only need on branch per major release. The
versioning is executed through tags, and fixes on past releases should be
done in the branch of the release. Also, there are things like
“add_XS_71_72”, “cloudearlyinit”, “new-location”, and
“debian9-systemvmtemplate”; none of them should be there. They are working
branch from contributors/committers. These branches can be at their own
personal forks.

On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <da...@gmail.com>
wrote:

> thanks for that list Khosrow,  Also very usefull for cleaning people to
> clean their own fork.
> I think you can start with the lowest pom versions but I changed one
> because the referred ticket isn't closed. It's my own and I'll have a look
> later today. For a lot of the branches the ticket aren't clear because only
> <the number> or CS-<the number> is in the titel. Only when CLOUDSTACK-<the
> number> is in the titel you can see immediately that it is closed by the
> automatic strikethrough that happens. just a heads-up.
>
> +1
>
>
> On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> gabrascher@gmail.com
> > wrote:
>
> > Thanks for the initiative, Khosrow.
> >
> > +1 on removing obsolete branches.
> >
> > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <km...@cloudops.com>:
> >
> > > 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.
> > >
> > > Thanks
> > >
> > > Khosrow Moossavi
> > >
> > > Cloud Infrastructure Developer
> > >
> > > CloudOps
> > >
> >
>
>
>
> --
> Daan
>



-- 
Rafael Weingärtner

Re: Clean up old and obsolete branches

Posted by Daan Hoogland <da...@gmail.com>.
thanks for that list Khosrow,  Also very usefull for cleaning people to
clean their own fork.
I think you can start with the lowest pom versions but I changed one
because the referred ticket isn't closed. It's my own and I'll have a look
later today. For a lot of the branches the ticket aren't clear because only
<the number> or CS-<the number> is in the titel. Only when CLOUDSTACK-<the
number> is in the titel you can see immediately that it is closed by the
automatic strikethrough that happens. just a heads-up.

+1


On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <gabrascher@gmail.com
> wrote:

> Thanks for the initiative, Khosrow.
>
> +1 on removing obsolete branches.
>
> 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <km...@cloudops.com>:
>
> > 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.
> >
> > Thanks
> >
> > Khosrow Moossavi
> >
> > Cloud Infrastructure Developer
> >
> > CloudOps
> >
>



-- 
Daan

Re: Clean up old and obsolete branches

Posted by Gabriel Beims Bräscher <ga...@gmail.com>.
Thanks for the initiative, Khosrow.

+1 on removing obsolete branches.

2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <km...@cloudops.com>:

> 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.
>
> Thanks
>
> Khosrow Moossavi
>
> Cloud Infrastructure Developer
>
> CloudOps
>

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
@Marc, I like this idea. However, some folks believe it might be useful to
use the official repo to work in groups (group of committers). I did not
want to push this without a broader discussion; that is why I am proposing
that people can use the official repository, as long as they remove the
branch after the merge. If they do not remove the branch right after
merging, according to the set of rules I wrote, we would be able to remove
it sic (6) months after the work is done (after following the other
procedures to remove a branch). Therefore, we do not have the risk of
someone deleting things that should not be deleted.

@Daan, that is the idea. A protocol is good to make the rules clear to
everybody; and as we state there, one cannot delete branches right away.
There are certain criteria that have to be met, and notice has to be given
on the dev mailing list.

On Mon, Dec 18, 2017 at 11:39 AM, Daan Hoogland <da...@gmail.com>
wrote:

> 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 <ma...@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
> > > > > > > > <km...@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
>



-- 
Rafael Weingärtner

Re: Clean up old and obsolete branches

Posted by Daan Hoogland <da...@gmail.com>.
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 <ma...@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 <da...@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 <te...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > > > > > <km...@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

Re: Clean up old and obsolete branches

Posted by Marc-Aurèle Brothier <ma...@exoscale.ch>.
+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 <da...@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 <te...@gmail.com>
> > > wrote:
> > > > >
> > > > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > > > > <km...@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
>

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <da...@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 <te...@gmail.com>
> > wrote:
> > > >
> > > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > > > <km...@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

Re: Clean up old and obsolete branches

Posted by Daan Hoogland <da...@gmail.com>.
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 <km...@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 <te...@gmail.com>
> wrote:
> > >
> > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > > <km...@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

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <km...@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 <te...@gmail.com> wrote:
> >
> > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > <km...@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

Re: Clean up old and obsolete branches

Posted by Khosrow Moossavi <km...@cloudops.com>.
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 <te...@gmail.com> wrote:
>
> > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > <km...@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
>

Re: Clean up old and obsolete branches

Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <te...@gmail.com> wrote:

> On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> <km...@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

Re: Clean up old and obsolete branches

Posted by Erik Weber <te...@gmail.com>.
On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
<km...@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