fwiw, I think a *small* number of topic branches in certain cases makes sense.. I'm definitely in support of a TTL limit (ie. automatically nuke topic branches with no activity in N months, or similar..)
BR, -R On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák <mar...@gmail.com> wrote: > It's not so important now that the amdgpu driver is about to be merged. > > Speaking of other branches, I think removing the old feature branches > is a good idea. > > Marek > > On Mon, Jun 22, 2015 at 8:02 PM, Ian Romanick <i...@freedesktop.org> wrote: >> On 06/22/2015 10:40 AM, Marek Olšák wrote: >>> I will happily remove the branch after the kernel driver lands. >>> >>> I also wonder why all Mesa developers can force-push branches in Mesa >>> but not libdrm. >> >> That's probably just historical. We probably ought to restrict that on >> Mesa as well. >> >> It sounds like you guys have some requirements for a shared repo. It >> seems like a repo on fd.o could work. I think you'd just need a >> "amddevs" group and make the repo group rwx. I thought fd.o GIT did >> https (maybe just SSH?). >> >>> Marek >>> >>> On Mon, Jun 22, 2015 at 5:39 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>>> On Mon, Jun 22, 2015 at 11:30 AM, Christian König >>>> <deathsim...@vodafone.de> wrote: >>>>> On 22.06.2015 15:41, Ilia Mirkin wrote: >>>>>> >>>>>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard <t...@stellard.net> wrote: >>>>>>> >>>>>>> On Mon, Jun 22, 2015 at 12:23:54PM +0200, Marek Olšák wrote: >>>>>>>> >>>>>>>> On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin <imir...@alum.mit.edu> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <mic...@daenzer.net> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 22.06.2015 00:31, Ilia Mirkin wrote: >>>>>>>>>>> >>>>>>>>>>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov >>>>>>>>>>> <emil.l.veli...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Ilia Mirkin <imir...@alum.mit.edu> writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are a *ton* of branches in the upstream mesa git. Here is a >>>>>>>>>>>>>> full list: >>>>>>>>>>>>>> >>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>> is there >>>>>>>>>>>>>> any reason to keep these around with the exception of: >>>>>>>>>>>>>> >>>>>>>>>>>>>> master >>>>>>>>>>>>>> $version (i.e. 9.0, 10.0, mesa_7_7_branch, etc) >>>>>>>>>>>>> >>>>>>>>>>>>> Instead of outright deleting old branches, it would be possible to >>>>>>>>>>>>> set >>>>>>>>>>>>> up an "archive" repository which mirrors all branches of the main >>>>>>>>>>>>> repository. And then delete "obsolete" branches only from the main >>>>>>>>>>>>> repository. Ideally, you would want a git hook to refuse to create >>>>>>>>>>>>> a new >>>>>>>>>>>>> branch (in the main repository) if a branch by that name already >>>>>>>>>>>>> exists >>>>>>>>>>>>> in the archive repository. Possibly with the exception that >>>>>>>>>>>>> creating a >>>>>>>>>>>>> same-named branch on the same commit would be allowed. >>>>>>>>>>>>> >>>>>>>>>>>>> (And the same for tags, of course) >>>>>>>>>>>>> >>>>>>>>>>>> Personally I am fine with either approach - stay/nuke/move. But I'm >>>>>>>>>>>> thinking that having a mix of the two suggestions might be a nice >>>>>>>>>>>> middle >>>>>>>>>>>> ground. >>>>>>>>>>>> >>>>>>>>>>>> Write a script that nukes branches that are merged in master (check >>>>>>>>>>>> the >>>>>>>>>>>> top commit of the branch) and have an 'archive' repo that contains >>>>>>>>>>>> everything else (minus the stable branches). >>>>>>>>>> >>>>>>>>>> Sounds good to me, FWIW. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> That still leaves a ton around, and curiously removes mesa_7_5 and >>>>>>>>>>> mesa_7_6. >>>>>>>>>> >>>>>>>>>> I think the latter is expected, we were using a different branching >>>>>>>>>> model back in those days. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> origin/amdgpu >>>>>>>>>> >>>>>>>>>> Note that this is a currently active branch, to be merged to master >>>>>>>>>> soon. >>>>>>>>> >>>>>>>>> Perhaps there's something I don't understand, but why is a feature >>>>>>>>> branch made available on the shared tree? In my view of things the >>>>>>>>> only branches on the shared mesa.git tree should be the version >>>>>>>>> branches. >>>>>>>> >>>>>>>> As you can see, a lot of feature branches are in the shared tree >>>>>>>> already, so there is a precedent. Sharing a branch among people in >>>>>>>> this way sometimes tends to be more convenient. >>>>>>>> >>>>>>>> The reason here is that it's the only mesa repository where most >>>>>>>> people from our team have commit access. >>>>>>>> >>>>>>> Also, the shared git tree supports https access, which means it is >>>>>>> accessible when behind a firewall. >>>>>> >>>>>> OK, well if that's the prevailing attitude, then I'm on a fool's >>>>>> errand, and I'll just drop this. >>>>> >>>>> >>>>> I still think it would be a good idea to archive the branches after a >>>>> while, >>>>> cause the current status is rather confusing if you search for something >>>>> specifc. >>>> >>>> Yeah, but if the policy is "create random branches whenever you feel >>>> like on the upstream mesa tree", then this same current situation will >>>> happen again, so it's not really worth fixing now (at least for me). >>>> I'm not aware of any other major project with this sort of branching >>>> policy, but I guess there's always a first! >>>> >>>> I don't really see why you wouldn't just use a shared tree in >>>> someone's ~/foo, chgrp'd to mesa or some other convenient group, or >>>> how https plays into things, but I'm sure there's some reason for it. >>>> [Or why those amdgpu patches are on a branch in the first place rather >>>> than in master.] If the final state isn't a tree with a policy of not >>>> adding (non-release) branches, I don't think I'm particularly >>>> interested in doing the legwork. >>>> >>>> Cheers, >>>> >>>> -ilia >>>> _______________________________________________ >>>> mesa-dev mailing list >>>> mesa-dev@lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> _______________________________________________ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >> > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
