Alan, +1 on branching.
That said, I just filed https://issues.apache.org/jira/browse/HCATALOG-577 which details a bug that breaks pig queries using HCatLoader in conjunction with the distinct operator, followed by HCatStorer. I figure we're potentially breaking in a number of other ways, but this one is demonstrable. I think we should definitely have this fixed in this release, but whether or not we want to do this before we branch, or after we branch is something I don't mind either way on. -Sushanth On Fri, Dec 21, 2012 at 9:05 AM, Alan Gates <[email protected]> wrote: > I propose we push in the following three JIRAs: > > Add HideUtilityClassConstructor checkstyle rule > https://issues.apache.org/jira/browse/HCATALOG-568 > > test.sh should let users specify the ant version > https://issues.apache.org/jira/browse/HCATALOG-564 > > HCATALOG-527 Broke backward compatibility > https://issues.apache.org/jira/browse/HCATALOG-576 > > and then branch for 0.5. I'd really like to branch now because I am > concerned that otherwise we'll keep having new things come in. Obviously > this branch would still be open to any bug fixes. But the intent would be to > not add any new features. > > I'll take ownership of pushing in those three patches. > > Alan. > > On Nov 28, 2012, at 7:57 PM, Travis Crawford wrote: > >> I totally agree we should do as much as possible before Hive 0.10 is >> released, so we can quickly release afterwards. Towards that goal, I >> spent a bunch of time today reviewing the release process, and seeing >> what we can do now so we can release quickly when we're ready. >> >> I'd love if someone can take a look at >> https://issues.apache.org/jira/browse/HCATALOG-558 because that makes >> some critical fixes in our src-release ant target. Additionally, it >> updates test.sh to run tests from an extracted src-release artifact to >> prevent fixes like this from being needed in the future. >> >> We should update our CI jobs to run test.sh (after updating with the >> appropriate commands) so we're doing this on a regular basis, as well >> as producing/archiving the src-release artifact from CI. This will >> help make the current (and future) releases go very smoothly, as much >> of the process will be automated. >> >> Thanks! >> Travis >> >> >> On Wed, Nov 28, 2012 at 1:46 PM, Travis Crawford >> <[email protected]> wrote: >>> I just hopped in #hcatalog on freenode if anyone wants to discuss/help >>> with release prep. >>> >>> --travis >>> >>> On Wed, Nov 28, 2012 at 1:43 PM, Travis Crawford >>> <[email protected]> wrote: >>>> Totally agree we can parallelize some things. Here's a list of stuff >>>> we can do now to help us release faster: >>>> >>>> RELEASEAUDIT TARGET >>>> >>>> Part of our release process is running the "releaseaudit" target. >>>> AFAICT the only thing it does is check for appropriate file headers. >>>> We actually do this with checkstyle now. Is that target still >>>> necessary? Ideally we could add checkstyle targets for some non-java >>>> files if necessary so we have an enforcement mechanism that happes >>>> with each patch, rather than trying to fix this stuff at the last >>>> minute before releases. If we can finish up this issue that will help >>>> us get closer to making a release: >>>> >>>> releaseaudit target does not cover all code >>>> https://issues.apache.org/jira/browse/HCATALOG-446 >>>> >>>> >>>> BUILD RELEASE ARTIFACT FROM JENKINS >>>> >>>> Jenkins has a feature where each build can produce files that are >>>> archived as long as the build history is around. Currently we use this >>>> to archive the contents of our "package" target. Can we update the CI >>>> job configuration to also generate and archive the "src-release" >>>> artifact? That way, each build will show us what would be released if >>>> we chose to release at that point. That way, there will be no >>>> last-minute surprises as to the contents of our release artifact. >>>> >>>> Also, we've talked about this in the past, but I think we should >>>> checkin a script with the CI command so everyone's aware of what tests >>>> are run. We could update >>>> http://svn.apache.org/repos/asf/incubator/hcatalog/trunk/build-support/scripts/test.sh >>>> with the correct commands, then update our CI job to run that script. >>>> >>>> >>>> PUBLISH JAVADOC IN CI >>>> >>>> Jenkins has a feature where it can archive and serve javadoc for each >>>> build. Can we set this up for >>>> https://builds.apache.org/job/Hcatalog-trunk-build/, which I assume >>>> we'll clone for the 0.5 branch CI job. This will make viewing javadoc >>>> really easy so we can see what it looks like before the final release. >>>> Also, if we do find content/formatting errors it will be easier to >>>> discuss as we can send links to see what it actually looks like. >>>> >>>> >>>> Actually branching seems like the easy part of making a release. If we >>>> can get the above items resolved we'll be in good shape to release >>>> really quickly after Hive releases. I can take care of the >>>> "releaseaudit" issue after getting more info. Can someone with CI >>>> permissions take care of producing+archiving the src-release artifact >>>> and publishing javadoc? >>>> >>>> Thanks! >>>> Travis >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Nov 28, 2012 at 1:11 PM, Alan Gates <[email protected]> wrote: >>>>> I agree we shouldn't cut an rc before Hive ships. In my experience >>>>> there's usually a week or two of bug fixing between branching and rolling >>>>> an rc. That's what we can parallelize. If we're confident we can roll >>>>> an rc immediately after branching then I'm fine with waiting to branch. >>>>> But I do not share this confidence. >>>>> >>>>> Alan. >>>>> >>>>> On Nov 28, 2012, at 11:26 AM, Travis Crawford wrote: >>>>> >>>>>> On Wed, Nov 28, 2012 at 11:10 AM, Alan Gates <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> We definitely cannot release HCat 0.5 before Hive 0.10. But I don't >>>>>>> think >>>>>>> we need to wait to branch. Why not branch now and start fixing issues >>>>>>> and >>>>>>> then update the dependencies once Hive ships? >>>>>>> >>>>>> >>>>>> Doing QA on a moving target seems challenging – I'd prefer to ask people >>>>>> to >>>>>> spend their time testing legitimate release candidates. If we're blocked >>>>>> on >>>>>> making a release candidate until Hive ships, there's no need for a >>>>>> release >>>>>> branch yet. Prematurely branching means we have to track changes in the >>>>>> release branch & trunk, which is work we can avoid. >>>>>> >>>>>> I'm not totally against branching now, but it seems like additional work >>>>>> for no gain. >>>>>> >>>>>> Does anyone have more insight into Hive's release ETA? >>>>>> >>>>>> --travis >>>>>> >>>>>> >>>>>> Alan. >>>>>>> >>>>>>> On Nov 28, 2012, at 11:03 AM, Travis Crawford wrote: >>>>>>> >>>>>>>> Hey hcat gurus - >>>>>>>> >>>>>>>> Regarding the 0.5 release, I'd like to postpone branching until Hive >>>>>>> 0.10.0 >>>>>>>> ships, as we cannot release with snapshot dependencies. >>>>>>>> >>>>>>>> Proposal: >>>>>>>> * Keep working on items with a target fix of 0.5 until Hive ships >>>>>>>> * Branch when hive 0.10.0 ships, and post a release candidate >>>>>>>> * Punt everything not yet complete to the next release >>>>>>>> * Budget ~1 week for people to test, more if issues are discovered >>>>>>>> * Ship it! >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> --travis >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 21, 2012 at 2:17 PM, Travis Crawford >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Status update: >>>>>>>>> >>>>>>>>> Thanks all for doing some jira cleanup and finalizing the list of >>>>>>>>> outstanding issues for 0.5. Open issues scheduled for inclusion are >>>>>>>>> available here: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HCATALOG+AND+fixVersion+%3D+%220.5%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide >>>>>>>>> >>>>>>>>> The plan is to branch next Tuesday, and hopefully release by EOW. As >>>>>>>>> the schedule is tight, please be mindful of the review queue so we can >>>>>>>>> get through these open issues. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Travis >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 19, 2012 at 11:21 AM, Travis Crawford >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Also, if we don't already have one I'd like to volunteer as the >>>>>>>>>> release manager. I've never done one before and would like to learn >>>>>>>>>> the process. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Travis >>>>>>>>>> >>>>>>>>>> On Mon, Nov 19, 2012 at 10:57 AM, Travis Crawford >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> I'd love to start thinking about a 0.5 release, but let's hold off >>>>>>>>>>> on >>>>>>>>>>> branching until we understand a bit more about what we're releasing. >>>>>>>>>>> >>>>>>>>>>> As a first step, can everyone make sure the "Fix Version/s:" field >>>>>>>>>>> says 0.5.0 for issues you're hoping to have included? >>>>>>>>>>> >>>>>>>>>>> You can view the full list of unresolved issues associated with >>>>>>>>>>> 0.5.0 >>>>>>>>> here: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HCATALOG+AND+fixVersion+%3D+%220.5%22+AND+resolution+%3D+Unresolved+ORDER+BY+due+ASC%2C+priority+DESC%2C+created+ASC&mode=hide >>>>>>>>>>> >>>>>>>>>>> Also, for committers, if you can make some time for reviewing patch >>>>>>>>>>> available issues that would be much appreciated. Its discouraging >>>>>>>>>>> for >>>>>>>>>>> contributors to have their patches linger. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Travis >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 19, 2012 at 10:32 AM, Daniel Dai <[email protected]> >>>>>>>>> wrote: >>>>>>>>>>>> Hi, folks, >>>>>>>>>>>> How about branching 0.5 for 0.5.0 release? Hive will release 0.10.0 >>>>>>>>>>>> soon (http://www.mail-archive.com/[email protected]/msg24708.html >>>>>>> ), >>>>>>>>>>>> sounds like it is a good time to make a HCatalog release as well. >>>>>>>>>>>> Thoughts? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Daniel >>>>>>>>> >>>>>>> >>>>>>> >>>>> >
