Evening everyone! So the 1.4.0 release is finally completed after much delay (my bad, my apologies!), and now we're already moving up to 1.4.1. Tonight I did quite some merging into the release_1_4 branch of some of the work that has been happening on trunk, but not all of it. I'm currently leaving out: 1) r23242: Ignoring SSL certificates; 2) r23098, r23125, r23238, r23248, 23362 and 23552: "New options for configure flags (C|CPP|CXX|LD)FLAGS and logic to handle that and backward compatibility." per Paul's commit log (original and subsequent commits); 3) r23246, r23249 and r23291: New -I${prefix}/include and -L${prefix}/lib compile time flags; 4) r23549, 23550 and r23553: Moving port tests into a test subfolder in order to portindex them; 5) Universal variant. On the one hand, I can't find my commit log mails for the work on the universal variant, so I'd appreciate it if someone could annotate my list with the proper revision numbers; and on the other hand, I'm not sure if 2) and 3) can be split like that, so (Paul) do correct me if I'm wrong. In any case, I'd like to discuss which of those changesets we're going to be including in 1.4.1, so everyone should feel free to ventilate all the pro's and con's about each of them, if any. We should, however, keep in mind that 1.4.1 is meant to be a minor, bug fixing release over 1.4.0 and therefore should not try to offer big and probably still experimental new features like the universal variant, in my opinion; 1.5 seems to me like more appropriate for that. But, again, I'm willing to be proven otherwise. Regards,... -jmpp
On Apr 6, 2007, at 3:51 PM, Juan Manuel Palacios wrote:
Evening everyone!
So the 1.4.0 release is finally completed after much delay (my bad, my apologies!), and now we're already moving up to 1.4.1. Tonight I did quite some merging into the release_1_4 branch of some of the work that has been happening on trunk, but not all of it.
I'm currently leaving out:
1) r23242: Ignoring SSL certificates; 2) r23098, r23125, r23238, r23248, 23362 and 23552: "New options for configure flags (C|CPP|CXX|LD)FLAGS and logic to handle that and backward compatibility." per Paul's commit log (original and subsequent commits); 3) r23246, r23249 and r23291: New -I${prefix}/include and -L$ {prefix}/lib compile time flags; 4) r23549, 23550 and r23553: Moving port tests into a test subfolder in order to portindex them; 5) Universal variant.
On the one hand, I can't find my commit log mails for the work on the universal variant, so I'd appreciate it if someone could annotate my list with the proper revision numbers; and on the other hand, I'm not sure if 2) and 3) can be split like that, so (Paul) do correct me if I'm wrong. In any case, I'd like to discuss which of those changesets we're going to be including in 1.4.1, so everyone should feel free to ventilate all the pro's and con's about each of them, if any. We should, however, keep in mind that 1.4.1 is meant to be a minor, bug fixing release over 1.4.0 and therefore should not try to offer big and probably still experimental new features like the universal variant, in my opinion; 1.5 seems to me like more appropriate for that. But, again, I'm willing to be proven otherwise.
Could you please list what you're *not* leaving out? What's the point in annotating what you are leaving out? Can we simply get rid of releases, considering the time it takes you to sort them out? Paul
On Apr 6, 2007, at 3:44 AM, Paul Guyot wrote: ---snip---
Could you please list what you're *not* leaving out?
You should read the commit logs/trac timeline/rss feed/changes mailing list/whatever else is your preferred method for looking at our svn commits. Had you done so you would have seen I merged bug fixes and documentation updates into the release_1_4 branch right after 1.4.1 was finally out, thus comprising what in theory what a minor release is supposed to be about. Now, that being said, I've made it clear once and again I have no problem with extending the pre-conceived notion of a minor update and incorporating more things into it, like new features, should the situation demand it (like the passogva port and the new ignore_sslcert option example). I am by no means disputing your claim that our release process needs revising, not to say major thinking over if you want me to go out on a limb here. On the other hand, I have myself stated that several times already, if you should remember, but.... ---snip---
Can we simply get rid of releases, considering the time it takes you to sort them out?
One of the main things our release process lacks, as stated specifically by you several times, is helping hands to both merge the code and test it... so why rather than complaining don't you instead help me speed up the entire process and thus reduce the time between one release and the next (and as a result, minimize the code deltas between trunk and any release branch)? I would like to point out to everyone, including Jordan (who raises different but admittedly valid concerns about our release procedures in a previous thread of his), that I believe your last statement, Paul, was said pretty much forgetting the pain "our entire user base using cvs ToT" days were, regardless of the valid concerns you might raise (which, again, I am more than willing to address.... I am no dictator here!).
What's the point in annotating what you are leaving out?
So that, precisely, we can know what the delta between trunk and release is at the moment and, from there, work on reducing it appropriately. Can we, for now, until we have a more streamlined release protocol at least, do that? I would only benefit *all* of us!
Paul
-jmpp
Guys! Discussion on the 1.4.1 seems to have stalled, so I'm going to make a proposal to get things moving forward and out of the current deadlock: I say we release 1.4.1 now with however small a delta the release_1_4 branch currently holds with respect to the 1.4.0 release, and work on further integrating trunk code (at least some of it) into the branch for upcoming 1.4.2, 1.4.3, etc releases. The existing delta is admittedly small, you can check it out with the following command: svn log -v -r23220:HEAD http://svn.macports.org/repository/macports/branches/release_1_4 (if anyone knows how to get the same output through trac's source browser, please enlighten me!) But it contains two or three important bug fixes I believe we should get into people's hands quickly. I'll be updating the ChangeLog as soon as possible. This should be a painless, simple and quick release, which we would be put out only in the form source tarballs and selfupdate; binary pkg installers and archive tags/tarballs (full svn repo) are left for major releases only (1.4.0, 1.5.0, etc, thus cutting on the time it takes us to produce a release). If we happen to work fast on trunk and a release branch (mainly with respect to testing), maybe we could even cut release_1_5 sooner than expected and get all the nifty beef only in trunk at the moment into people's hands soon, and that sounds like a plan! So, please, anyone interested in having all the features in trunk go mainline (I know I am interested!), you can at least help in getting usability reports in. Also looking at the "MacPorts 1.5" and "Needs developer review" milestones up at the project roadmap (http://trac.macports.org/projects/macports/roadmap) would help. Should we cut a release_1_5 branch now and start preparing it for prime time? Do we want to work on trunk a bit more before starting a new cycle? Please feel free to weigh in with your opinions! Back again on 1.4.1, if I don't get any feedback within, say, two days, I'll tag a release candidate based on the current state of the branch and work my way toward a release from there. Speak up if you feel there's any glaring omission in the code base. Regards to all,... -jmpp PS: I created a "MacPorts 1.4.1" milestone not long ago, but most of the tickets that were fixed for it are currently assigned to the 1.4 milestone. I'll work on correcting that to accurately reflect the state of 1.4.1 in trac.
On Apr 10, 2007, at 9:03 AM, Juan Manuel Palacios wrote:
Back again on 1.4.1, if I don't get any feedback within, say, two days, I'll tag a release candidate based on the current state of the branch and work my way toward a release from there. Speak up if you feel there's any glaring omission in the code base.
OK, at the risk of being flamed for having a one-track mind, let me try a slightly different approach to my usual rant: To ask a counter-question, what would / will the difference between 1.4.1 and ToT tagged and released as of, say, two days ago? Or even sometime this week? I'm not looking for a line by line diff, I am wondering what features or experimental and dangerous code would escape should the latter approach be taken. It's a legitimate question - I'm not just trying to be annoying, honest. I don't have to try to be annoying, I can do that naturally. :-) - Jordan
On Apr 10, 2007, at 10:03 AM, Juan Manuel Palacios wrote:
...
The existing delta is admittedly small, you can check it out with the following command:
svn log -v -r23220:HEAD http://svn.macports.org/repository/macports/ branches/release_1_4 (if anyone knows how to get the same output through trac's source browser, please enlighten me!)
You mean something like; <http://trac.macports.org/projects/macports/log/branches/release_1_4? verbose=on&format=changelog&stop_rev=23220&limit=100&mode=stop_on_copy> That's the ChangeLog format for the page at <http://trac.macports.org/projects/macports/log/branches/release_1_4? action=stop_on_copy&rev=head&stop_rev=23220&mode=stop_on_copy&verbose=on
Get to it by browsing the branch in question, then use the 'Revision Log' link and select the appropriate revision points in the little update box on the right (use 'head' for ToT). Bryan
... Regards to all,...
-jmpp
PS: I created a "MacPorts 1.4.1" milestone not long ago, but most of the tickets that were fixed for it are currently assigned to the 1.4 milestone. I'll work on correcting that to accurately reflect the state of 1.4.1 in trac.
On Apr 10, 2007, at 9:33 PM, Jordan K. Hubbard wrote:
On Apr 10, 2007, at 9:03 AM, Juan Manuel Palacios wrote:
Back again on 1.4.1, if I don't get any feedback within, say, two days, I'll tag a release candidate based on the current state of the branch and work my way toward a release from there. Speak up if you feel there's any glaring omission in the code base.
OK, at the risk of being flamed for having a one-track mind, let me try a slightly different approach to my usual rant:
To ask a counter-question, what would / will the difference between 1.4.1 and ToT tagged and released as of, say, two days ago? Or even sometime this week?
The global +universal variant, for one. I think the plan is to release that with 1.5 (once some more details are figured out).
I'm not looking for a line by line diff, I am wondering what features or experimental and dangerous code would escape should the latter approach be taken.
It's a legitimate question - I'm not just trying to be annoying, honest. I don't have to try to be annoying, I can do that naturally. :-)
-- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (5)
-
Bryan Blackburn
-
Daniel J. Luke
-
Jordan K. Hubbard
-
Juan Manuel Palacios
-
Paul Guyot