In principle I agree with this, but creating a new release will be a little more involved that just running maven, when we do this at the ASF. To publish a new release we will have to vet and vote on the release. This takes at least 72 hours in the best case if we’re a TLP, the first release candidate is great, and have enough people to vote. While we’re still in the incubator, releasing will take a little longer as we also have to get enough votes for the release in the incubator. As I proposed earlier, it would be really good to go through the full release process once, before we decide how to structure our processes and infrastructure.
Cheers, Till > On Jun 4, 2015, at 6:37 PM, Ildar Absalyamov <[email protected]> > wrote: > > I am with Chris on repository separation and I think that the solution to the > issue of Hyracks commits breaking Asterix build is using release Hyracks > versions instead of snapshot ones. Yes, that will create a frequent Hyracks > releases (we will have to release it each time there is a change which spans > both Hyracks & Asterix) and we have abandoned this practice a while ago, but > it seems that’s the only way to separate projects logically. > > Here are few examples to clear the picture. In all examples Hyracks version > is 4.5.6-Snapshot, Asterix version is 1.2.3-Snapshot (but it depends on > previous release version Hyracks 4.5.5): > 1) The changes span both Asterix & Hyracks. > First make sure that Asterix could depend on Hyracks 4.5.6-Snapshot without > API conflicts & switch Asterix dependency to 4.5.6-Snapshot. > Submit Gerrit review, once it is done as a part of git-asf script commit > changes, bump Hyracks version to 4.5.6, make Asterix depend on 4.5.6 and bump > Hyracks to 4.5.7-Snapshot right after. > 2) The changes are located only in Hyracks. Regular review and commit (with > snapshot version) without any version bump. > 3) The changes are located only in Asterix. Regular review and commit (with > snapshot version) without any version bump. > > In this scenario Hyracks commit can never make Asterix build fail (since it > depends on a stable release) and it’s the responsibility of the first person, > whose commits spans both repos to make sure that the changes in snapshot > Hyracks version are properly merged. > > Regarding the Yingyi’s issue with Gerrit topics: could we modify git-gerrit > script so it would submit both Asterix & Hyracks reviews (granted that the > latter is needed), and link them together, setting the proper topic? Gerrit > seems to have API for changing that, right? > >> On Jun 4, 2015, at 15:45, Mike Carey <[email protected]> wrote: >> >> Just a quick high-level note from our nearest equivalent of the >> pointy-haired Dilbert guy (aka me): What would be nice is to have Hyracks >> changes kick off tests of all "supported client projects" - AsterixDB, >> VXQuery, maybe also Pregelix, IMRU, and possibly others in the future. I >> don't think we'll ever prevent such downstream things from being broken >> unless we run their tests - so I would suggest that we need a mechanism to >> keep Hyracks changes from being permitted to happen without verifying the >> ongoing integrity of all "blessed" (priority 1) affected projects.... We >> could have an agreed upon list of such projects and tests for each.... It >> would be nice to have a "quick check" (hello world still works, basics are >> working) that was synchronously blocking of such changes, and at least a >> daily verification that all's totally well (AFAWK) for them all. >> >> Not sure how this affects the still two-sided discussion... :-) >> >> Cheers, >> Mike >> >> >> On 6/2/15 10:00 AM, Chris Hillery wrote: >>> On Mon, Jun 1, 2015 at 9:46 PM, Yingyi Bu <[email protected]> wrote: >>> >>>> In my opinion, merging the repository doesn't break the separation of >>>> hyracks and asterixdb, because the dependencies are controlled by mvn pom >>>> files. >>>> >>> That wasn't the separation I was talking about. I meant API separation. As >>> it is now, when we make a change to both Asterix and Hyracks, we are forced >>> to consider the API implications, or at least they are put out there in a >>> very clear way that we need to look at. If we merge them, people will >>> (rightly) treat the whole thing as one product, and there will be no brakes >>> on making wide-ranging API changes. >>> >>> (As an aside: I don't trust Maven's pom files to do a good job of keeping >>> the dependency management clean. In fact I trust it to do precisely the >>> opposite, by making it both easier to screw up the dependencies and harder >>> to update them in future.) >>> >>> Again, my point is this: If we truly believe that Hyracks is a re-usable >>> component, it should be treated as such from source to build to delivery. >>> By merging in Asterix, we are saying that Asterix is "more equal" than >>> others Hyracks clients, to the point that we're tacitly willing to break >>> those other clients in favor of simplifying Asterix development. If that is >>> a fair and true statement, well, then, sure, let's merge them. >>> >>> 1) It forces those hyracks-only changes to pass asterixdb regression >>>> tests. Currently hyracks-only change are not verified by asterixdb tests. >>>> >>> This is a good point, I will admit. However, I think this same goal can be >>> met in other ways. My strong preference would be to create a set of true >>> API tests inside of Hyracks, which both document and test the external >>> Hyracks API. That will make API-breaking changes in future much easier to >>> spot, and also make it clear when Asterix is using internal APIs that it >>> should not. >>> >>> >>>> 2) On my local machine, I don't need to always install hyracks and then >>>> verify asterixdb from time to time. Especially, switching branches seems >>>> painful because the installed hyracks snapshot is overwritten from time to >>>> time. >>>> >>> I haven't tried working on multiple Hyracks branches at the same time, so I >>> haven't experienced this. This seems like a working method error, though. >>> If you're working with two things that are "the same version" (even if >>> that's a snapshot version), you'll need to use separate Maven repositories >>> to install them. In fact, merging the two git repositories would do nothing >>> to fix this problem, will it? If the proposal is to put the two source >>> repositories in the same git repo but otherwise leave them untouched, then >>> nothing would change in the build process. It's possible I'm missing >>> something there, though. >>> >>> >>>> 3) I only need to make one code review request and one jenkins job. >>>> Currently I need to manually change the topic of my asterixdb gerrit CL >>>> every time before I update my hyracks CL, and then manually schedule >>>> jenkins to run a new asterixdb job. If I forget to schedule the jenkins >>>> job, the asterixdb CL is still shown to be "verified by jenkins". >>>> >>> This is a problem, but it's a problem in commit validation, not in the >>> source. Modifying the source to work around these issues is still a bad >>> idea IMHO. >>> >>> The "change-topic" issue could be fixed with a bit of development work >>> (have the topic point to a change, rather than a specific patchset on the >>> change, so you only need to set it once, for instance). >>> >>> As for manually scheduling Asterix Jenkins jobs, that sounds like it's only >>> a problem where your Hyracks change breaks an existing public API. That >>> would be obviated by having true API testing inside of Hyracks, which is >>> something that we should have regardless of any decisions about source >>> locations. >>> >>> In summary / repeating myself again: yes, we have some problems because >>> Hyracks and Asterix are in seperate repositories. But those problems are >>> pointing out true issues with our development and processes. Merging the >>> repositories isn't fixing those problems, it's sweeping them under the rug. >>> Long term we would be much better off to identify, isolate, and fix the >>> problems themselves. >>> >>> Ceej >>> aka Chris Hillery >>> >> > > Best regards, > Ildar >
