--nextPart34354529.UBdsaUqg1J
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Wed, August 20, 2014 00:48:36 =C0lex Fiestas wrote:
> On Monday 18 August 2014 21:54:40 Michael Pyne wrote:
> > We await your comments, suggestions, clarification requests, and ot=
her
> > feedback.
>=20
> The proposed solution will clearly help to improve the situation, so =
+1!
>=20
> Something I would like to explore is the possibility of putting on ea=
ch
> repository the information relative to it, and then maybe via jenkins=

> generate the unified file.
>=20
> The pros of this is that we have the information about each project c=
ontain
> 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 sysadmi=
ns on=20
the idea of expanding the information recorded about a project in the=20=

projects.kde.org interface to allow for this.

However we ended up noting some issues. Eventually, the idea at the cre=
ation=20
of kde-build-metadata was that this information would be centralized th=
ere=20
(not at the repo) so that maintainer action would not be required to ma=
ke=20
things work. Not to say that maintainer action is not desired; just tha=
t it=20
wouldn't be mandated to make things work right.

Although it's true that moving data to the repo doesn't mean errors cou=
ldn't=20
be fixed by KDE developers who happen to notice it, that would require =
cloning=20
the whole repo (since it's fairly likely that it's not already be check=
ed=20
out), making the fix, pushing it, you know the drill. With kde-build-me=
tadata=20
you already have it checked out by definition, and the ones most likely=
 to=20
notice a test failure know where to make the fix (or at least where to =
point=20
the repo's maintainer).

Additionally there's actually a couple of scripts in kde-build-metadata=
's=20
tools/ subdirectory that would be much less useful if they had to wait =
for=20
Jenkins to re-generate the centralized file, and these tools are useful=
 for=20
validating the JSON format used and proving that the dependencies are a=
s=20
expected, so I think that would increase the odds of introducing errors=
 by=20
accident.

As it stands I don't think discoverability is a big concern here. If a=20=

maintainer is making a repo from a template, we could add a pointer to =
the=20
right repo in the template itself. If a maintainer is already maintaini=
ng a=20
repository, they'd have to hear the news to know to add a new metadata =
file,=20
but if they're able to receive that news it's easy enough to point them=
 to=20
kde-build-metadata instead.

The one problem is developers making a new repository by simply copying=
 the=20
structure of an old one, but then they'd hear about dependency data whe=
n their=20
new repo doesn't work on Jenkins. ;)

With all that said there's no reason we can't make the data in kde-buil=
d-
metadata more easily available to developers in a more-preferred locati=
on=20
(maybe at projects.kde.org?), but I don't think I'll be the one impleme=
nting=20
it.

Regards,
 - Michael Pyne
--nextPart34354529.UBdsaUqg1J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJT8+79AAoJEAuvDJx7aunyxvEP/1wX4QISVybncekmuxUSQBnw
NfGwaGsyMy4v9z/5EA5UifUveKH7sY1Cz66/ngAc3Lieb6aFguJIC+ubMECHblIP
3wveRORKwWAE9VBXDW69lZEeXHFmq2NiJRoBs3y9KdAbXBWOemvxMg5LBz1W/8k/
RDDl4Q7cUqAxu4D4E1dmKefihtKXYNwiIzvmdQbSXoECa56qbVGlk9R0ROIqOCZK
P1UFAbPh9To7ZV3Rka9w3x5KYrd5zp7lxxdMwoCzrD5ShUp0NEVZi4n6VwwmM4CQ
J5hCEGGUJgRTYavfOZ1z87QDMEaVINeiyKLu/eBlIQiFMKAiiIZdlG1OBj3t3jKW
6J3Ls8akCO7GE50Z/hu9yJ/JzLx7q1VYsduNYpCuWPHxN78AMpan14dJnlImmBxA
0oYl4r+ZSxzYDa+4N8LqhILxWa0ZJ0SyJ4nta0UksjpXJpX/fzbFfJIxgeSdzHs/
H987nAnClJAzvlfMegb7CDL/M2SOhCkku0HaHShNZCjAIpi/u9YRjKiHz1C4rEnL
aa9fDmeEwXTruSP/8EJRok6DzTOvB533P3Pt5QgPMTqWpXUYoysDwN9aR7aG4q1n
AJFCjZZK6nr7BF31pDXmSstMx+/SaNd7CGnzozWXDLUJwGkmP3elRSpIRhBokRq3
Ut9kAgszRM+LMHODsXY1
=1usX
-----END PGP SIGNATURE-----

--nextPart34354529.UBdsaUqg1J--