[rkward-devel] splitting repos?

[Thomas Friedrichsmeier]

Hi,

On Mon, 12 Oct 2015 12:22:32 +0200
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> the most natural way to start working on something like RKTeaching
> would probably be to fork it as the RKWard community group.
> hopefully, we will see more development like this in the future.
> however, this does not work so well with the rather monolithic
> external-plugins repo. it also makes it a bit hard to tag releases of
> individual plugins, and if you'd like to contribute to just one of
> those you'd still have to get them all, which might become a problem
> over time (when it grows). is there a real advantage of having all
> plugins in one repo?

not sure, if splitting might make it a bit harder for handing out
permissions (I'm not up to speed with github), but probably not much.

I'm not sure, whether it makes a lot of sense for the smaller packages.
Depends on how likely you'd be to want to check out only one of them.

One thing that a split does make harder is applying "the same" change
to all plugins at once. Suppose we'd get a new but not quite compatible
version of the <varselector> for instance (just an example, I have no
plans on this), we'd want to adjust essentially all plugins. After a
split that would be one commit and one push for each repo.

> if not, i would like to try to split the external plugins repository
> on github into one for each plugin[1].

All that said, I'm not opposed to a split, and for rkTeaching it
definitely makes sense.
 
> this might also be a good idea for the XiMpLe and rkwarddev packages,
> which are currently part of the RKWard sources and cannot be
> tagged/cloned individually.

Yes, probably. Though I tend to think that we'd want to keep these on
git.kde.org, rather than github.

> [1]
> https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/

Not sure, if it helps any, but you might also be interested in
scripts/import_external_plugin.sh inside the RKWard repo.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151012/681c4799/attachment.sig>