From: Alistair Bush <ali_bush@gentoo.org>
To: gentoo-java@lists.gentoo.org
Subject: Re: [gentoo-java] QA: java-experimental
Date: Mon, 02 Feb 2009 07:33:45 +1300 [thread overview]
Message-ID: <4985EB09.4070302@gentoo.org> (raw)
In-Reply-To: <4985881C.2010907@gentoo.org>
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
>
prev parent reply other threads:[~2009-02-01 18:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-01 2:11 [gentoo-java] QA: java-experimental Alistair Bush
2009-02-01 10:32 ` Krzysztof Pawlik
2009-02-01 11:03 ` Alistair Bush
2009-02-01 11:31 ` Krzysztof Pawlik
2009-02-01 18:33 ` Alistair Bush [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4985EB09.4070302@gentoo.org \
--to=ali_bush@gentoo.org \
--cc=gentoo-java@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox