Project* roadmap for D6

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Now that Drupal 6 is out, getting the project* family of modules ported to D6 is going to become an urgent task. We want to ensure that by the time the final release candidates are out, we're ready to upgrade drupal.org to D6 (which must happen before the official 6.0 release is possible). That's going to take a lot of effort, and hunmonk and I have some very specific plans for how it should all happen. This page will be the place to keep track of what has to get done, in what order, so that anyone who wants to help knows where to put their efforts. It's obviously a work-in-progress, so feel free to help keep it updated, add issue links where appropriate, cross off things that are completed, or add other steps that need to happen.

I'm cross-posting this to a lot of groups since: a) converting project* to use views is a big part of this effort (so we have significantly less code to support in project* and port to newer versions of core), b) since we need lots of volunteers/help, and c) in case anyone is able to help sponsor some of this work to ensure that everything is completed well before the core maintainers would like to ship 6.0. Thanks!

  1. #103790, #103791, #103795 and #177271: Make project* E_ALL compliant (since we have to do it eventually, anyway, and it'll be easier to do this before we make more branches, etc).
  2. finish up existing project module bugs here: http://tinyurl.com/ynq2n6 and also here: http://groups.drupal.org/node/7396 Finished on 2008-01-06
  3. Project: cut a 5.x-1.2 release of everything (finished on 2008-01-06), and finally create the DRUPAL-5 branch.
  4. Project issue tracker: Fix issues at http://groups.drupal.org/node/7396, cut a 5.x-1.2 release of everything, and finally create the DRUPAL-5 branch. Finished on 2008-01-06
  5. #18920: Convert issue followups to comments (mostly done, just needs more help with the upgrade path, testing, and more reviews).
  6. Project subscriptions or other aspects may benefit from this proposed enhancement to Views: http://drupal.org/node/103171. Note: there is now a module called Views Bulk Operations that makes this patch unnecessary.
  7. Test the Version Control API, CVS backend and Project integration version control modules. The release node integration needs to be completed (probably in versioncontrol_project). [This can all happen in parallel with most of the rest of this list, unless we decide it'll be significantly easier to do the release node FAPI integration via D6 FAPI]. -- postponed until after d.o is running 6.x, see http://groups.drupal.org/node/8102

Work to do for the actual 6.x ports

  1. #157694: Port project to 6.x
  2. #157693: Port project_issue to 6.x
  3. #76725: Convert the issue queues into views (project_issue_views.inc) -- I started this for my day job -- however, the goal would be to actually rip out all the existing code and make project_issue require views, which will take a little more work (but remove *tons* of code we'll no longer have to maintain).
  4. #76726: Convert the project browsing pages into views (project_views.inc)
  5. #209408: Port CVS module to 6.x
  6. #225059: test CVS 6.x project components
  7. Deploy everything on s.d.o

Work to do after the initial 6.x port

  1. Port versioncontrol* to 6.x. Probably sounds like a lot, but it's not much more code than the existing CVS integration module, and it's a) much better code and b) much more flexible for the future, and c) potentially useful to other sites. [Note: this can happen in parallel with project_issue porting]. -- postponed until after d.o is running 6.x, see http://groups.drupal.org/node/8102
AttachmentSize
Project module upgrade to Drupal 6 for Drupal.org_.png94.72 KB
Drupal.org-Drupal-6-upgrade.png100.39 KB

Comments

views2

moshe weitzman's picture

you might mention 'finish views for d6' cuz we are dead without it.

good point

dww's picture

added to the list, and emailed earl about this...

rocking

drewish's picture

i worked on some of the e_all patches and the project namespace patch... eek that's going to touch a lot of code.

working in serial on these?

dww's picture

First, drewish, thanks for helping out here, your efforts are always appreciated in project*. ;)

