> Op 3 december 2017 om 12:54 schreef Rafael Weingärtner > <rafaelweingart...@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 <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
