[oe] meta-java Workflow

[Jens Rehsack]

> Am 13.01.2016 um 19:38 schrieb Otavio Salvador <otavio.salvador at ossystems.com.br>:
> 
> Hello Jens,
> 
> On Wed, Jan 13, 2016 at 4:03 PM, Jens Rehsack <rehsack at gmail.com> wrote:
>> to avoid such a problem as it occurred with ec7b984f, 04d5d0bf and dfb21b44, I strongly suggest that meta-java follows the merge-workflow from other meta-layers:
>> 
>> cherry-pick new stuff into master-next, when settled - merge to master
>> Branch releases as other layers do and same, push back-ported patches into ${rel_branch}-next and merge the behaving ones into ${rel_branch}.
>> 
>> The current way - pushing to master and live only there result in the happened revert - and to continue my work I would have to revert the reverts without any nice word in the commit message as I did in reverting 24b98ac3 with a88718b6.
> 
> I understand your frustation but I think you are exagerating on this.

I don't think so ;)
I'm not frustrated - I think no one benefits from quick shots. If there
were staging branches, the regression would have been found before it
bothers users like Jackie.

Lot's of jethro users wanting to build openjdk-8 asking for trouble
(still? is autotools-patch in jethro meanwhile) because of missing
patch (for good reason - stability of the release, as we figured out).

My goal is not to make Jackie or me more happy, my goal is to find
regressions before they hit users to avoid pressure (regardless whether
you, me or an innocent user is affected).

> The fix you provide (and was reverted by causing regression at that
> moment) is a great improvement and those should be brought back. To
> bring it back, as I explained on the Hangout, you can revert those and
> apply the fix for the sstate. Doing this, we can integrate those
> changes back and everyone is happy.

No, because I can't do the tests discovered the regression, because they
come from forcing rebuilds in the bootstrap phase. Precisely because
of the challenge to test excessively so much circumstances I highly
appreciate the opportunity of a CI alerting on integration. Regardless
of the root cause that allows to fix problems before they hit common
folk like everyone except Otavio :D

> To make all this setup you are asking for, I need to reserve resources
> in our autobuilder to properly excercize it and provide useful
> feedback otherwise it is useless. To be honest, I am not being an
> active user of this and been acting as maintainer just due the lack of
> someone more active so I am willing to give the maintenance for
> someone more commited to Java use than me, if desired.

I was unsure whether I mention that: I see what you are doing in
excellence for so many parts of Yocto - and because of this, when
you're doing something just great, it feels as a performance degrade :D

I don't see any personal mistake in the situation - from none of
the involved parties.

Maybe

Cheers
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160115/2629fdf0/attachment-0002.sig>