+1 for that approach, thanks Taylor.
On Wed, Nov 8, 2017 at 10:47 AM, P. Taylor Goetz <[email protected]> wrote: > Another thing to keep in mind is that non-Apache release artifacts cannot > be hosted on ASF infrastructure. Even so, non-Apache releases can be cut > from an ASF-hosted git repository. Non-Apache releases also need to be > clearly labeled as such. > > In terms of moving from “com.twitter” to “org.apache” maven group names > and source code package names, I would highly recommend making the maven > group name change as well as changing the package names. > > As Jerry pointed out, Storm waited a long time to change package names to > “org.apache.storm” (maven group name change was immediate). One of the > reasons we were able to do this is because the original package name was > “backtype” as opposed to “com.backtype”. I wouldn’t be surprised if there > were IPMC pushback on making an Apache release with the “com.twitter” > package prefix. You’d likely need a compelling justification for not making > the change. > > In short, my recommendations: > > 1. Move to Apache git — you can still do non-Apache releases > 2. Change groupId/package prefixes to “org.apache.*” prior to attempting > an Apache release. > > -Taylor > > > > On Nov 7, 2017, at 7:32 PM, Julien Le Dem <[email protected]> > wrote: > > > > Sorry for the late reply. > > +1 to moving to apache git first. > > +1 on using gitbox so that the github repo is writable. That should > > simplify a lot of things. > > When we migrated parquet, we first moved the code to apache git and only > > later renamed packages to the new org.apache.parquet namespace. > > For java artifacts. I'd recommend renaming packages and maven group in > the > > same release to avoid weird dependency conflicts (you don't want 2 maven > > artifacts with different coordinates but same class name). If you follow > > this convention, you force yourself to post org.apache maven artifacts > only > > once you rename your packages. > > We still did a few twitter releases while the projects was not ready yet > to > > make apache release (updating the build, notice, etc). It is ok but it > must > > be very clear that those are not official apache releases. Official > Apache > > releases must be voted on by the PMC (and the IPMC in the incubator). And > > you need to make sure you're still mking progress towards apache official > > releases which is the point of the incubation. > > > > > > > > On Sun, Oct 29, 2017 at 8:27 PM, Jacques Nadeau <[email protected]> > wrote: > > > >> I don't believe the location of the code influences the type of release > >> allowed. For example, I believe the Parquet project to did a non-Apache > >> release after migrating. Maybe Julien can confirm that. Or Jake/another > can > >> reconfirm/refute my memory. > >> > >> > >> > >> > >> > >> On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham <[email protected]> > wrote: > >> > >>> Jacques, I was under the impression that once the code was imported to > >>> apache, releases had to be apache releases. This would require 1 and a > >>> number of other changes. Is that not the case? The motivation for > doing 1 > >>> first was so we could continue to cut releases as needed during that > >>> effort. > >>> > >>> On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau <[email protected]> > >> wrote: > >>> > >>>> I'm -0 on plan. > >>>> > >>>> Why not just import code then do changes 1 and 2 after 3? Just seems > >> like > >>>> getting 3 done is a key blocking item on forward progress of the > >>> community. > >>>> > >>>> On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni" <[email protected]> > >> wrote: > >>>> > >>>>> +1 > >>>>> > >>>>> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham <[email protected]> > >>>> wrote: > >>>>> > >>>>>> Any other comments on this proposal from Heron developers? The next > >>>>> podling > >>>>>> report is due on Wednesday so we should address our plan. > >>>>>> > >>>>>> On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament < > >>> [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> If you do in fact want to use gitbox (which allows you to have > >>> github > >>>>>>> writable repos), infra will need to be made an admin on your > >>>>> organization > >>>>>>> temporarily to do the migration. > >>>>>>> > >>>>>>> Many new projects are doing this, so it's not uncommon to just > >> use > >>>>> gitbox > >>>>>>> since you're already on github. > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>> On 2017-10-19 13:20, Brian Hatfield <[email protected]> > >> wrote: > >>>>>>>> Thank you both for the info :-) I had not realized it would > >> just > >>> be > >>>>>>>> re-homed in a different Github org. Thanks! > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham < > >>>> [email protected]> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Right, it would still be on github, just at apache/heron > >>> instead > >>>> of > >>>>>>>>> twitter/heron. > >>>>>>>>> > >>>>>>>>> On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell < > >>>> [email protected]> > >>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Apache git can also refer to the Github Apache org as a > >>> number > >>>> of > >>>>>>>>> projects > >>>>>>>>>> are running in that fashion. They key is that the code has > >>> been > >>>>>>> imported > >>>>>>>>>> over to the Apache Infra owned/managed infrastructure > >>>>>>>>>> > >>>>>>>>>> -Jake > >>>>>>>>>> > >>>>>>>>>> On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield < > >>>>>>> [email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Silly question - and apologies if this has already been > >>>>> discussed > >>>>>> - > >>>>>>> but > >>>>>>>>> is > >>>>>>>>>>> #3 (Migrate the code to Apache git) required? From my > >>>>> perspective > >>>>>>> Github > >>>>>>>>>>> is > >>>>>>>>>>> much more preferable as it's where nearly every other open > >>>>> source > >>>>>>>>> codebase > >>>>>>>>>>> I interact with is, and the UI is very friendly to > >>> newcomers. > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham < > >>>>>> [email protected] > >>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> In LEGAL-339 < > >>>> https://issues.apache.org/jira/browse/LEGAL-339 > >>>>>> > >>>>>>> it was > >>>>>>>>>>>> concluded that we can in fact move the code to Apache > >> git > >>>> and > >>>>>> cut > >>>>>>>>> Apache > >>>>>>>>>>>> releases without the SGA. I propose we move forward on > >>>> that. I > >>>>>>> suggest > >>>>>>>>>>> the > >>>>>>>>>>>> following plan: > >>>>>>>>>>>> > >>>>>>>>>>>> 1.a Refactor all Heron build dependencies (mainly c++ > >>> libs) > >>>> to > >>>>>> be > >>>>>>>>>>> fetched > >>>>>>>>>>>> at build time and not committed in the repo. (#2092 > >>>>>>>>>>>> <https://github.com/twitter/heron/issues/2092>) > >>>>>>>>>>>> 1.b Refactor the bazel checkstyles to support both the > >>>> Twitter > >>>>>>>>> copyright > >>>>>>>>>>>> (for existing code) and the Apache copyright (for new > >> code > >>>>> after > >>>>>>> the > >>>>>>>>>>>> migration). > >>>>>>>>>>>> 2. Cut the last non-Apache release. > >>>>>>>>>>>> 3. Migrate the code to Apache git > >>>>>>>>>>>> 4. Add incubation disclaimer > >>>>>>>>>>>> 5. Cut the first Apache release. > >>>>>>>>>>>> > >>>>>>>>>>>> What do folks think of that plan? Item's 1a and 1b can > >>>> happen > >>>>> in > >>>>>>>>>>> parallel, > >>>>>>>>>>>> as could item 2 actually. There will surely be more > >>> smaller > >>>>>>> items, but > >>>>>>>>>>>> those are the big ones as I see it. Please chime in if > >>> I've > >>>>>>> overlooked > >>>>>>>>>>>> anything major. > >>>>>>>>>>>> > >>>>>>>>>>>> thanks, > >>>>>>>>>>>> Bill > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>> Sent from Gmail Mobile > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> -- > >>> Sent from Gmail Mobile > >>> > >> > >