Second, given the far-reaching nature of both the E_ALL patches and the $node namespace issue, I wonder if we won't all be happier and more productive if we work on those two topics in serial. I anticipate lots of re-rolling and wasted effort if we're doing both of those in parallel. Might I suggest we just focus on E_ALL for now, and other, relatively self-contained bugs and issues. Then, when we've got all the E_ALL stuff fixed and committed, we can do a burst of activity on the $node namespace issue and get it resolved as quickly as possible. That seems like an issue that will generate pain and suffering in direct proportion to the length of time we spend actively working on it. ;)

I could certainly be wrong, but I just want to make the most of your time and efforts.

Thanks,
-Derek

since i can only get so far

drewish's picture

since i can only get so far until the E_ALL stuff is committed i'm not going to be scared off few failed hunks ;)

Safety Mode

hal2's picture

Can you tell me if there is a safe mode, so that we can work with more confidence with D6, while it goes to out to millions and trillions?
Upgrading this site it is a very radical move, that is quite courageous, and will put a lot of people off. If there is a safe mode, that doesn't use to much of the new hardwired code, it would be easier for me to justify putting in the time to upgrade, as I don't want to end up with a half broken site because of the other responsibilities presently on my plate. Please tell there is a safe mode.
:-)

It's beta

earnie's picture

Are you updating your production? A beta is for those who can help debug it in development and testing cycles. The "safe mode'' is to not put the "beta'' code in production.

Thoughts about Projects and CCK

markfoodyburton's picture

In my view (sorry for the pun), project pages should be nothing more or less than CCK pages, and as many of the elements as possible should be CCK elements. So - for instance, the list of releases should be nothing more or less than a view field. The support and development links should be CCK elements too - not sure which ones, maybe new elements might be needed.
A release should be a CCK type, with (among other things) a CCK node-reference element pointing back to the project its a release of.
Why? -- Because then we have a flexible system which is easy to integrate into other work-flows and adapt as needed. And it would also integrate better with other CCK "modules".

I'd also imagine that, at the end of the day, it would be less code. Indeed, if taken this far, it becomes hard to see what the project module is, except for a bunch of content types, and views....?

Yes, but out of scope

dww's picture

Yes, this isn't new -- we've discussed similar things in the past. However, this doesn't get us closer to a D6 release. I think CCK-ifying project* will have to happen another time -- we've already got way too much work to do before a 6.x-1.0 release as it is.

Convert to CCK first and get Views for free?

dww's picture

I just added http://drupal.org/node/85049 to the list. What do y'all think?

Removed again...

dww's picture

Upon further consideration, this is just way too big a change to try to be making, given how time critical a functioning, stable D6 project* is. :( As tempting as it seems to do it now, we should wait for CCK-ification until the 6.x-2.* series. Also, we don't really get much "views for free", since the bulk of the work in views-ification at this point is correctly defining all the default views, which we'll have to do either way...

"working for me"

markfoodyburton's picture

Up front - I agree about the risk. However, I've had to get on and deploy "something" for my own web site, it's about 80% there. Sometime I should blog all I've done, but in short:

To create the basis of projects, I set up a type called - projects (orrigonal!) - and made it the home page for a Organic Group.
* I also set up an "issue" type.
* I set up a number of views to search the issues
* I used a simple "computed field" (any php code you like, anywhere in the page you like) to add links to these views from the project type (links to "issues, Bugs, etc etc") (Nice technique 1)

more features I needed:
I want a "hierarchy" of projects. So I've made a module called og_gpromote - same functionality as og_promote but for groups, when you become the member of one group, you instantly get membership of another group.
To control it, the og_gpromote module has a admin setting where you select which field type is used to indicate a sub-project. It must be a "node-reference" field.(Nice technique 2 - for module developers)
To brows projects, I include a view-field, using the "not official" viewfield module (which I should probably also upload as a module) - which I have patched so it works with views etc. The view field points at a view which searches for all other projects listing this project as their parent. (Nice technique 3)

To add complication - I also want to be able to specify "groups" that are members of this group "by default"
So, you can also specify a "child" field type.

It kind of works - I know of some bugs in it, like if you remove somebody from the "child" then they get removed from the parent, even if they either (a) explicitly want to remain in the parent or (b) are a member of a different child.
But - "it works for me".

Then I also created an "SVN" module, which provides 2 cck types (in sub modules)
1/ a repository
2/ a release
You then instance these fields on a Groups page, and they get treated by the system. The SVN module itself allows you to set up repositories (so long as they are hosted on the same machine), deals with passwd/authz access etc. It also adds "externs" so you can automatically set up one repo to have "externs" for all the projects you have in all the other repo's (if you so want to).
For each repo, you select what groups will be used for membership, either "the owning group" and/or specific groups.

"issues"
* My releases are different from drupal releases - right now, they just consist of a link to a tag in an svn. Therefore I have not needed to set up a "release" content type (I did, it kind of worked, then I realized I didn't need it)
* group promotion really should track if somebody specifically joins a group (see above)
* When you click on the "issues" link, you currently "fall off" the group pages, which is annoying for the user (Of course, you only see issues for the group that you were in (unless you change the search), but, none the less, it would be nice to still "feel" like you were in the group.
* Probably plenty other problems - this is still work-in-progress.

If you want to take a look at this stuff, or help (Open Source projects need help! :-) ), or you have a similar site you want to implement, then please get in touch... When it goes live it will be on www.greensocs.org, but for now, thats still the old site (moinmoin powered - I also have a hacky module to help me convert from moinmoin if anybody needs it).

Check out this thread too

rcross's picture

You might want to also check out this thread - http://groups.drupal.org/node/7850

Also - I wonder if people working on casetracker.module would be able to help with this, since it seems like there are quite a few people who would like to see that module converge to CCK/Views and it sounds like they have more volunteers to draw upon.

--Ryan

subscribe

pwolanin's picture

subscribe

6.x upgrade

douggreen's picture

There are two ways to do upgrades. (a) do a simple conversion from one version to the next (api -> api), or (b) re-implement using new features. The case for (a) is that it's easier, less risky, and faster; and the case for (b) is that you end up with a better product that is easier to maintain, but you have to go through a re-development process. I usually opt for (a) and then do (b) afterwards. It takes more work in the long run, but gets the client to where they want to be quicker.

I think the your chosen work path, where you re-develop using views before you upgrade to 6.x, will introduce new bugs in the project module, will take longer than you expect, and more importantly will slow down the acceptance of 6.x.

I think that getting d.o running 6.x sooner than later is a pretty important endeavor. I also know that you're re-development of project will make things better in the long run, but will take longer in the short run.

Is there a stable version of project that I could just upgrade so we could run d.o on 6.x? Could I upgrade the current version of project that is running on 6.x? I've been willing to do this for 6 months. See #157694. I don't think that this would take more than a day, two at most.

(For the record, I recently broke this rule for a client last month, and to everyone's surprise but mine, we were about 40% overbudget and the client's payment processing system was down for a couple weeks. The lesson: All development takes longer than we estimate.)

BTW, Thanks for the project module! Thanks for all your work on Drupal and d.o. And thanks for reading this!

Doug Green
904-583-3342
www.douggreenconsulting.com
www.civicactions.com

Providing open source technology solutions to Progressives and Democrats
Changing the world one node at a time!

Spoken like someone who's never ported project* before. ;)

dww's picture

I don't think that this would take more than a day, two at most.

That's the funniest thing I've read in weeks. ;) You've clearly never participated in porting project* before.

The main point with the views conversion is that there are huge chucks of very nasty code, still dating back to probably 4.5.x days, that have to be ported and limp along each time we upgrade d.o. By requiring views, we rip most of that out, and a) have a much smaller, saner code base to port to D6, and b) have a vastly wider pool of expertise to draw from to deal with problems, and c) have access to other modules that can extend the functionality in the future.

Yes, there will be new problems. There will be snags. But, I honestly don't think it's going to take significantly longer than it would take to port all the crap that's there now, and the end result will be more maintainable and flexible. If we're wrong, and we hit major problems, we can always re-assess in a week or two.

Also, note: we've been wanting to "do (b) afterwards" the whole length of the 5.x development of project, but it was only once the D6 port started looming that I got killes and dries to agree to let us run views on d.o and do the views conversion. In my mind, we're just now starting (b) from the 5.x porting days. Project* development moves slowly, due to the serious shortage of outside help, and almost total lack of funding and sponsorship (which is pretty surprising, given how critical it is for the entire Drupal project). The shortage of outside help is directly related to the scariness of the code, and converting to views will significantly help with that.

So, in some ways, we're just now finishing up the serious work on the 5.x-2.0 version of project. Once that's done, we'll be ready to port to D6.

dww's picture

Sadly, hunmonk and I have concluded that the conversion to versioncontrol* is premature. Upon closer inspection, the code just isn't ready for prime time yet, there's just too much work to do, and we can't afford either the delays or the risks at this time. We'll just have to put that off until after d.o is running D6 when we can take our time.

So, that means we need to port cvs.module to D6. Doug, if you're ready to help, please see:

http://drupal.org/node/209408#comment-689526

Thanks!
-Derek

You're not giving coder enough credit

douggreen's picture

I did start the upgrade 6 months ago and I spent a couple hours on it, and decided that it was a bigger project than I originally estimated, days instead of hours. But I think that coder makes these things MUCH simpler than it's ever been in the past. I just looked at it again, and I don't think 1-2 days for the actual upgrade is funny at all. Call me an optimist!

dww's picture

a) The things coder will help with will be great, and will certainly speed up points 10-12 (the actual D6 porting).

b) However, the FAPI conversion of all project* modules will undoubtably be the worst part of the upgrades to D6, and coder can't help us there. Honestly, the views conversion won't help much with this, either. :(

c) The views stuff is mostly done (at least for project_issue). There are a small number of things that don't yet easily work with views alone. At this point, most of point #6 involves ripping out crap we no longer need and testing.

So, lest you get the wrong idea, I'd LOVE it for you and coder to go to town with points 10-12 once we get there. I just don't think we're quite ready to start that yet, and I'm sure that it's still going to take some serious FAPI effort, regardless.

Thanks,
-Derek

let him go

moshe weitzman's picture

@dww - I suggest you take Doug's offer/challenge. Let him spend 48 hours and see how far he gets. Think of how much pressure will be relieved once project runs on 6. i know it would be nice to rip lots of old views code beforehand, but you have a live volunteer in front of, willing to do some very important work. i think a hot volunteer merits deviating from the optimum order of operations.

Concerns

dww's picture

@Doug, please understand none of this is meant to disrespect you, or doubt your efforts, ability, sincerity, or intentions.

However, I'll be honest: Chad and I are worried about going down this path. Let's say (optimistically), that Doug is right, and can get a patch done in a few days, that basically ports the existing project and project_issue code base, insane query builders and all, to the D6 API. There will still be bugs and problems with the port (there always are). Doug, are you going to stick with it to debug, test and fix all of it? Frankly, Chad and I are worried about being left "holding the bag" as it were, with a quickly generated, monolithic patch that doesn't fully work. We anticipate that we're going to have to deploy it on project.d.o, and do a bunch of work that takes us away from the versioncontrol API integration and views conversions that we think are best for the long term health of the project and short term stability of the upgrade path (I'm big on ultimately deploying 1 major change at a time, even though Chad and I are working in parallel on the 2 next big things).

So, if there was some explicit agreement ahead of time that Doug will see his patch through to the bitter end, without handing it off to Chad and myself for testing, fixing, etc, I'd be more comfortable "letting him go". However, as little as I want to be left holding the bag, I also don't want Doug to waste his own time. If he's going to spend time on something, and in the end, we can't use it anyway (a huge patch that no longer applies once Chad or I start committing what we're in the middle of, etc), that sucks for everyone. What's going to be the fate of project_release.module in all of this? That's going to be undergoing major changes for versioncontrol API integration, so I don't see how Doug can really do much to port that without creating patch conflicts like crazy. But yet, we certainly can't upgrade d.o without that, and much of the project.module functionality (project browsing pages, etc) will depend on project_release working before we can really test that... See what I mean?

That's what I'm worried about. If there are good solutions to these problems, I think Chad and I are both willing to see this happen and give it a try. I'm just afraid there are a lot of pitfalls and potential for wasted time and lost effort, something that we can't really afford much of these days...

Possibly Wrong Thread

rcross's picture

This is probably the wrong thread to post this, but I'm not sure where a better one is. Its probably a minor issue, but I think it would be very helpful/ideal if issues had their own path. So, instead of drupal.org/node/### you would have drupal.org/issue/###

I want to be able to implement this on a site that I am using, so if there is already a way to do this (hopefully without all the overhead of pathauto since there will be a lot of issues) please let me know. Less necessary, but it would also be nice if issue numbers could be seperate from node numbers. I've had a few users comment that it seems like we have lots of problems because of the high numbers, when in reality its that we have a lot of other nodes too (like forum posts).

--Ryan

definitely the wrong thread ;)

dww's picture

a) please submit new feature requests as issues. this is a roadmap to understand what issues have to be fixed, in what order, to get to a 6.x-1.0 release. random ideas for new features don't belong here. only things that get us closer to a 6.x-1.0 release belong here.

b) casetracker works that way, and personally, i really don't like it. i think it's a feature that issue ids are just node ids. if you see "#123456" in a cvs commit message, you never have to think "is that an issue id or a node id?". in your world, "issue #435" == "node #123456", which is the worst of both worlds, since then you never know what you're talking about. instead of a simple, easy to type, unique id, you end up having to use clumsy stuff like "issue:456", or "node:123456" (or, most likely, both) to know what you mean. people won't do this consistently, and a big ol' mess will ensue. globally unique ids are handy, we should embrace them. if someone really wants to know how many issues you have (and not all issues are problems, but that's another story), provide a view that let's them see the total #.

anyway, go ahead and submit this as a feature request to project_issue if you dare, but i'll "won't fix" it in a heartbeat. ;)

cheers,
-derek

what if they are the same number?

greggles's picture

dww - I think the idea is that issue/123 would just show what's available at node/123 - not to use a whole new numbering scheme (I agree, new numbering scheme == teh bad).

I'm still not sure this idea has merit, since one of the problems with project/casetracker already is that it eats up URL namespace that should be left to other modules.

pathauto is not a lot of

moshe weitzman's picture

pathauto is not a lot of overhead. you can configure it to work on issues only, and do only what you need it to do.

Newsletter

hal2's picture

We would like to know if anyine can put together a short piece, writeup for the newsletter on the roadmap for D6 please, less technical more funk. ;-)

Subscribing. I'll be doing

litwol's picture

Subscribing.

I'll be doing patch reviews etc.


------------------
Sometimes interesting things appears on http://litwol.com

subscribe

neoliminal's picture

Subscribing and probably testing soon.

--
Sony BMG | John K. Lewis | (212) 833-8375 | 550 Mad Ave. 6-22b | aim: neoliminal

--
John Kipling Lewis

subscribing

emilyf's picture

subscribing

subscribing

erikkramer's picture

subscribing

+1 subscribing

prophetsearcher's picture

+1 subscribing

Subscribing.

fuzzy_texan's picture

Subscribing.

subscribing

shrop's picture

subscribing

Version control is now

Ryanbach's picture

Version control is now ported to 6x!

Great news! Thanks for the

shrop's picture

Great news! Thanks for the update. Looks like some of the plugins have been ported to 6.x too.

subscribing

radj's picture

you might also want to finish it fast before D7 comes out. Lol.

UNSTABLE Project 6.x-1.x-dev

Ryanbach's picture

UNSTABLE Project 6.x-1.x-dev released! Link: http://drupal.org/node/357811
Current bug list: http://drupal.org/project/issues/project?versions=357811

release planning?

subcomandante's picture

Hi guys, is there a place to read news about this project beside this page? There is a plan to release a stable version?

EDIT:
I'm testing the 6.x dev version, is there a possibility of data lost while upgrading to future versions?

subscribing

steelaz's picture
  • subscribing

subscribing

davide_ga's picture

subscribing

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: