Hi Gregory, I absolutely agree to the points here, but what made me disappointed several time is feeling that those kind of rules have been arbitraly followed or broken and there is no "community process" at all in some of the decisions...
You said that only blocker bugs can be fixed during RCs, but we saw commits related to enhancements or small bugs that are ok if considered someway important there in Magnolia. Maybe they are blocker for someone, but this is surely not clear outside, consider that. Discussing commits through jira or the mailing list should be done also by core developers, don't you think that? If magnolia CE is a *community* project please be open also with things that have been discussed privately in the Magnolia office. I am not there, and jira/mailing list should be used also for that. For whatever commit, even small, should exist a JIRA. That's great, and I know that any commit without a jira attached will be criticized. But that seems to be not valid for you for example :) I would have been happy to revert your 26044 and following commits and shame you for what you did ;) Ok, release time and things to do. But if there are rules they worth for everybody. If there is a community it can't exist a "superuser" that can bypass them. Also, rolling back a commit done by someone else is something that MUST be discussed before done. Nobody should do a similar thing before discussing it with the owner, whatever reason is behind. I have to remember that in the past you did important changes and removed features I developed/discussed etc 5 minutes before a final release, after the rc period... that was something really unacceptable which broken any rule described till now. (ok, I know, time has passed... hope that this wan't happen again). So, summing up: great rules and I totally agree, but let's try to discuss and manage things really in a open way, no first/second class developers or single-man decisions. Probably is just a feeling I get since I am not there in the Magnolia place where all the decisions take place, but anyway please consider it... thanks fabrizio 2009/6/11 Grégory Joseph <[email protected]> > > Hi, > > Sorry for taking so long to reply. It seems we need to clarify things a > little, especially about what we call a "blocker" and what not. > > First off, I understand that those fixes were important for you. Heck, > they're important to us. > > During development cycles, basically anything could be called a "blocker"; > the most common reasons will be "we need feature X for project Y which has > roll out with Magnolia n.m next month", "we need X to be able to implement Y > in this or the next version", "feature Z of module M is planned for the next > release, but needs X in Magnolia-core to work", and so on. Releases are > guided by customer/user needs... and marketing. We're *trying* to be > transparent and expose our plans upfront. We need to do it more. But you'll > already find most of the plans document on the wiki, especially in the DEV > space. We usually have a fairly flexible deadline for releases, or, at least, > when starting to work on the next, the deadline isn't so lethal. > > But the closer we get to it, the more precise it has to be. > > These features or fixes (and countless others!!) didn't make it before the > first RC. As soon as we're in "RC mode", the only reason code changes happen, > or the only way any issue deserves the title of "blocker" is if this is a > newly introduced bug that we've only just discovered (examples in the last > RCs: fixes in activation have introduced a couple of other activation-related > bugs - it went as far as the activation being completely broken in certain > cases). Another case would be when we realise (too late) that a feature/fix > we thought was completed actually isn't. This was the case with the > multi-value change in the DefaultNodeData class that you've mentioned; > multi-value support was actually introduced in the API in 4.0, and at that > moment we had a module that started using it. While doing QA, we realized > that it wasn't working properly in a corner-case. (when the multi-value > property which has a single value is activated, it wasn't seen as a > "multi-value property" on the public instance anymore). Yet another > acceptable case is when we notice bundling issues. These are usually fairly > hard to spot and fix on snapshots - there have been a bunch this time with > the upgrade of a few maven plugins, etc. > > I don't want to play games, so, yes, there are certainly cases where we've > cheated ourselves about this. Point is - these have discussed and agreed upon > internally - so there is no surprise or unweighted risk. And you can ask > anyone here, they'll confirm I'm pretty bitchy about this ;) > > We do these RCs to have a stable basis to do some QA. If other changes are > introduced, this means more review and more QA work, which is both workload > and risk which we can't afford at that moment. > > Your contributions are always appreciated, but we have to be fairly strict. > On our end, we know we're not always as communicative as we could or should > be (although in this case I believe the first RC was announced with advance, > we had few pages going on the wiki). As much as I hate policing, I guess I'll > have to publish those "rules" from now on. If fixes are SO urgent they > *really* have to be included in between RCs, then at the very least, to avoid > the waves of panic, report them on Jira - maybe with a reviewable patch - and > ping the devlist, instead of silently applying them. (but don't be offended > if we ask you to wait until the next release - the criteria above will still > apply) > > On a more constructive note, is there something we could do to either > facilitate your life if you have to live on patched versions until 4.1.1, or > to make sure the "features or fixes you need but forgot to report until just > now" show up in time ? > > Cheers, > > -g > > > > > On Jun 3, 2009, at 3:32 PM, Fabrizio Giustina wrote: > >> >> Hi Gregory, >> MAGNOLIA-2758 is IMHO definitively a blocker, and also MAGNOLIA-2653 >> is pretty critical. >> Ok for not committing enhancements but these have a reason for being in 4.1. >> >> >> fabrizio >> ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
