[Mesa-dev] abundance of branches in mesa.git

Sat Feb 20 21:41:04 UTC 2016

On Feb 20, 2016 1:19 PM, "Rob Clark" <robdclark at gmail.com> 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 <maraeo at 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 <idr at 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 <imirkin at alum.mit.edu>
wrote:
> >>>> On Mon, Jun 22, 2015 at 11:30 AM, Christian König
> >>>> <deathsimple at vodafone.de> wrote:
> >>>>> On 22.06.2015 15:41, Ilia Mirkin wrote:
> >>>>>>
> >>>>>> On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard <tom at 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 <
imirkin at alum.mit.edu>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer <
michel at 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.velikov at gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ilia Mirkin <imirkin at 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 at lists.freedesktop.org
> >>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>> _______________________________________________
> >>> mesa-dev mailing list
> >>> mesa-dev at lists.freedesktop.org
> >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>>
> >>
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160220/9a72c90a/attachment-0001.html>