Would it make sense to have a wiki page on the status of a release, including any outstanding bugs and whether it is still open for updates? I know we have email for this, but in looking over my email, I'm uncertain as to the status or even the value of x. Bill On Nov 30, 2010, at 11:32 AM, William Gropp wrote:
Thanks - I do filter mpich2-core, so cc'ing me doesn't help (that would be a useful mailer feature - overriding the filter for a list when explicitly included).
I've add this to the release page since I have it handy.
Bill
On Nov 30, 2010, at 10:25 AM, Rajeev Thakur wrote:
Bill, I have already merged r7447 from trunk to 1.3.x, but it can be done as follows:
% check out 1.3.x branch % cd into it % svn merge -c 7447 url-of-trunk . % commit
That's it.
Also, in case you are filtering mpich2-core into a read-occasionally folder, such mails (about 1.3.x) get sent there. Pavan also CCed you explicitly on some mails, but the mailer may not send it separately if you are already included in the list (at least some times it happens that way).
Rajeev
On Nov 30, 2010, at 10:01 AM, William Gropp wrote:
Pavan,
This is the first that I've heard of the 1.3.x branch - I don't even know how to do this for svn (I did know how to do it for cvs).
Is this on the wiki? I looked at http://wiki.mcs.anl.gov/mpich2/index.php/Creating_a_Release , but that suggests that a release is created from the trunk and not updated after that (except for critical fixes in the release), which is why I've tried to get things into the trunk as soon as possible.
Anyway, if you can tell me what svn commands to use and what fixes you'd like me to add, I'll be happy to do it.
(I'll put in a plea to remember that it is also everyone's responsibility to keep the documentation, both on the release process and the design documents, up to date - that discipline will save a tremendous amount of time for everyone else.)
Bill
On Nov 19, 2010, at 3:21 PM, Pavan Balaji wrote:
All,
There will very likely be a 1.3.2 release (and possibly more in the 1.3.x series) given that 1.4 has many planned features and is almost an year away.
So, whenever you commit any bug fixes to trunk, remember that it is your responsibility to merge them into the 1.3.x branch -- do not wait for someone else to do the merge for you. Features that change ABI compatibility (such as adding MPI-3 features) should not go into 1.3.x.
I see that some of the windows commits (r7442, r7443, r7444, r7445) have not been merged, which I'm assuming is intentional.
Bill: r7447 looks like a bug-fix. Can you merge it into the 1.3.x branch?
Dave: r7462 adds the qsort capability to Comm_split. Can you merge it into the 1.3.x branch?
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign