+1, just a few quick notes:
Am 08.10.2012 05:53, schrieb Aaron Meurer:
If anyone is interested, the current (and hopefully final)
blocker is https://github.com/sympy/sympy/pull/1561 (and I guess also
https://github.com/sympy/sympy/pull/1559).
That might be part of the problem: I have something different on my
agenda right now, and I guess it's similar for many others.
It's probably a good idea to give release blockers high visibility.
Say, a web page that lists blockers (could be a redirect to the proper
search results).
That way, people looking for "what's next" might get the blockers on
their shortlist.
So in case I didn't make my point, le me state it explicitly: we need
to release more often. We need to release *way* more often.
[...]
- I think that one other thing that has held back many releases is the
feeling of "wait, we should put this in the release". The use of a
release branch has helped keep master moving along independently, but
there still seems to be the feeling with many branches of, "this is a
nice feature, it ought to go in the release." My hope is that by
making the release process smoother, we can release more often, and
this feeling will go away, because it won't be a big deal if something
waits until the next release. As far as deprecations go, the real
issue with them is time, not release numbers. So if we deprecate a
feature today vs. one month from today, it's not a big deal (as
opposed to today vs. a year from today), regardless of how many
versions are in between.
+10.
2. There are a dozen things that need to be done when we release.
They are all outlined at
https://github.com/sympy/sympy/wiki/new-release. If you go through
that page, you will see that there really are a ton of things to do.
And some of them are even more than what the look at. For example, at
the end, there are 12 different independent sites that need to be
updated.
[...]
- We have to automate the release process. I'm referring specifically
to the stuff on https://github.com/sympy/sympy/wiki/new-release. We
should have some script, say bin/release.py, and to do a release, all
we should have to do is run that script. And literally everything
should be in that script. If there is some step in the release
process that is not automatable, we should either attempt to make it
automatable, or ask if it is really necessary to be done before each
release.
Third option: Make it part of the requirements before a pull request can
go in.
Example in point:
One thing that I already know will be an issue is the example
notebooks (see https://github.com/ipython/ipython/issues/1195). Also,
we will either need to automate the process of updating all the
various sites and packaging systems, or make concessions that someone
else will have to be responsible for doing so.
Here's how to make it part of the pull request:
1) Unify everything that needs to be updated into a single directory
tree, so people can make all the relevant changes part of the same pull
request and nothing gets forgotten. Here, the notebooks would become
part of that SymPy Release Tree.
2) If a notebook exercises a specific piece of Python code, they Python
code should mention that in a comment. Even better, write unit tests to
verify that the notebooks actually work.
3) Make the release script regenerate the notebooks from the SymPy
Release Tree.
I do not think that everything in the release process can be automated
or removed, but I think the inevitable manual intervention can be moved
into the pull request reviewing process.
- One thing that I know cannot be automated, but still needs to be
done is the release notes. If someone has any good ideas on how to
make this smoother, I'd like to hear them. One way would be to make
it a policy that a pull request containing major changes should not be
merged until those changes are documented in the release notes. I'm
doubtful of this, though, because policies are useless unless well
enforced.
Enforce it then as a part of the pull request policy.
The more important aspect: State that part of the policy.
Describe the line between changes that need and need not be described.
Perhaps it might be possible to have a tool that searches through the
git history and tries to heuristically tell what parts are major
changes. Maybe such a tool already exists?
Such a tool would have to emit the same output, whether the same set of
changes is pulled as a single request or split into a dozen small pull
requests.
I doubt that such a tool is even feasible.
Or, perhaps this problem will be solved if we can solve the other
problems. After all, if a release consists of only a few hundred
commits (or say, a few dozen pull requests), it won't be that big of a
deal to comb through them and write down what has changed.
Quite possible.
It's certainly not a decision that needs to be made early, since no
other decisions depend on it.
- Everyone, if they have push access, is also trusted enough to do a release.
I'd wait with that until the release process is indeed fully automated.
I'm not sure if we really want the possibility of a daily release. Well,
maybe we want the possibility, but we'll probably have nontechnical
issues to consider (such as not annoying users with daily updates vs.
fixing really important bugs). And we want to have these decisions to be
vaguely consistent, so it's going to be a single person who decides when
to release, even if the actual release is no big thing.
I'm not 100% sure whether I'm on spot with this though.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
