All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maxin B. John" <maxin.john@intel.com>
To: prvs=68935beb6=Richard.Leitner@skidata.com
Cc: Mark Asselstine <mark.asselstine@windriver.com>,
	Otavio Salvador <otavio@ossystems.com.br>,
	OpenEmbedded Devel List
	<openembedded-devel@lists.openembedded.org>,
	Otavio Salvador <otavio.salvador@ossystems.com.br>
Subject: Re: [meta-java] maintainer status
Date: Mon, 11 Jun 2018 14:30:35 +0300	[thread overview]
Message-ID: <20180611113035.GA17777@mbabyjoh-desk.ger.corp.intel.com> (raw)
In-Reply-To: <d8462836-e655-4bb4-7b03-bce18cb3e24c@skidata.com>

Hi Richard,

Sorry for my long silence here in the list ( was away due to a personal loss).


On Thu, Jun 07, 2018 at 04:32:36PM +0200, prvs=68935beb6=Richard.Leitner@skidata.com wrote:
> On 06/07/2018 03:56 PM, Otavio Salvador wrote:
> > On Thu, Jun 7, 2018 at 10:53 AM, Richard Leitner
> > <richard.leitner@skidata.com> wrote:
> > ....
> >> As I'm using this layer now for quite a few years I'll be glad to help you with
> >> the maintainership of meta-java. Nonetheless I have to admit that I have no
> >> experience in maintaining an openembedded layer ;-)
> >> Therefore if you're still interested I'd have some questions regarding the
> >> "strategic" targets, workflows and stuff like that...
> > 
> > Awesome, new energy!

Great ! 

> > Sure, go ahead and ask :-D
> > 
> 
> Thanks :-)
> 
> So here are some question that currently came to my mind:
> 
>  * do you use some kind of patch management software (like patchwork)?

meta-java doesn't use patchwork till now.

>  * are there any "quality gate tests" for patches being applied to master or stable branches?

At the moment, we dont have enough tests in meta-java (It will be good to have more selftests). Moving
from manual build/testing to a Jenkins based automated one was briefly tested in a personal setup.

>  * is there something like a build/test robot for patches and/or branches?
Not yet. Tested a travis based setup in github. Testing wasn't successful due to the resource restrictions
(mainly storage) there.

>  * should we use the master-next branch for staging new patches?

Preferably - yes.

>  * is there a reason for not having OpenJDK >8 recipes?

Nothing that I can remember :)

>  * if the above is answered with something like "because nobody submitted them": Should we try to follow the current OpenJDK release model (a feature release every six month)?

+1, That will be nice. 

>  * based on what scheduling are the stable branches created? Yocto Project release dates I guess?

Yes.

>  * what kind of patches should be applied/backported to the stable branches?

Depends. Mostly security based patches and others, based on urgency/demand.

> 
> I think that's all for now (but presumably some more question will follow during the next weeks) ;-)
>
> regards;Richard.L

Best Regards,
Maxin


  reply	other threads:[~2018-06-11 11:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 15:11 [meta-java] maintainer status Mark Asselstine
2018-06-05 15:18 ` Mark Asselstine
2018-06-05 15:51   ` Mark Asselstine
2018-06-05 16:48 ` Otavio Salvador
2018-06-05 17:45   ` Mark Asselstine
2018-06-06  7:38 ` Mario Domenech Goulart
2018-06-06 13:31   ` Mark Asselstine
2018-06-07 14:10     ` Mario Domenech Goulart
2018-06-07 14:14       ` Mark Asselstine
2018-06-06 20:42 ` Henning Heinold
2018-06-07  5:44   ` Richard Leitner
2018-06-07 13:22     ` Henning Heinold
2018-06-07 13:53       ` Richard Leitner
2018-06-07 13:56         ` Otavio Salvador
2018-06-07 14:11           ` Mark Asselstine
2018-06-07 14:32           ` Richard Leitner
2018-06-11 11:30             ` Maxin B. John [this message]
2018-06-11 12:08               ` Henning Heinold
2018-06-12  7:23                 ` Richard Leitner
2018-06-12 20:59                   ` Michael Halstead
2018-06-13  5:42                     ` Richard Leitner
2018-06-13 10:05                       ` Burton, Ross
2018-06-13 13:44                         ` Richard Leitner

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=20180611113035.GA17777@mbabyjoh-desk.ger.corp.intel.com \
    --to=maxin.john@intel.com \
    --cc=mark.asselstine@windriver.com \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    --cc=otavio@ossystems.com.br \
    --cc=prvs=68935beb6=Richard.Leitner@skidata.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.