meta-java Workflow

meta-java Workflow

[Jens Rehsack]

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

Hi,

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.

Cheers
--
Jens Rehsack - rehsack@gmail.com


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 859 bytes --]

Re: meta-java Workflow

[Otavio Salvador]

Hello Jens,

On Wed, Jan 13, 2016 at 4:03 PM, Jens Rehsack <rehsack@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.

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.

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: meta-java Workflow

[Maxin B. John]

Hi Jens,

On Wed, Jan 13, 2016 at 07:03:51PM +0100, Jens Rehsack wrote:
> Hi,
> 
> 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

Agree with this suggestion. Current state of meta-java isn't that great 
mostly because of the absence of a Continuous Integration process. 

I have briefly tried to incorporate automated testing for meta-java layer
in github using travic CI. However, it is not yet completed due to space 
limitation and timeout problems in Travis CI. Hoping to fix that soon.

https://github.com/maxinbjohn/meta-java/blob/master/.travis.yml

> 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.
> 
> Cheers
> Jens Rehsack - rehsack@gmail.com

Best Regards,
Maxin

Re: meta-java Workflow

[Huang, Jie (Jackie)]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org [mailto:openembedded-devel-
> bounces@lists.openembedded.org] On Behalf Of Otavio Salvador
> Sent: Thursday, January 14, 2016 2:38 AM
> To: OpenEmbedded Devel List
> Subject: Re: [oe] meta-java Workflow
> 
> Hello Jens,
> 
> On Wed, Jan 13, 2016 at 4:03 PM, Jens Rehsack <rehsack@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}.

I agree to improve this so it should be able to avoid some regression issues.

> >
> > 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 left the detail message in the following commit, if that didn't have nice word, sorry about that, but I just
tried to explain the regression issue I found and how I fix it.

> I did in reverting 24b98ac3 with a88718b6.
> 
> I understand your frustation but I think you are exagerating on this.
> 

I have the same feeling, if there is no regression issue, I believe no one like to revert anything.

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

I agree, I will be happy if there is a better fix.

Thanks,
Jackie

> 
> 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.
> 
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: meta-java Workflow

[Jens Rehsack]

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


> Am 13.01.2016 um 19:38 schrieb Otavio Salvador <otavio.salvador@ossystems.com.br>:
> 
> Hello Jens,
> 
> On Wed, Jan 13, 2016 at 4:03 PM, Jens Rehsack <rehsack@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@gmail.com


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 859 bytes --]