Silly question how easy is it to migrate some contrib code into a module? Is it as simple as (1) generating a new module, (2) import/move code in, and (3) add any needed additional module hooks as needed?
Maybe a pointer to building modules would best for me to look for and go from there. Eric Bresie ebre...@gmail.com > On February 13, 2020 at 2:59:32 PM CST, Eric Barboni <sk...@apache.org> wrote: > Hi, > If I understand well only what we want to care of will be audited and > donated. The neglected part will not be audited nor given to Apache or > individual. > > Maybe we first need a list and from this list we decide. > > We can use repository as placeholder to handle reception and adapt to main > repo. (easy to create, easy for pmc member) (done for i10). IMHO pure > refactoring adaption history from 4-6 years decorelated repository is not so > important to keep. > > Question after that is do we want a feature to be release same pace as > NetBeans (quarterly) or do you want to have custom release like > html4j,jackpot or mavenutilies artefacts. > (html4j and mavenutilities are maven based and are better on separated > repository, easy release) > > Jackpot30 looks like an example of ant built artefacts independent form main > repo. We release 3-4 time as incubation, not sure we do one as TLP but that > not an issue. > > We receive, we slice we "fit the pieces together" and we prepare release :D > > Best Regards > Eric > > > -----Message d'origine----- > De : Sven Reimers <sven.reim...@gmail.com> > Envoyé : jeudi 13 février 2020 20:54 > À : dev <dev@netbeans.apache.org> > Objet : Re: [DISCUSS] Wrapping up Oracle's donation of NetBeans to Apache > > Okay. Let's look at this in more detail: > 1. major features like python and xml-schema or similar > -> should get back into a primary place, e.g. own cluster for python maybe > own cluster for xml-schema (could be consolidated with other xml-tooling). > 2. single / simple feature modules from contrib > -> vote if they should get directly promoted to default NetBeans or kept > separate. For me this looks like a case by case decision. > > If we want to have the code at Apache I would assume we want to ship it as > well. > On the other hand I like the idea of having something like incubating > modules, which can be accessed via a special update center... Once they are > mature enough we just ship the code... > Not sure how this may end up in the actual repository structure, but special > clusters seem to be a good idea. > > -Sven > > On Thu, Feb 13, 2020 at 7:34 PM Jesse Glick <typr...@gmail.com> wrote: > > > On Thu, Feb 13, 2020 at 11:27 AM Sven Reimers <sven.reim...@gmail.com> > > wrote: > > > I would assume that all things we pick up from the remaining stuff > > > will > > end > > > up in the main NetBeans repository > > > > OK, in that case I guess they would be dumped in > > `nbbuild/cluster.properties#nb.cluster.betauc` until someone decides > > to promote them? (And fold the contents of `nb.cluster.experimental` > > into that? I am not sure what the real distinction is.) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > -- > Sven Reimers > > * Java Champion > * Apache NetBeans PMC: http://netbeans.apache.org > * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee > * Duke's Choice Award Winner 2009 & 2018 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > >
