@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 <daan.hoogl...@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 < > > 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 > -- Rafael Weingärtner
