Proposal to improving KDE Software Repository Organization

[Michael Pyne]

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 
accident.

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 
kde-build-metadata instead.

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 
it.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140819/681eeea3/attachment.sig>