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 <kmooss...@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 < > rafaelweingart...@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 <terbol...@gmail.com> wrote: > > > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi > > > <kmooss...@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
