Incidentally, the bug you discovered happens to be a show-stopper, so I just changed my vote - nice catch Sandro :)
This thread can still serve as a discussion as to future Pivot release policy when it comes to pushing things out of a release down to a future release. Here's my first take, and once we all agree on this, we can check it in as part of our project practices. - When bugs are discovered during normal development, they should be fixed in the next release. - When bugs are discovered after a release candidate has been tagged, they should be investigated to determine their severity. Only critical bugs should hold up the release; all other bugs can go in the following release. - It's ok for a release to be missing certain features, as long as those features are tracked on the roadmap and prioritized according to the consensus priority. The prioritization of JIRA tickets is always open for debate on the dev list, though it should be kept in mind that if a developer chooses to work on something of lower priority, that's his or her prerogative and should not be discouraged. -T On Fri, Aug 28, 2009 at 9:47 AM, Todd Volkert <[email protected]> wrote: > Are you saying you want all documentation done for 1.3, or just the 404 not > found pages to read "this section is not yet complete"? If the latter, > that's not much time at all to do. If the former, then I'm afraid 1.3 will > be held up for quite some time, as completing the documentation for 1.3.1 is > going to be a very large effort. > > Also of consideration is the time is takes to properly deploy and test a > release candidate. As the release manager, each release candidate takes > about a day of my time to get out, call for a vote, and test myself. As > such, I don't want to hold up a release for newly found bugs unless they > really are show-stoppers. The JSONViewer is a little tool - not a core part > of the platform, so I wouldn't think that any bugs found in it should hold > up any release. > > As for the broken links, I myself do not think they should hold up a > release, but I respect your opinion. Is your -1 vote a full veto, or just a > vote against? > > -T > > > On Fri, Aug 28, 2009 at 9:40 AM, Sandro Martini > <[email protected]>wrote: > >> Hi to all, continuing here the discussion ... >> >> > The issues you raised below are valid, but are not showstoppers, >> especially for an incubating project. Getting a number of successful >> releases out is essential for us to graduate. >> > >> > This is a volunteer effort, and we simply don't have the resources that >> a commercial project might to make sure that absolutely everything is >> perfect for each release. Even in commercial software development, products >> go out the door with known bugs and issues. That's why we have a road map - >> so we > can keep track of our priorities, and make sure that they are >> addressed at the right time. >> I disagree on this, mainly for major releases, given the fact that >> these are simple things to fix, and that we know already. >> Shifting the release of some day shouldn't be a problem ... >> >> > 1.3 is not the "right time" to get all of our documentation done. We >> need to get a stable 1.3 release out so we can promote it and raise >> additional awareness of the platform. Holding up the release until all the >> documentation is ready will prevent us from doing that, and will ultimately >> hinder our success. >> I agree, but the good of Open Source isn't that we haven't here >> commercial timelines to respect, so we can make products with high >> quality ? >> But maybe it's my mis-conception of Open Source ... or are we >> returning to the concepts of last days, explained by Niclas ? >> And form my point of view, a "good release" is the best of code, and >> also the best in related material, also documentation. >> And i repeat, in this case should be enough to put the same pages >> already in the wiki, or are they older ? >> >> > So I would encourage you to reconsider your vote, taking this into >> account. >> Ok, for me it's not a problem, I don't want to have a negative effect >> in the project ... I'm only trying (with my efforts, and from many >> points of view) to improve the quality of this excellent project, and >> this is the reason why i spend here most (and I'm thinking that could >> be too much) of my (little) free time ... >> >> What others say on this ? >> >> >> Bye, >> Sandro >> > >
