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 <kmooss...@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 <daan.hoogl...@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 <daan.hoogl...@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 < > > > rafaelweingart...@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.hoogl...@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 < > > >> > gabrasc...@gmail.com > > >> > > wrote: > > >> > > > >> > > Thanks for the initiative, Khosrow. > > >> > > > > >> > > +1 on removing obsolete branches. > > >> > > > > >> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi < > kmooss...@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
