Re: Changes to branch management
On Tue, Dec 30, 2014 at 6:08 AM, Jan Kundrát wrote: > On Monday, 29 December 2014 09:50:06 CEST, Ben Cooksley wrote: >> >> Unfortunately allowing force pushes is an extremely messy business >> with the hooks - so we're unable to do this (for maintenance reasons >> among others). > > > Could you please elaborate on this one? > > The only reason I remember ever hearing was "it will send all notification > e-mails again when you force-push". Why would that be a problem? Would > disabling e.g. the CCMAIL, BUG and CCBUG keywords (or the all of the > notification hooks) in all branches that support force pushes be a > reasonable fix? Two reasons: 1) The notification hooks, as you mention above. Disabling them for branches which permit force pushes would be a workaround for that, but then we have more complexity in the hooks to look after. 2) The social problems that come with the lack of notifications. Community code review via email is broken without them, and force pushes require people to take action if they have interacted with such a branch in the past. Plus it means we'll have a 3 tier hierarchy of branches in our mainline repos - "personal" branches one can force push, "work" branches which are shared and the primary release branches. Seems like it might be a bit complex. > > With kind regards, > Jan Thanks, Ben > > > -- > Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to branch management
On Monday, 29 December 2014 09:50:06 CEST, Ben Cooksley wrote: Unfortunately allowing force pushes is an extremely messy business with the hooks - so we're unable to do this (for maintenance reasons among others). Could you please elaborate on this one? The only reason I remember ever hearing was "it will send all notification e-mails again when you force-push". Why would that be a problem? Would disabling e.g. the CCMAIL, BUG and CCBUG keywords (or the all of the notification hooks) in all branches that support force pushes be a reasonable fix? With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to branch management
On Sat, Dec 27, 2014 at 9:09 AM, Matthew Dawson wrote: > On December 25, 2014 08:21:05 PM Ben Cooksley wrote: >> > The way I see it, there are two reasonable alternatives with the current >> > setup: >> > >> > 1) Everybody can create, delete and force-push to all branches except the >> > "reserved" ones (kde/*, master, stable,... see the list). >> > >> > 2) People are free to create, delete and force-push to all branches below >> > my/$username/ (in my case, tat would be my/jkt/foo for example). Only repo >> > owners can create, delete and force-push to arbitrary branch names. >> >> In essence, yes - those are the two possible options we have. >> Force pushing will *still* be prohibited under this proposal as it >> stands (and would be a CoC violation if done). >> >> > Deciding which of these to use should be just a matter of style. Both seem >> > very sensible to me, and they will definitely present an improvement over >> > the current status where people can create, but not cleanup afterwards. >> >> Agreed. Can we have a show of hands / etc as to which one would suit >> people best? >> >> I will add a 3rd possibility though. >> >> 3) People are free to create and delete to all branches below work/*. >> Creation and deletion of branches outside this would be limited to >> project admins (release managers). It also allows other developers to >> cleanup as needed so it doesn't all fall on the repository admin / >> sysadmin. > I think a combination of 2 + 3 are best. 3 is the best for doing > collaborative work, where force pushes are not welcome. As Thomas says, its > simple and keeps most important branches protected. > > However, I think 2 should be included, if and only if a developer gains the > ability to force push into their personal branches. When working , a > developer may want to revise the history as development progress, but before > moving it into a collaborative zone. This makes it easy for developers to > work closer to the main repository without pushing the code elsewhere, > allowing other developers to quickly see how something is progressing. > > If force pushes are something that KDE does not want to allow, then I think > doing just 3 is best. I had thought they were disallowed to prevent people > doing bad things on important branches. I think for branches specifically > listed as personal branches, allowing force pushes would be OK with the CoC, > as developers can continue to monitor progress on a given branch. > -- > Matthew Thanks everyone for the feedback. Support for proposal #3 seems fairly universal from what I can see - so we'll go ahead and implement that. Unfortunately allowing force pushes is an extremely messy business with the hooks - so we're unable to do this (for maintenance reasons among others). Thanks, Ben
Re: Changes to branch management
On December 25, 2014 08:21:05 PM Ben Cooksley wrote: > > The way I see it, there are two reasonable alternatives with the current > > setup: > > > > 1) Everybody can create, delete and force-push to all branches except the > > "reserved" ones (kde/*, master, stable,... see the list). > > > > 2) People are free to create, delete and force-push to all branches below > > my/$username/ (in my case, tat would be my/jkt/foo for example). Only repo > > owners can create, delete and force-push to arbitrary branch names. > > In essence, yes - those are the two possible options we have. > Force pushing will *still* be prohibited under this proposal as it > stands (and would be a CoC violation if done). > > > Deciding which of these to use should be just a matter of style. Both seem > > very sensible to me, and they will definitely present an improvement over > > the current status where people can create, but not cleanup afterwards. > > Agreed. Can we have a show of hands / etc as to which one would suit > people best? > > I will add a 3rd possibility though. > > 3) People are free to create and delete to all branches below work/*. > Creation and deletion of branches outside this would be limited to > project admins (release managers). It also allows other developers to > cleanup as needed so it doesn't all fall on the repository admin / > sysadmin. I think a combination of 2 + 3 are best. 3 is the best for doing collaborative work, where force pushes are not welcome. As Thomas says, its simple and keeps most important branches protected. However, I think 2 should be included, if and only if a developer gains the ability to force push into their personal branches. When working , a developer may want to revise the history as development progress, but before moving it into a collaborative zone. This makes it easy for developers to work closer to the main repository without pushing the code elsewhere, allowing other developers to quickly see how something is progressing. If force pushes are something that KDE does not want to allow, then I think doing just 3 is best. I had thought they were disallowed to prevent people doing bad things on important branches. I think for branches specifically listed as personal branches, allowing force pushes would be OK with the CoC, as developers can continue to monitor progress on a given branch. -- Matthew signature.asc Description: This is a digitally signed message part.
Re: Changes to branch management
On Thursday 25 December 2014 20:29:12 Thomas Friedrichsmeier wrote: > On Thu, 25 Dec 2014 20:21:05 +1300 > Ben Cooksley wrote: > > 3) People are free to create and delete to all branches below work/*. > > Creation and deletion of branches outside this would be limited to > > project admins (release managers). It also allows other developers to > > cleanup as needed so it doesn't all fall on the repository admin / > > sysadmin. > > > > This removes developer usernames from the branch names - which is > > probably better for long term collaborative branches (which i've seen > > used in a number of projects) and doesn't make a difference for short > > term branches. > > I like 3 best. > > This seems like a very straight-forward solution that offers the current > level of protection for all existing branches, while allowing a lot of > flexibility in managing non-protected branches (including, importantly, > the possibility to organize by feature / purpose rather than by > "owner"). +1
Re: Changes to branch management
El Dijous, 25 de desembre de 2014, a les 20:29:12, Thomas Friedrichsmeier va escriure: > On Thu, 25 Dec 2014 20:21:05 +1300 > Ben Cooksley wrote: > [...] > > > > 1) Everybody can create, delete and force-push to all branches > > > except the "reserved" ones (kde/*, master, stable,... see the list). > > > > > > 2) People are free to create, delete and force-push to all branches > > > below my/$username/ (in my case, tat would be my/jkt/foo for > > > example). Only repo owners can create, delete and force-push to > > > arbitrary branch names. > > [...] > > > Agreed. Can we have a show of hands / etc as to which one would suit > > people best? > > > > I will add a 3rd possibility though. > > > > 3) People are free to create and delete to all branches below work/*. > > Creation and deletion of branches outside this would be limited to > > project admins (release managers). It also allows other developers to > > cleanup as needed so it doesn't all fall on the repository admin / > > sysadmin. > > > > This removes developer usernames from the branch names - which is > > probably better for long term collaborative branches (which i've seen > > used in a number of projects) and doesn't make a difference for short > > term branches. > > I like 3 best. > > This seems like a very straight-forward solution that offers the current > level of protection for all existing branches, while allowing a lot of > flexibility in managing non-protected branches (including, importantly, > the possibility to organize by feature / purpose rather than by > "owner"). +1 Cheers, Albert > > Regards > Thomas signature.asc Description: This is a digitally signed message part.
Re: Changes to branch management
On Thu, 25 Dec 2014 20:21:05 +1300 Ben Cooksley wrote: [...] > > 1) Everybody can create, delete and force-push to all branches > > except the "reserved" ones (kde/*, master, stable,... see the list). > > > > 2) People are free to create, delete and force-push to all branches > > below my/$username/ (in my case, tat would be my/jkt/foo for > > example). Only repo owners can create, delete and force-push to > > arbitrary branch names. [...] > Agreed. Can we have a show of hands / etc as to which one would suit > people best? > > I will add a 3rd possibility though. > > 3) People are free to create and delete to all branches below work/*. > Creation and deletion of branches outside this would be limited to > project admins (release managers). It also allows other developers to > cleanup as needed so it doesn't all fall on the repository admin / > sysadmin. > > This removes developer usernames from the branch names - which is > probably better for long term collaborative branches (which i've seen > used in a number of projects) and doesn't make a difference for short > term branches. I like 3 best. This seems like a very straight-forward solution that offers the current level of protection for all existing branches, while allowing a lot of flexibility in managing non-protected branches (including, importantly, the possibility to organize by feature / purpose rather than by "owner"). Regards Thomas signature.asc Description: PGP signature
Re: Changes to branch management
On Thursday, 25 December 2014 08:21:05 CEST, Ben Cooksley wrote: In essence, yes - those are the two possible options we have. Force pushing will *still* be prohibited under this proposal as it stands (and would be a CoC violation if done). Hi Ben, this is a very strong statement. I'm believe that you have a good reason for making it, but I do not understand what that reason is. I think that one of the reasons you strongly dislike force pushes are limitations of the current hook setup. That's a relevant technical point, but IMHO it isn't something which would qualify a force push to be a CoC violation. The CoC is a generic document which doesn't even talk about the concept of SCM. Maybe I have my knee-jerk reaction when people call something they consider an evil thing a "CoC violation", but I just about totally disagree when I read such a statement. I would hate to see this subthread getting derailed into a lnguage lawyering of what's in the CoC and what isn't there, so I'll stop here by saying that I don't agree with that particular conclusion. The reason why I think that a force push sometimes makes sense is experience with Trojita. There's a couple of long-forgotten WIP branches which only differ by some of them being already squashed into more manageable form or rebased on a more recent master. The current state leads to branches like "foo", "foo-2" etc (I think we're at foo-5 with Trojita now). What alternative to force pushes would you recommend? Should we stick with the foo-number scheme? Why is that good? With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to branch management
On Wed, Dec 24, 2014 at 12:56 AM, Christian Mollekopf wrote: > On Wednesday 24 December 2014 00.04:22 Ben Cooksley wrote: >> Hi all, >> >> As the other thread has gotten a bit congested with various threads, I >> thought I would split up the topics to make things a bit easier to >> manage. >> >> The first seems the least contentious: allowing all developers to >> delete branches on our mainline repositories, except for certain >> protected branches (like "master" and "KDE/*" for instance). >> >> Any suggestions or variations on this? >> > > This would be a great improvement indeed. > > I assume this would also work on scratch repositories? > Since one person has to "own" a scratch repository, I think other people > should still be able to delete branches in that repository. The way our templating system works at the moment means we would need to make a separate adjustment for them as they are declared separately. At the moment, normal developers only have the power to push to existing branches on others scratch repositories. > > Cheers, > Christian > Thanks, Ben
Re: Changes to branch management
On Wednesday 24 December 2014 00.04:22 Ben Cooksley wrote: > Hi all, > > As the other thread has gotten a bit congested with various threads, I > thought I would split up the topics to make things a bit easier to > manage. > > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). > > Any suggestions or variations on this? > This would be a great improvement indeed. I assume this would also work on scratch repositories? Since one person has to "own" a scratch repository, I think other people should still be able to delete branches in that repository. Cheers, Christian
Re: Changes to branch management
On Thu, Dec 25, 2014 at 5:04 AM, Jan Kundrát wrote: > On Wednesday, 24 December 2014 01:57:15 CEST, Ben Cooksley wrote: >> >> Unfortunately i'm not sure if Gitolite's ACL mechanisms let us >> differentiate between tags and branches so if we allow anyone to >> delete branches they'll probably be able to do the same for tags. > > > Are the generated config files or the scripts for generating gitolite's > config files available somewhere? The Gitolite setup I'm familiar with uses > explicit qualifiers such as "refs/heads/" and "refs/tags/" when setting up > ACLs. Do you use something different on git.k.o? If not, then managing tags > separately from branches should come for free. The generated files themselves are only available in the private gitolite-admin repository. You can find the "script" which is a Redmine/Chiliproject plugin in my scratch space on git.kde.org. Our config file template goes something like this though: repo RWCD = RW [0-9](.+) = @all -[0-9](.+) = @all RW KDE/(.+) = @all -KDE/(.+) = @all RWC = @all Changing it to use explicit syntax shouldn't cause any major breakages though - but considering that the release managers are not always repository admins I would be reluctant to restrict the management of tags to repo admins only. > > The way I see it, there are two reasonable alternatives with the current > setup: > > 1) Everybody can create, delete and force-push to all branches except the > "reserved" ones (kde/*, master, stable,... see the list). > > 2) People are free to create, delete and force-push to all branches below > my/$username/ (in my case, tat would be my/jkt/foo for example). Only repo > owners can create, delete and force-push to arbitrary branch names. In essence, yes - those are the two possible options we have. Force pushing will *still* be prohibited under this proposal as it stands (and would be a CoC violation if done). > > Deciding which of these to use should be just a matter of style. Both seem > very sensible to me, and they will definitely present an improvement over > the current status where people can create, but not cleanup afterwards. Agreed. Can we have a show of hands / etc as to which one would suit people best? I will add a 3rd possibility though. 3) People are free to create and delete to all branches below work/*. Creation and deletion of branches outside this would be limited to project admins (release managers). It also allows other developers to cleanup as needed so it doesn't all fall on the repository admin / sysadmin. This removes developer usernames from the branch names - which is probably better for long term collaborative branches (which i've seen used in a number of projects) and doesn't make a difference for short term branches. > > With kind regards, > > Jan Thanks, Ben > > -- > Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to branch management
On Wednesday, 24 December 2014 01:57:15 CEST, Ben Cooksley wrote: Unfortunately i'm not sure if Gitolite's ACL mechanisms let us differentiate between tags and branches so if we allow anyone to delete branches they'll probably be able to do the same for tags. Are the generated config files or the scripts for generating gitolite's config files available somewhere? The Gitolite setup I'm familiar with uses explicit qualifiers such as "refs/heads/" and "refs/tags/" when setting up ACLs. Do you use something different on git.k.o? If not, then managing tags separately from branches should come for free. The way I see it, there are two reasonable alternatives with the current setup: 1) Everybody can create, delete and force-push to all branches except the "reserved" ones (kde/*, master, stable,... see the list). 2) People are free to create, delete and force-push to all branches below my/$username/ (in my case, tat would be my/jkt/foo for example). Only repo owners can create, delete and force-push to arbitrary branch names. Deciding which of these to use should be just a matter of style. Both seem very sensible to me, and they will definitely present an improvement over the current status where people can create, but not cleanup afterwards. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Changes to branch management
Hi! On Wed, 24 Dec 2014 14:11:46 +1300 Ben Cooksley wrote: > That brings the list of protected branches requested thus far to: > > master > frameworks > KDE/* > Applications/* > Plasma/* > Calligra/* > > Any others? Extragear apps may have different names for release series branches. For RKWard, we currently have releases/*. That said, I think the risk of someone deleting these branches seems quite tolerable, given that there are backup refs. No need to add protection rules for these as far as I am concerned. However, just to bring in yet another idea, a different approach would be whitelisting certain branch names for deletion, e.g. devel/* (static prefix(es) as opposed to user-name prefix as suggested by others). Regards Thomas signature.asc Description: PGP signature
Re: Changes to branch management
El Dimecres, 24 de desembre de 2014, a les 10:48:43, Kevin Ottens va escriure: > On Wednesday 24 December 2014 13:57:15 Ben Cooksley wrote: > > Unfortunately i'm not sure if Gitolite's ACL mechanisms let us > > differentiate between tags and branches so if we allow anyone to > > delete branches they'll probably be able to do the same for tags. > > Then it's definitely something to pay attention to. I don't think we're as > well structured for tags than we are for branches accross the board. > Especially for tagging releases I don't think we have a consistent naming > scheme. For "old KDE SC", Plasma, Frameworks and Applications we're using v$VersionNumber I know that's not *everything* but covers quite a nice percentage. Cheers, Albert > > Cheers. signature.asc Description: This is a digitally signed message part.
Re: Changes to branch management
El Dimecres, 24 de desembre de 2014, a les 14:05:54, Ben Cooksley va escriure: > On Wed, Dec 24, 2014 at 5:35 AM, Sebastian Kügler wrote: > > On Tuesday, December 23, 2014 06:27:01 Albert Astals Cid wrote: > >> El Dimarts, 23 de desembre de 2014, a les 14:48:21, Sebastian Kügler va > >> > >> escriure: > >> > On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > >> > > The first seems the least contentious: allowing all developers to > >> > > delete branches on our mainline repositories, except for certain > >> > > protected branches (like "master" and "KDE/*" for instance). > >> > > >> > I'd add "frameworks" to that, it has a status very similar to "master" > >> > for > >> > many projects. > >> > >> Has it? As far as i understand frameworks is "just" a work branch that > >> will > >> eventually merged into "master" when it's done. > > > > IMO, yes. It's a branch shared across many people and often being the base > > for yet another branch, so the annoyance of someone doing a force-push > > there would be quite high. > > The abuse of such branch deletion powers to achieve a "force push" > would be considered a severe violation of the Code of Conduct as far > as i'm concerned. > That is regardless of whether the branch affected is a personal or > mainline branch. > > > I'm in favor of only relaxing the permissions for "personal" branches > > (i.e. > > branches that you've created yourself (in Plasma, we're using > > username/branchname quite consistently, so just matching for "starts with > > $username" would work well enough for me). > > It would be incredibly expensive to record who created a branch to > implement such an ACL. > While personal branches are supported, the scheme you use at the > moment isn't unfortunately. We don't say record who created it, "just" do a plain text comparison of the branch name against the user name. Cheers, Albert > > See http://gitolite.com/gitolite/gitolite.html#pers for more information. > > > Cheers, > > -- > > sebas > > > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > > Thanks, > Ben
Re: Changes to branch management
On Wednesday 24 December 2014 13:57:15 Ben Cooksley wrote: > Unfortunately i'm not sure if Gitolite's ACL mechanisms let us > differentiate between tags and branches so if we allow anyone to > delete branches they'll probably be able to do the same for tags. Then it's definitely something to pay attention to. I don't think we're as well structured for tags than we are for branches accross the board. Especially for tagging releases I don't think we have a consistent naming scheme. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Changes to branch management
On Wed, Dec 24, 2014 at 4:40 AM, Boudewijn Rempt wrote: > On Wed, 24 Dec 2014, Ben Cooksley wrote: > >> Hi all, >> >> As the other thread has gotten a bit congested with various threads, I >> thought I would split up the topics to make things a bit easier to >> manage. >> >> The first seems the least contentious: allowing all developers to >> delete branches on our mainline repositories, except for certain >> protected branches (like "master" and "KDE/*" for instance). >> >> Any suggestions or variations on this? >> >> Note: the protected branches really do need to be universal across all >> repositories to be effective - otherwise the effort required to add >> the protection will introduce an extremely high maintenance burden. > > > Would it be possible to add the Calligra/* release branches to that list, or > should we better rename them toe KDE/*? That brings the list of protected branches requested thus far to: master frameworks KDE/* Applications/* Plasma/* Calligra/* Any others? Please bear in mind that for each item added to the list, we need two lines in the Gitolite configuration - per repository. We have 747 declared (mainline) repositories at the moment. (Fortunately the generation of this file is scripted from the projects.kde.org database) > >> I'll also add that there is never a risk of work being lost courtesy >> of the backup refs. The hooks automatically create these refs >> (including the unix time of the event) whenever a destructive event is >> made to a ref. The hooks will also explicitly prohibit any attempt to >> alter the backup refs - they're read only and untouchable. >> >> These can be manually fetched using "git fetch" if necessary to >> restore a branch which is mistakenly deleted. > > > That's reassuring :-) Yes, we've had this mechanism in place since our current generation of hooks went live (Jan 2011). > > Boud Thanks, Ben
Re: Changes to branch management
On Wed, Dec 24, 2014 at 5:35 AM, Sebastian Kügler wrote: > On Tuesday, December 23, 2014 06:27:01 Albert Astals Cid wrote: >> El Dimarts, 23 de desembre de 2014, a les 14:48:21, Sebastian Kügler va >> >> escriure: >> > On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: >> > > The first seems the least contentious: allowing all developers to >> > > delete branches on our mainline repositories, except for certain >> > > protected branches (like "master" and "KDE/*" for instance). >> > >> > >> > >> > I'd add "frameworks" to that, it has a status very similar to "master" for >> > many projects. >> >> Has it? As far as i understand frameworks is "just" a work branch that will >> eventually merged into "master" when it's done. > > IMO, yes. It's a branch shared across many people and often being the base for > yet another branch, so the annoyance of someone doing a force-push there would > be quite high. The abuse of such branch deletion powers to achieve a "force push" would be considered a severe violation of the Code of Conduct as far as i'm concerned. That is regardless of whether the branch affected is a personal or mainline branch. > > I'm in favor of only relaxing the permissions for "personal" branches (i.e. > branches that you've created yourself (in Plasma, we're using > username/branchname quite consistently, so just matching for "starts with > $username" would work well enough for me). It would be incredibly expensive to record who created a branch to implement such an ACL. While personal branches are supported, the scheme you use at the moment isn't unfortunately. See http://gitolite.com/gitolite/gitolite.html#pers for more information. > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 Thanks, Ben
Re: Changes to branch management
On Wed, Dec 24, 2014 at 7:10 AM, Thiago Macieira wrote: > On Tuesday 23 December 2014 17:45:23 Milian Wolff wrote: >> +1 to all of the above. What about tags btw? In KDevelop e.g. it would only >> be a nuisance if someone would delete one of our "stable" branches, but >> deleting one of the release tags would be ugly as I'd then need to figure >> out what commit was chosen for what release. >> >> Bye and thanks for your continuous work Ben, much appreciated! Take care. > > Tags shouldn't be deleted, period. That's something for the repo owner, in > case of a mistake. > > Also note that people will get those tags and git remote prune doesn't delete > them. So don't push bad tags. Once again you don't have to worry. The backup mechanism in the hooks doesn't care about the type of ref it is handling - if the operation is destructive a backup will be created. Unfortunately i'm not sure if Gitolite's ACL mechanisms let us differentiate between tags and branches so if we allow anyone to delete branches they'll probably be able to do the same for tags. Regards, Ben > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 >
Re: Changes to branch management
On Tuesday 23 December 2014 17:45:23 Milian Wolff wrote: > +1 to all of the above. What about tags btw? In KDevelop e.g. it would only > be a nuisance if someone would delete one of our "stable" branches, but > deleting one of the release tags would be ugly as I'd then need to figure > out what commit was chosen for what release. > > Bye and thanks for your continuous work Ben, much appreciated! Take care. Tags shouldn't be deleted, period. That's something for the repo owner, in case of a mistake. Also note that people will get those tags and git remote prune doesn't delete them. So don't push bad tags. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Changes to branch management
On Tuesday, December 23, 2014 17:29:05 Ivan Čukić wrote: > > I'd add Applications/* and Plasma/* to this. > > > >Would it be possible to add the Calligra/* release branches to that > > Seems that release branches are starting with capital letters. Would that > be possible and sufficient for the deletable-branch heuristic? Sounds very cryptic to me, to be honest. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
On Wednesday 24 December 2014 00:04:22 Ben Cooksley wrote: > Hi all, > > As the other thread has gotten a bit congested with various threads, I > thought I would split up the topics to make things a bit easier to > manage. > > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). > > Any suggestions or variations on this? > > Note: the protected branches really do need to be universal across all > repositories to be effective - otherwise the effort required to add > the protection will introduce an extremely high maintenance burden. > > I'll also add that there is never a risk of work being lost courtesy > of the backup refs. The hooks automatically create these refs > (including the unix time of the event) whenever a destructive event is > made to a ref. The hooks will also explicitly prohibit any attempt to > alter the backup refs - they're read only and untouchable. > > These can be manually fetched using "git fetch" if necessary to > restore a branch which is mistakenly deleted. +1 to all of the above. What about tags btw? In KDevelop e.g. it would only be a nuisance if someone would delete one of our "stable" branches, but deleting one of the release tags would be ugly as I'd then need to figure out what commit was chosen for what release. Bye and thanks for your continuous work Ben, much appreciated! Take care. -- Milian Wolff m...@milianw.de http://milianw.de
Re: Changes to branch management
On Tuesday, December 23, 2014 06:27:01 Albert Astals Cid wrote: > El Dimarts, 23 de desembre de 2014, a les 14:48:21, Sebastian Kügler va > > escriure: > > On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > > > The first seems the least contentious: allowing all developers to > > > delete branches on our mainline repositories, except for certain > > > protected branches (like "master" and "KDE/*" for instance). > > > > > > > > I'd add "frameworks" to that, it has a status very similar to "master" for > > many projects. > > Has it? As far as i understand frameworks is "just" a work branch that will > eventually merged into "master" when it's done. IMO, yes. It's a branch shared across many people and often being the base for yet another branch, so the annoyance of someone doing a force-push there would be quite high. I'm in favor of only relaxing the permissions for "personal" branches (i.e. branches that you've created yourself (in Plasma, we're using username/branchname quite consistently, so just matching for "starts with $username" would work well enough for me). Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
> I'd add Applications/* and Plasma/* to this. >Would it be possible to add the Calligra/* release branches to that Seems that release branches are starting with capital letters. Would that be possible and sufficient for the deletable-branch heuristic? -- Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com
Re: Changes to branch management
On Wed, 24 Dec 2014, Ben Cooksley wrote: Hi all, As the other thread has gotten a bit congested with various threads, I thought I would split up the topics to make things a bit easier to manage. The first seems the least contentious: allowing all developers to delete branches on our mainline repositories, except for certain protected branches (like "master" and "KDE/*" for instance). Any suggestions or variations on this? Note: the protected branches really do need to be universal across all repositories to be effective - otherwise the effort required to add the protection will introduce an extremely high maintenance burden. Would it be possible to add the Calligra/* release branches to that list, or should we better rename them toe KDE/*? I'll also add that there is never a risk of work being lost courtesy of the backup refs. The hooks automatically create these refs (including the unix time of the event) whenever a destructive event is made to a ref. The hooks will also explicitly prohibit any attempt to alter the backup refs - they're read only and untouchable. These can be manually fetched using "git fetch" if necessary to restore a branch which is mistakenly deleted. That's reassuring :-) Boud
Re: Changes to branch management
El Dimarts, 23 de desembre de 2014, a les 14:48:21, Sebastian Kügler va escriure: > On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > > The first seems the least contentious: allowing all developers to > > delete branches on our mainline repositories, except for certain > > protected branches (like "master" and "KDE/*" for instance). > > I'd add "frameworks" to that, it has a status very similar to "master" for > many projects. Has it? As far as i understand frameworks is "just" a work branch that will eventually merged into "master" when it's done. Cheers, Albert
Re: Changes to branch management
El Dimecres, 24 de desembre de 2014, a les 00:04:22, Ben Cooksley va escriure: > Hi all, > > As the other thread has gotten a bit congested with various threads, I > thought I would split up the topics to make things a bit easier to > manage. > > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). I'd add Applications/* and Plasma/* to this. > Any suggestions or variations on this? Is the option that someone mentioned of "I can remove only the branches that are myusername/*"? Cheers, Albert > > Note: the protected branches really do need to be universal across all > repositories to be effective - otherwise the effort required to add > the protection will introduce an extremely high maintenance burden. > > I'll also add that there is never a risk of work being lost courtesy > of the backup refs. The hooks automatically create these refs > (including the unix time of the event) whenever a destructive event is > made to a ref. The hooks will also explicitly prohibit any attempt to > alter the backup refs - they're read only and untouchable. > > These can be manually fetched using "git fetch" if necessary to > restore a branch which is mistakenly deleted. > > Thanks, > Ben
Re: Changes to branch management
On Wednesday, December 24, 2014 00:04:22 Ben Cooksley wrote: > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). I'd add "frameworks" to that, it has a status very similar to "master" for many projects. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Changes to branch management
On Wednesday 24 December 2014 00:04:22 Ben Cooksley wrote: > The first seems the least contentious: allowing all developers to > delete branches on our mainline repositories, except for certain > protected branches (like "master" and "KDE/*" for instance). > > Any suggestions or variations on this? I think "master" and "KDE/*" is a reasonable set of protected branches, and allowing deleting other branches should be fine, given the backup system. > Note: the protected branches really do need to be universal across all > repositories to be effective - otherwise the effort required to add > the protection will introduce an extremely high maintenance burden. Also, having consistency helps people working across multiple projects, which I have always got the impression is something we encourage. Alex
Re: Changes to branch management
On Tuesday, 23 December 2014 12:04:22 CEST, Ben Cooksley wrote: The first seems the least contentious: allowing all developers to delete branches on our mainline repositories, except for certain protected branches (like "master" and "KDE/*" for instance). Any suggestions or variations on this? Given that the current git infrastructure is there to stay for a while, adding support for this makes a lot of sense in my opinion. Right now we all have a technical access to create arbitrary branches. It makes sense to abolish the current rule that only a repo owner can delete them. That said, is it OK from a "cultural" point of view if I as a KDE developer go ahead and work directly in some project's feature branch? IMHO that makes sense, "increases collaboration" and what not, but I also think that this should be clearly documented and communicated well so that people aren't surprised. Looking ahead long-term, I envision a system where it doesn't really matter where people do not have to create feature branches. They simply push their changes up for a review, and they are tracked as if it was a feature branch. However, this won't get adopted anytime soon, so +1 for enabling branch deletion, +1 for discouraging the use of personal clones, +1 for working with feature branches right within a project's repo. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Changes to branch management
Hi all, As the other thread has gotten a bit congested with various threads, I thought I would split up the topics to make things a bit easier to manage. The first seems the least contentious: allowing all developers to delete branches on our mainline repositories, except for certain protected branches (like "master" and "KDE/*" for instance). Any suggestions or variations on this? Note: the protected branches really do need to be universal across all repositories to be effective - otherwise the effort required to add the protection will introduce an extremely high maintenance burden. I'll also add that there is never a risk of work being lost courtesy of the backup refs. The hooks automatically create these refs (including the unix time of the event) whenever a destructive event is made to a ref. The hooks will also explicitly prohibit any attempt to alter the backup refs - they're read only and untouchable. These can be manually fetched using "git fetch" if necessary to restore a branch which is mistakenly deleted. Thanks, Ben
