Proposal to improving KDE Software Repository Organization
mpyne at kde.org
Wed Aug 20 01:42:30 BST 2014
On Wed, August 20, 2014 00:48:36 Àlex Fiestas wrote:
> On Monday 18 August 2014 21:54:40 Michael Pyne wrote:
> > We await your comments, suggestions, clarification requests, and other
> > feedback.
> The proposed solution will clearly help to improve the situation, so +1!
> Something I would like to explore is the possibility of putting on each
> repository the information relative to it, and then maybe via jenkins
> generate the unified file.
> The pros of this is that we have the information about each project contain
> on itself making it easier for maintainers to keep the information up to
> date and also making it easier to discover this information (not many
> people know about kde-build-metadata and surely not third party
Actually this was my initial idea. I had even tried to sell the sysadmins on
the idea of expanding the information recorded about a project in the
projects.kde.org interface to allow for this.
However we ended up noting some issues. Eventually, the idea at the creation
of kde-build-metadata was that this information would be centralized there
(not at the repo) so that maintainer action would not be required to make
things work. Not to say that maintainer action is not desired; just that it
wouldn't be mandated to make things work right.
Although it's true that moving data to the repo doesn't mean errors couldn't
be fixed by KDE developers who happen to notice it, that would require cloning
the whole repo (since it's fairly likely that it's not already be checked
out), making the fix, pushing it, you know the drill. With kde-build-metadata
you already have it checked out by definition, and the ones most likely to
notice a test failure know where to make the fix (or at least where to point
the repo's maintainer).
Additionally there's actually a couple of scripts in kde-build-metadata's
tools/ subdirectory that would be much less useful if they had to wait for
Jenkins to re-generate the centralized file, and these tools are useful for
validating the JSON format used and proving that the dependencies are as
expected, so I think that would increase the odds of introducing errors by
As it stands I don't think discoverability is a big concern here. If a
maintainer is making a repo from a template, we could add a pointer to the
right repo in the template itself. If a maintainer is already maintaining a
repository, they'd have to hear the news to know to add a new metadata file,
but if they're able to receive that news it's easy enough to point them to
The one problem is developers making a new repository by simply copying the
structure of an old one, but then they'd hear about dependency data when their
new repo doesn't work on Jenkins. ;)
With all that said there's no reason we can't make the data in kde-build-
metadata more easily available to developers in a more-preferred location
(maybe at projects.kde.org?), but I don't think I'll be the one implementing
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel