search

graphite-project / graphite-web

A highly scalable real-time graphing system
http://graphite.readthedocs.org/
Apache License 2.0
5.89k stars 1.26k forks source link

Next Release? #677

Closed esc closed 8 years ago

esc commented 10 years ago

How does everyone feel about cutting a new release? I think it's high time, there are many new features and several bugs that have been fixed. The questions that nag me is how to release? I couldn't find any maintainers notes anywhere and there are many small details to be taken care of. Let me sketch some bullet-points from my previous experience releasing software, these can serve as a skeleton to be expanded.

Some things to note:

brutasse commented 10 years ago

:thumbsup:

It'd be nice to have a release branch, like with 0.9.X. That way you create the branch and can do all release-related things there (RC, etc) without having to freeze master. When fixing things, fix in master and backport to the release branch. I fear that some issues will reappear with the release as some fixes only made it to 0.9.X and not master.

Regarding the docs, they are built automatically on readthedocs: http://graphite.readthedocs.org/ (someone with enough permissions please replace the project URL with that, the repo home on GitHub still points to wikidot). So IMO no action is required here. Just mark the 0.10.0 release notes as final when cutting the release.

Carbon & whisper releases are needed as well, with some pull-requests cleanup on these projects. Ceres has never been released so far so I don't know what the status is.

esc commented 10 years ago

I would prefer to prep and cut the release from master. Release branches are useful if you want to continue development during a release time. Also, I think it is simpler to just use master, no need to backport or forwardport.

Regarding the project url, I have no ownership over th organization. I think it needs to be someone who does have that. @obfuscurity would you do use the honours? :)

obfuscurity commented 10 years ago

Yes, I think we all agreed some time ago to focus on cutting our next major release (0.10) from master. I'd like to see any glaring fixes applied to 0.9.x but we need to put that cow to pasture, so to speak.

I'm happy to tag a pre-release candidate but I feel like we need to comb through the issues and PRs for any glaring fixes that should be included in a RC.

esc commented 10 years ago

@obfuscurity I agree that as many glaring things should be applied as possible. However, there are really a ton of PRs and Issues and sometimes it is better to release (ship) something that is adequate, rather than wait until it is perfect.

For sorting issues, I would suggest to use the 0.10 milestone to flag anything that should absolutely go into 0.10:

https://github.com/graphite-project/graphite-web/issues?milestone=2&page=1&state=open

So currently there are 8 issues remaining. Does that mean: a) there are only 8 left to go? or b) that we still need to sift through the remaining 278 issues and 72 PRs?

In the Numpy project the releases usually start with a request on the mailinglist, for anyone to speak up about issues that they thing should absolutely be resolved before the next release. This is nice, because it doesn't require the maintainers to sift through each and every one of the issues, which in the case of graphite(-web) is quite a daunting task.

So, perhaps we can find a common ground where we say, the following issues will be fixed within a pre-defined time-period that we can commit to, and everything else will be sorted later. Also, for any major issues, security, grave functionality impediments, we can always push maintenance releases of the form 0.10.X.

timbunce commented 10 years ago

I strongly agree that getting into a regular release cycle is more important that worrying too much about combing the backlog.

Some suggestions that I've seen work elsewhere:

What I've seen happen before is that each volunteer will polish and automate the process a little. Soon you'll have a release process that takes very little effort plus a pool of people with experience making releases.

The key point is that working on smoothing out the release process is an investment that will be more than paid back. Once momentum is restored to the project more people will be motivated to contribute and the backlog will be unblocked.

steve-dave commented 10 years ago

At this stage I won't comment on how to structure releases. There are a lot of good ideas here but I'm new to the project and wouldn't feel confident in suggesting how to go forward in that respect.

However, I would like to see at least one more 0.9.x release. As far as I know it is considered the "stable" release, but currently Graphite things just don't work if 0.9.x is checked out from all 3 repos. I have opened a number of PRs across the 3 repos that get the branch to the point where it does run and it would be great if they could be merged and then a new, possibly final, 0.9.x release tagged. I have one more 0.9.x branch in the works that doesn't have a PR here, but it is only a backport of a performance improvement so it wouldn't matter so much if it wasn't accepted here - my main interest is in getting 0.9.x across all three repos running out of the box.

It's entirely possible that master is almost ready for a 0.10.x, but I'm not sure that it would be ready to be the new "stable" release as it has quite a bit of new functionality in it that may not be complete or well tested. For this reason, IMHO, it would be best to keep 0.9.x going at least there is a new "stable".

Thanks!

obfuscurity commented 10 years ago

I would love to see a 0.9.x release come out soon and then have someone step up to take over the project leadership. Sadly I don't have much time to work on the project these days and I don't expect that to change anytime soon. Personally, I see projects like graphite-api and cyanite as the future of the Graphite community, but clearly a lot of folks would like to see something official come out of the official project for their short-term upgrade path.

Is anyone willing to help massage the next release into shape?

steve-dave commented 10 years ago

I am happy to be involved in the next (which obviously may be the final) release(s) of 0.9.x, but I'm not familiar enough with master to know if I have the bandwidth to be (heavily) involved in 0.10.x. I have a number of PRs pending for 0.9.x (various fixes and backports to get the branch back to running out of the box) that could be the makings of 0.9.13-pre and I'd be happy investigate bug reports relating to the pre-release once it has been tagged. Of course I'd be happy to help review any other PRs that it is thought should be included as well, but perhaps anything other than bugfixes could be postponed till at least 0.9.14?

SEJeff commented 10 years ago

I'll have from Saturday through Thursday evenings completely uninterrupted to go through and merge a lot of PRs. I'll make a special point to look through all of your outstanding ones. Sorry but we've been busy with real life things unfortunately.

steve-dave commented 10 years ago

Thanks Jeff. Totally understand the real life side of it, was more offering help than expecting anything. Once again, if I can help, let me know.

esc commented 10 years ago

I gather that it isn't clear if we should release a 0.9.x maintenance release or/and a 0.10.x release. We have been using the current master (plus some additional feature branches) in production since April w/o any issues. What are you guys using in production?

The problem with having a 0.9.x and a 0.10.x simultaneously that it is a bit of a split brain situation, and having to supply two branches with fixes and updates is somewhat of a maintenance nightmare.

As you can see here:

zsh» git log --oneline master..0.9.x | wc -l
200
zsh» git log --oneline 0.9.x..master | wc -l
641

the two branches have diverged quite a lot. Note however that this does not take into account any commits that have been cherry picked.

If we do decide to to go for a 0.9.x, for which I do sense some momentum, we should use the 0.9.13 milestone, for which there are already some issues:

https://github.com/graphite-project/graphite-web/issues?milestone=4&page=1&state=open

esc commented 10 years ago

BTW: tests for 0.9.x are currently passing:

https://travis-ci.org/graphite-project/graphite-web/builds/19817617

Also, we should favor bugfixes only for 0.9.x as @steve-dave suggested and additionally reject anything that isn't tested in one way or another.

brutasse commented 10 years ago

Some fixes even made it to 0.9.x but not to master. I tried to resync things once but gave up… +1 for bugfix-only branches.

steve-dave commented 10 years ago

I agree it's quite concerning how far the branches have diverged. I still feel that 0.9.x should be maintained until 0.10.x is released and becomes the official stable, perhaps put a line in the sand at 0.10.1 or 0.10.2? Any fixes that are applicable to both branches should be applied to both branches until 0.9.x is final (certainly not just to 0.9.x) - I'm not sure the preferred procedure for this but I have just been opening a PR for each branch rather than leaving it to the person that merges to have to port it. If someone else doesn't get to it first I will review the fixes that have been applied to 0.9.x and port them to master where applicable.

drawks commented 10 years ago

The repo organization aspect of this is really the most difficult part to sort out in my opinion. I'm not sure how to dig out of the current mess, but the end result should look like:

  1. Active development is all based against Master and no feature branches should be maintained in the official git project.
  2. Major versions should cut be cut into separate maint. branches for continued support in the form of bugfixes and once they are ~2 majors behind they should either be abandoned or be kept around only for critical security fixes.
  3. All PRs for merge into master should be squashed into single commits and should include a concise description of their intended behavior AND a unit test to match. Only PRs which are pure refactors of code which is already covered by existing tests should be accepted without tests.
  4. Some sort of automated/scripted procedure should be adopted for cutting new versions which should handle the work of updating all relevant version strings AND ideally updating a CHANGELOG document which would be initially synthesized from commit messages, but should be massaged into something readable by whoever is cutting the release.
  5. All of the above along with any suggested workflow should be codified in a CONTRIBUTING file at the base of the project to provide guidance for contributors. Additionally we might consider adding a FAQ section to this document to address questions which have been asked and answered before i.e. Why isn't this project PEP8 style compliant?

edit: This is all just a suggestion from my point of view and one that I've made before in other channels. None of the above should be construed as me dictating new policy or assuming a role of leadership in the project; I've got too much other stuff going on to bite off a bigger chunk of graphite.

torkelo commented 10 years ago

I would like to help any way I can. Mostly I would like to create a new home page for graphite on a domain like graphite.org (or similar), with updated install guides, links to read the docs, download links, links to graphite-api etc. And usage screenshots & diagrams to show of what graphite can do.

obfuscurity commented 10 years ago

I had intended to build up something similar to Sensu's website for Graphite but never got around to it. I have the graphiteapp.org domain registered if anyone wants to use that.

esc commented 10 years ago

I agree that cleaning up the repo structure in the long run is something to aim at. Also having a nice a website under a good domain-name is something to aspire to. However, given the recent dilemma we are in, I would like to focus on getting a release out the door that fulfills the minimum requirements -- something like a minimum viable release.

From what I gather here, maybe a 0.9.13 release would be a good interim solution, but I still don't have an idea what you guys use in production. Anyway, to move towards that release, we will only merge bug-fixes that have tests.

@steve-dave you said you had some pending pull requests? I would like to take up your offer of looking into those for the 0.9.x release. Perhaps you could point the people with appropriate privileges that are reading this thread: (@esc, @obfuscurity, @SEJeff, @drawks. others?) to any bugfixes you would like to have included. Of course this also goes for anyone else reading this thread, who has commits that they feel need to be applied to 0.9.x

From a maintainers / release managers point of view, here is a small checklist for evaluating if a commit is suitable:

If you encounter a commit which you can not deal with immediately, please set the 0.9.13 milestone, to make sure we have a list of things that need to be done:

https://github.com/graphite-project/graphite-web/issues?milestone=4&page=1&state=open

Also, again, what do you guys use in production?

Also does anyone feel like we need, or would prefer to have a mailinglist for this project. I sometimes miss being able to answer in-line when discussing with github issues?

steve-dave commented 10 years ago

@esc FWIW we are currently running the 0.9.x branch in production with a handful of patches that I have created pull requests for to be considered for merging.

Would you like the 0.9.13 candidate pull requests highlighted here in this thread, tag those with permissions in the actual PRs, or highlight them in some other way? I apologise if this is obvious, but I am new to both this project and Github. Also, should I include carbon and whisper PRs or are they handled by different people?

esc commented 10 years ago

No problem, by highlighting, i meant, just writing the name, e.g. @esc in the issue. That way you will draw mine (our) attention to this pull-request so that it can be considered.

Regarding whisper and carbon, I realized earlier today, that the current 0.9.x branch of graphite-web actually needs a whisper from its master. This would indicate that maybe new releases of both projects would also be required.

esc commented 10 years ago

@steve-dave not sure yet who or how whisper and carbon will be handled.

steve-dave commented 10 years ago

@esc Is there a deadline or target date? I've lost a couple of days to miscellaneous issues and haven't been able to go through the PRs yet...

esc commented 10 years ago

No, as long as we keep momentum, it will be ready when it is ready. Importantly, motion towards the release should not stagnate.

toni-moreno commented 10 years ago

Hi Guys.

first I would like to say thanks to @obfuscurity @esc @brutasse @timbunce @steve-dave @SEJeff @torkelo @drawks @timbunce and all the other collaborators who created and are maintaining this great tool.

I'm new in the project ,and I would like to help you as much as possible (I will dedicate as time as my son my wife and my job let to me) .

I think there was in this thread very good ideas on how to manage the github repositori ,so I prefer ( by now) not enter in this discussion.

We are planning to build a big graphite platform and I'm installing from the current master repository for graphite-web, whisper and,carbon. But we need some new features and we are coding these. We have some proposed PR's to add a few interesting new features on the 0.10 milestone. ( I would like contribute from these release)

https://github.com/graphite-project/graphite-web/pulls/toni-moreno

I have experience on proprietary tools like ( CA-Wily Introscope ) , that gave me some good ideas to improve Graphite-web, and I would like to contribute with these new features.( https://github.com/graphite-project/graphite-web/issues/721 )

I'm waiting now on your feedback and perhaps a new "Roadmap" discussion and instructions for what to do to help all you.

esc commented 10 years ago

@toni-moreno thanks, your help is much appreciated. We are currently focusing on a 0.9.x release and as such we need to handle all the issues in:

https://github.com/graphite-project/graphite-web/issues?milestone=4&page=1&state=open

And potentially tag more with the 0.9.13 milestone so that we can track open things better.

We have pretty much agreed that we will only add bugfixes -- no new features -- to the 0.9.13 release and that any bug fixes really should include some tests.

If you would like to help out, take a look at the issues in the 0.9.13 milestone and see if you can help out with any of those. Also, if there are any issues or pull-requests you see, that should be part of the 0.9.13, you can highlight me using @esc and I'll add them to the milestone.

I am hoping that once the 0.9.13 release is out -- which should hopefully be the last one in the 0.9.x series -- we as a community can focus on moving forward, and get 0.10 released.

esc commented 10 years ago

FYI: I am also available on freenode as esc in case you need me in (semi-)realtime.

toni-moreno commented 10 years ago

Hi @esc I would like to help you with 0.9.13 , but we are already working with current master branch 0-10-beta and with our PR from 0.10.
It is too late for us revert to previous version and remake the new features we need to work. And as I said previously I have not time enough to spent on this release.

What I will do sure (mandatory on my job) is a complete testing of the current master releases for graphite-web, carbon and whisper ( on a big production environment) and I will report you ( and fix myself when I can and I have enough acknowledgement) all whatever we can see.

At the same time while you are working on both 0.10 and 0.9.13 I will try to follow all your discussions and take part on them waiting to resume the 0.10 development.

I hope you can let me take part on the discussion and development for define the 0.10-beta milestone and roadmap for the following releases.

esc commented 10 years ago

@toni-moreno we use current master in production too, with a number of patches, of course. Regarding the 0.10 release, please be patient, we are quite understaffed as a community, but I hope that will get around to it soon.

esc commented 10 years ago

I have updated the 0.9.13 to be due by Jul 11 2014, it's just an arbitrary date in the future, if we make an rc1 by then, good, if not, we can always extend it.

toni-moreno commented 10 years ago

@esc OK! I will wait !! Thanks a lot !!

esc commented 10 years ago

Adding to 0.9.13 milestone to track the release, cc @obfuscurity

obfuscurity commented 10 years ago

I'd like to propose that we pin to Django >= 1.5 and backport the fix for Django urls.

hggh commented 10 years ago

I'm also interested in a new release of graphite-web. (I'm the debian maintainer) The current release 0.9.12 does not work any more with new Django 1.7 from debian experimental and newer Python libraries from Debian unstable. so .. :+1:

brutasse commented 10 years ago

@obfuscurity why the need for Django >= 1.5? There is very little django in graphite-web, it's easy to support 1.3 all the way to 1.7 (unreleased but coming at some point).

obfuscurity commented 10 years ago

@brutasse I inferred that Django 1.5 introduced the urls breakage, based on this commit.

brutasse commented 10 years ago

@obfuscurity with this pattern:

try:
    from django.conf.urls import patterns, url, include
except ImportError:
    from django.conf.urls.defaults import patterns, url, include

You get Django 1.3+ support with no warning at all.

The order is currently reversed, meaning Django 1.3 and 1.4 work but get a warning.

https://github.com/graphite-project/graphite-web/blob/0.9.x/webapp/graphite/urls.py#L15-L18

obfuscurity commented 10 years ago

@brutasse :cool:, I'll work on getting a PR for that in 0.9.x today.

obfuscurity commented 10 years ago

Argh, never mind. I see that the urls issue should be completely resolved in 0.9.x thanks to https://github.com/graphite-project/graphite-web/commit/ba3acd257530448e82e5654e4d74a57df9803106. Thanks to @brutasse for the correction and to @esc for the aforementioned commit.

obfuscurity commented 10 years ago

I've gone through the graphite-web, carbon and whisper projects to identify any issues or PRs that should be included for the 0.9.13 milestone. Here are the current totals (not counting this issue):

esc commented 10 years ago

@obfuscurity :dancer:

gwaldo commented 10 years ago

Does anyone have rights to the RTD site? I've seen it updated automagically, and as an Ops-guy, I thoroughly appreciate that.

I poked around RTD's RTD, and discovered their Build Process doc.

Can someone with rights to our project drop in the Settings menu, and check whether we have a Webhook configured? I don't have rights to modify settings (nor do I need them.)

obfuscurity commented 10 years ago

@gwaldo I thought I did but I was mistaken. Working on getting these for myself, will report back.

gwaldo commented 10 years ago

Speaking of docs, does anyone have a doc / notes / scripts / omnious-puzzle-box that helps with releases?

d7a8fbd6d9e8ad3667896099ad38a8c9

obfuscurity commented 10 years ago

@esc made some notes at the top when he opened this issue.

obfuscurity commented 10 years ago

@gwaldo Sorry, I was thinking you were referring to a setting in RTD. Yes, we're using the RTD service with the graphite-web project in GitHub.

gwaldo commented 10 years ago

@obfuscurity Actually, it was both.

I took the notes at the top to be "I don't know how it is supposed to be done, but here's what I would do".

As far as RTD, I know we're using it, but I was curious if anyone had credentials to RTD, and if we have a webhook set up on the repo.

nox commented 10 years ago

So, still no new release? No new 0.9.x either with the new backports…?

brutasse commented 10 years ago

@nox here's the milestone for 0.9.13: https://github.com/graphite-project/graphite-web/milestones/0.9.13

nox commented 10 years ago

That's not an ETA, is it? The holtWintersAberration bug have been reported for ages and makes Graphite mostly unusable for forecasts. Why should a release including it be stalled for bugs reported a couple of weeks ago?

obfuscurity commented 10 years ago

@nox Bugs are bugs, whether they were reported 1 week ago or a year and a half ago. We appreciate your patience while we clear out the rest of the milestone in preparation for a new release. Thanks.