On Feb 20, 2016 1:19 PM, "Rob Clark" <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote: > > 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..) I agree. Sometimes something big comes up that's not ready for merging such as amdgpu or our recently pushed Vulkan driver. However, those should only be temporary and removed once the work is complete. I saw a "broadwell" branch in there which is probably at least 2 years old and completely subsumed by master. We don't want to be archiving random junk in the main tree. I'd be fine with a timeout system where non-release branches get the boot after a certain amount inactivity. If you want to archive something, that's what personal git repos are for. --Jason > BR, > -R > > On Mon, Jun 22, 2015 at 2:23 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> 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 <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> 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 <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote: > >>>> On Mon, Jun 22, 2015 at 11:30 AM, Christian König > >>>> <<a href="mailto:deathsimple@vodafone.de">deathsimple@vodafone.de</a>> wrote: > >>>>> On 22.06.2015 15:41, Ilia Mirkin wrote: > >>>>>> > >>>>>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> 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 <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On 22.06.2015 00:31, Ilia Mirkin wrote: > >>>>>>>>>>> > >>>>>>>>>>> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov > >>>>>>>>>>> <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> 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 > >>>> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > >>>> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> > >>> _______________________________________________ > >>> mesa-dev mailing list > >>> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > >>> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> > >>> > >> > > _______________________________________________ > > mesa-dev mailing list > > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > > <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> > _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a>