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 < > rafaelweingart...@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.hoogl...@gmail.com> > > wrote: > > > > > sounds lime a lazy consensus vote; +1 from me > > > > > > On Thu, Dec 14, 2017 at 7:07 PM, Rafael Weingärtner < > > > rafaelweingart...@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 < > > 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 > > > > > > > > > > > > > > > > -- > > > Daan > > > > > > > > > > > -- > > Rafael Weingärtner > > > -- Daan
