On Wednesday, October 5, 2016 11:40:44 AM CEST Tim Flink wrote:
> I didn't notice that my reply went only to Pavel, resending to devel@
>
> On Tue, 04 Oct 2016 10:25:46 +0200
> Pavel Raiskup <praiskup(a)redhat.com> wrote:
>
> > On Monday, October 3, 2016 1:50:33 PM CEST Tim Flink wrote:
> > >
https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task...
> > > ...
> > > Please read through the wiki page I mentioned above and give us
> > > feedback on whether what we're planning to implement is going to be
> > > useful
> >
> > Useful, yes!
> >
> > > or if there are areas of the plan which could be improved.
> >
> > Can we rather make the ./taskotron directory separate git submodule?
> > I expect that I'm going to play with that directory a lot, without
> > being "that much careful" as I'm with package directories; which
> > might mean that for packaging work there might be a bit unpleasant
> > rush in git-log otherwise.
>
> I'd rather avoid git submodules and subtrees because that's a lot of
> extra complexity to make sure that the various pointers are updated at
> the correct times.
I disagree with extra complexity. Sub-tree sounds like something which is
terribly important -- so we can have separate ACLs for package and tests,
I don't have to bother package maintainers when I develop tests ... etc.
And when we talk about sub-tree, git submodules bring *a lot* of control
over sub-trees *for free*. There's something like `git submodule update
--init --recursive` (could be done by 'fedpkg clone'?).
Simply you can develop subtree without touching "parent", and once you are
ready -- you just update hash. Also one sub-trees (test directories) can
be shared among packages (and not being able to share some testcases among
several packages would be 99% show-stopper for me).
> I think that a better alternative to putting checks into the same
> dist-git repo as packaging information would be to have differently
> namespaced git repos (eg checks-rpms/libfoo for rpms/libfoo) and
> enhance fedpkg to work with that second repository to make it look like
> a subdirectory even though it's a separate git repo.
I'm not against it, as I'm not going to hack that :) but this is a lot of
expensive complexity, when submodules are here clearly for this purpose.
And are you going to hack on submodules? (both as user and to help infra getting
it set-up?)
Pierre