[gentoo-java] QA: java-experimental

[gentoo-java] QA: java-experimental

[Alistair Bush]

http://dev.gentoo.org/~ali_bush/qa_java-experimental.txt

Please start fixing.

Re: [gentoo-java] QA: java-experimental

[Krzysztof Pawlik]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Alistair Bush wrote:
> http://dev.gentoo.org/~ali_bush/qa_java-experimental.txt
> 
> Please start fixing.

I've fixed few packages, and... leesten carefully... I'm going to say this only
once: next person to commit an ebuild with KEYWORDS="" (or KEYWORDS="-*") will
be punished... Alistair will send an e-mail every 10 minutes until the ebuild
gets proper keywords and ends up in package.mask.

Can we get commit hook that does some basic QA and aborts the commit if there
are QA errors (and some warning)?

-- 
Krzysztof Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, java, apache, ppc, vim, kernel, python...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-java] QA: java-experimental

[Alistair Bush]

Krzysztof Pawlik wrote:
 > I've fixed few packages, and... leesten carefully... I'm going to say
this only
> once: next person to commit an ebuild with KEYWORDS="" (or KEYWORDS="-*") will
> be punished... Alistair will send an e-mail every 10 minutes until the ebuild
> gets proper keywords and ends up in package.mask.
> 

Oh shit

/me runs back to reverse all the commits in which I dropped all
keywords.  ;)

On a more serious note.

KEYWORDS="-*" is bad!!! and if I see anymore of it an email every 10
minutes will be the last of anyones problems.

but im not that concerned about KEYWORDS=""

I dropped keywords on a few packages in java-overlay because there deps
weren't satisfied within gentoo or java-overlay ( I didn't check
java-experimental unless it was obvious to me. aka hibernate-annotations
). Eventually there will be an email going around with a list of ebuilds
that have no keywords.  These will either be junkyarded or moved to
java-experimental (if that satisfies them).

> Can we get commit hook that does some basic QA and aborts the commit if there
> are QA errors (and some warning)?

I will look into this at some point.  I suppose there are many things we
could do to help maintain qa.  I suppose we also need more overview of
our contributors.  So I might attempt to generate reports, etc of
commits by those users.

Re: [gentoo-java] QA: java-experimental

[Krzysztof Pawlik]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

Alistair Bush wrote:
> I will look into this at some point.  I suppose there are many things we
> could do to help maintain qa.  I suppose we also need more overview of
> our contributors.  So I might attempt to generate reports, etc of
> commits by those users.

So.. maybe it's time to re-think the way java-* overlays are used? I'd opt for
"staging" approach: let java-experimental be well, experimental - you don't know
whenever something will work, is a good idea, you're still working on it, etc.
java-overlay would become a staging ground: after some time (to be defined)
ebuilds would end in main tree.

So the ebuild migration would look like:
 * experimental: fresh stuff
 * overlay: checked by somebody else (peer reviewed)
 * main tree: after some time in overlay (like a month)

That would enforce from where one can have dependencies in particular overlay,
would (hopefully) reduce the size of overlays.

Something similar was done:
http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinoverlays

-- 
Krzysztof Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, java, apache, ppc, vim, kernel, python...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-java] QA: java-experimental

[Alistair Bush]

Krzysztof Pawlik wrote:
> Alistair Bush wrote:
> So.. maybe it's time to re-think the way java-* overlays are used? I'd opt for
> "staging" approach: let java-experimental be well, experimental - you don't know
> whenever something will work, is a good idea, you're still working on it, etc.
> java-overlay would become a staging ground: after some time (to be defined)
> ebuilds would end in main tree.
> 
> So the ebuild migration would look like:
>  * experimental: fresh stuff
>  * overlay: checked by somebody else (peer reviewed)
>  * main tree: after some time in overlay (like a month)
> 
> That would enforce from where one can have dependencies in particular overlay,
> would (hopefully) reduce the size of overlays.

Yes that would be good.  Half the problem is that java-overlay became a
huge playground of experimental packages.  Just look at all the maven
packages.  Ive never been able to get maven to work from java-overlay
and had to hack and slash my way thru them to get them to install in the
first place.  My guess is that everyone is guilty of this in some way.
(I known I am).  Whether it is packages that did work but now don't to
the ones that never worked in the first place it doesn't matter.  From
what I understand java-overlay was meant to help reduce the amount of
maintenance we had to do within the gentoo tree.  It has been very
successful at that,  now we just have overlays full.....

Here are also things ppl should think about. and implement.

1) If you bump a package, with more than trivial changes (aka you don't
finish making them, removing bundled jars, etc, etc) commit it to
java-experimental, never java-overlay.  I don't care what keywords you
give it, if it ain't ready it ain't java-overlay.

2) If you delete (even an outdated ebuild) ensure that there are no
reverse dependencies.  If you are deleting from java-overlay ensure
there are no reverse dependencies within java-overlay and
java-experimental.  (this seems to have occurred a bit.  packages
depending on =dev-java/package-1.1.1.  only to have 1.1.1 replaced by
1.1.2).

I could run on but i've run out of time.

> 
> Something similar was done:
> http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinoverlays
>