We made a lot of progress during the Field API code sprint but the code is by no means "finished" for D7. Our planning spreadsheet shows many tasks remaining to be done, though not all of them are ever intended for core in the D7 timeframe. And, of course, we have yet to convince the community that our approach (particularly the per-field storage tables) is correct. So the code is in no way core-worthy yet.
Given the amount of work remaining, it is not practical to continue work in terms of a monster patch (or a set of patches) in the d.o issue queue. We need a development process that meets several goals:
- Allow the code sprinters, and anyone else that wants to contribute, to continue working on the "initial D7 version" of Field API in an efficient manner.
- Expose the Field API work in progress to the community for discussion.
- Preserve future design and code review discussions "for posterity."
Here is my suggestion:
-
The master development tree remains in Bazaar at Four Kitchens for now. This allows anyone (that knows how to use bzr) to work with their own copy of the repo and submit patches for the code sprint team.
-
We commit periodic snapshots of Field API to core CVS even though they aren't ready for release. This allows everyone looking at D7 in CVS to see what is going on and start to play with it. This is feasible because the Field API is self-contained in the directory module/field. The changes to node.module and user.module to use the Field API are very minimal, easy to identify and back out later, and do nothing if the field.module is not enabled.
-
We use the planning spreadsheet as the master to-do list to track what needs to get done and who is working on it, until such time as the to-do list gets small enough to be managable solely by...
-
We use the d.o issue queue (project Drupal, component "field system") for design discussion, code review, etc.; everything we normally use the d.o issue queue for, except not for patches. People that want to contribute patches to the master sources in bzr but do not have commit access can post them to the issue queue.
This process continues until the Field API is "done" to the degree a normal core patch would be committed (i.e.: not perfect, because we often commit patches with expectation of future work, but good enough for an unstable development release). At that point, the bzr repo is retired and the normal d.o development process resumes.
Comments welcome.
Comments
sounds good
As long as field tests don't cause testbed failures then I see no real reason to avoid committing something self-contained to core rather than trying to work on it as a huge patch. In a way simpletest was done the same way (a lot of the original tests would've never made it into core as patches - with polish code comments for example) - and yet having it in core allowed us to tidy all that up much faster than doing the same in contrib would.
I'm a bit less sure about a 'no core patches' rule while the work is in bzr - the motivation is good, but in terms of actual workflow it might be hard to manage - but that's not really a big issue compared to the rest of it. So in general a +1.
We commit periodic snapshots
This procedure will cause severe conflicts with the default merge algorithm when we merge in changes from CVS HEAD into the Bazaar repository. Bazaar will have no idea how text in its repository made it upstream; all it will conclude is that people on both sides edited the same lines of the same files. It might be possible to periodically push FiC code into CVS HEAD if we merge back into the Bazaar repository using the weave algorithm (and not the default diff3).
Personally, I'd like to see the merge back into CVS HEAD and the Bazaar repository shutdown be a one-time, simultaneous event. I can publish nightly tarballs of HEAD + FiC if it would help, but we'd also have to commit to merging HEAD changes into FiC every day, too.
Here's the Bazaar
Here's the Bazaar documentation on the issue of merging into something and then merging back from it with additional changes on both sides:
http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#criss-c...
Issue queue seems best
Dries, yched, and I talked about this on Friday and he is quite open to the idea of using the d.o issue queue for this, even before we have any 'Field' code in core. He said it would be fine to create a 'Field' category where we could post issues and handle them. We could even post bazaar patches on the d.o. issue queue for review or explanation if we wanted (we would have to give them some name that the test bot would ignore, like making them all .txt files).
Doing it on the issue queue would be far more manageable than using the spreadsheet since we could create an issue for each story that could contain its own discussion.
I would be in favor of moving directly to the issue queue instead of the spreadsheet, though.
Another suggestion, we have
Another suggestion, we have some patches to 'node' and 'user' to make the system work. They use hooks that don't otherwise exist so should not break anything for existing code. We could go ahead and try to get those patches committed so that the only 'new' code is the code in the new modules. That might make it easier to continue to use bazaar for now.
I do like using bazaar temporarily since we are still making a blizzard of changes that are needed to get basic functionality working. Once it gets to some semi-stable point (even if less than perfect) I'd vote for getting a patch into core so we can continue work from there. But I don't think we're ready for that yet.
Updated proposal
Based on progress since I started this thread a month ago, I have a new proposal for handling ongoing Field API development.
For code maintenance, I think the rate of change of the Field API has decreased to the point that working via patches in the issue queue is feasible (this certainly wasn't the case a month ago). Therefore, I suggest:
For issue discussions, I think we can start using the d.o issue queue now. We'll just have to make a judgment call for whether each case is better handled via a d.o issue or a discussion here, just as we do for every other project that has a group. If we do this, though, it means all members of the Field API team will have to periodically search for all 'field system' issues to make sure we all see them all.
I do not see a way to make a GET link that returns all 'field component' issues, so we'll have to submit the Advanced Search form to get them.
Chicken and egg?
I think the bzr repository made a lot of sense when there were 8 of you in the same room ferociously working on it simultaneously. Now we seem to be at the point where everyone's back to their day jobs. In order to keep momentum going, we need to get more people involved, and "learn bzr" and "use this Google spreadsheet somewhere that doesn't bump up in 'my issues' when there are updates" are just plain not the way most developers on Drupal.org work.
Don't want to see this important work stalled. :( What's the bare minimum we need to do to bring in our other 500 core contributors?
Ready. Fire. Aim.
I think the answer is "nothing." I'll update the draft Final Report to point to the Field API issue queue (thanks for the link, catch!) and submit a current patch. Then we'll start opening issues on d.o instead of beginning discussions on g.d.o. We'll continue committing to bzr (and re-submitting patches to d.o) until something gets committed, then figure out what to do from there.
fields queue
http://drupal.org/project/issues?projects=3060&components=field%20system