New Release System

[UPDATE 2012年04月23日 from the Drupal.org D7 Upgrade sprint: This list is rather old, outdated, and needs to be triaged by a maintainer before any further work is performed.]

Here's a list of all the issue's I've already submitted for future work -- things about the current system I'd like to improve, and issues other people have suggested. None of these were critical enough to delay the initial deployment of the system, but they should all be fixed eventually. I'm keeping this list updated (and roughly in priority order, as i see it) so there's a central place to keep track of future work.

• #107813: Ditch version selector box in favour of subtabs
• #89699: make release node form smarter when editing HEAD releases
• #90531: give non-admins a way to unpublish their own releases
• #112304: add setting to hide a given release series without unpublishing release nodes
• #97569: allow filtering issue queue by "series"
• #97145: always allow users to leave the version alone when replying to issues
• #93118: Print better error messages on faulty tag or branch name
• #90968: enforce sequential release tags in xcvs-taginfo
• #93055: add project type-specific settings
• #97568: allow maintainers to restrict choices for "Version" in new issues/replies
• #94137: email subscriptions for release nodes
• #94138: RSS feeds for release nodes
• #63491: Drupal Version-Module Support Matrix
• #96971: make better use of tabs and subtabs on project nodes
• #89535: add version filter to each project's "view all releases" page
• #89537: project-specific releases page needs sorting options
• #89673: add input filter to convert #12345 into a link to an issue
• #101905: add a way to stop automated packaging on a release node

is there any new modules can be show??? especially in jira with drupal system, is there any????

The testing phase is over... 3281d Consulting is extremely pleased to announce that the new distribution packaging system is now deployed on drupal.org. The announcement on the front page of drupal.org contains lots of details about how the system looks for end users of Drupal distributions, including lots of nice UI changes to project pages and release nodes.

If you maintain an installation profile on drupal.org please read the How to package a profile on drupal.org handbook page. It's really not that hard, but there are some very important things you need to read and understand to make use of the new system. Support requests and "bug reports" from people who just didn't read the handbook page won't be well received. ;) Oh, and speaking of issues, if you find one, please search the packaged install profiles tag before submitting a new one.

Exciting times -- go forth, yonder profile maintainers, and make Drupal more usable!

Thanks!
-Derek

In case anyone missed the announcements in Planet Drupal, we're going to have fully packaged installation profiles/distributions on drupal.org. Yay! ;) The system goes live Monday night, 6pm PST. Anyone who's maintaining an installation profile project on drupal.org is strongly encouraged to help test the new system. Full details here:

http://3281d.com/2009/11/28/packaged-install-profiles-ready-for-testing

Thanks!
-Derek

mod_xsendfile

mod_xsendfile is a small Apache2 module that processes X-SENDFILE headers registered by the original output handler.

If it encounters the presence of such header it will discard all output and send the file specified by that header instead using Apache internals including all optimizations like caching-headers and sendfile or mmap if configured.

It is useful for processing script-output of e.g. php, perl or any cgi.
Referance from http://tn123.ath.cx/mod_xsendfile/

I am in the early stages of developing a group of modules that will be inter-dependent and will ship as a single downloadable project. This has got me thinking about avoiding module namespace conflicts for submodules that ship as part of other module packages.

This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:

When I gained cvs access, I read the drupal book pages on cvs and also merlinofchaos blog, and polled irc drupal-support.

What I came up with was that there are 2 ways of maintaining releases for contributed modules.

1) Always have the latest code in head, and only release a branch when the new version of drupal comes out. For example when working with module and it is for drupal5 the code is found under HEAD, when the module is upgraded for drupal6, create a branch DRUPAL-5 for the drupal5 module.

I just spent some time in #git to further investigate how our CVS access control scripts would translate to distributed version control systems, in order to help determine the right direction for our new GHOP-powered Git and Mercurial backends (currently being worked on, more on that to come later). Short answer: keep out of that altogether - it's not DVCS style to restrict project maintainers like that. Read on for a more detailed analysis.

I've been evaluating solutions for Project management (for the duration of this post, that includes what i describe as project, issue, ticketing, case tracking, and pretty much anything that falls in that category) solutions with Drupal, over a year actually. I keep being enticed by the features of each individual solution, and new promises that are announced for each module(s) and trying them out and coming to the same conclusion with each of them. And yes, all of them seem to have the same problems that I'm hitting repeatedly.

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!

Garrett Dimon is writing a series of posts on the design of his issue tracking system. The design if for smaller projects than Drupal, but it may provide some inspiration.

So far:

http://garrettdimon.com/archives/2007/8/14/bug_issue_tracking/
http://garrettdimon.com/archives/2007/8/20/the_tracker_status_bar/
http://garrettdimon.com/archives/2007/8/20/tracker_status_amp_comments/

Instead of keeping potentially stale copies of a TODO list in the README.txt files in CVS, I'm moving these list to a wiki page here so there's just a single canonical copy. This is general stuff about the modules. Other to-do lists of interest include:

• Future work for the release system
• Suggestions for improving the d.o issue queue (especially for core)

At http://drupal.org/node/150278 we've started serious work on an official 5.x-1.0 release of project* (project, project_issue, and cvslog).

Here's my current list of issues I'd like to see us resolve for the 5.x-1.0 releases, if possible. Mostly, these are either a) critical bugs, or b) patches I've already written for relatively easy-to-solve problems. Feel free to add comments or update this list. And, of course, please work on any of the issues below -- reviewing, testing, rolling patches, etc. Thanks! -Derek

how long is a release system allowed to describe itself as new?

The project* collection of modules (Project, Project issue tracking, and CVS integration) is the largest set of code running on drupal.org besides Drupal core. They are the key tools that power all Drupal development, including the Drupal issue queue and Drupal release system. Because of the huge user base, high visibility, complex requirements and feature requests, and size and scope of the existing code base (and issue queues) there is a ton of work to be done. This wiki page is how I (dww, the primary maintainer of project*) will try to communicate the best ways for other people to get involved in helping. One of the ways to help is to improve this list, so please add your own ideas here.

Hi,

I'm thinking this may be a good place to start seriously contributing to Drupal. Basically I'm looking for a project that needs help (!) and that will help me to get a strong grasp of how Drupal works. I know Project* fits the first criteria, but I'm a little unsure how well it will help me grok Drupal as a whole.

It is a known fact that the drupal modules page (http://drupal.org/project/Modules) is not perfect. There's a lot of discussion going on about how to gather module quality metrics, whether to enable a voting module or not, etc.
It's quite true that it's currently rather difficult to find what you're looking for. I think that by now I've got quite a good overview about the "hot" modules, but still for me, I often find the modules by using the advanced search or by checking cvs commit track page of the user of which I know he created the module.

this is an idea i've been thinking about. posting it here so other folks can add to it, provide feedback, etc.

Summary

we could really use an install profile that setup a test site similarly to how drupal.org is configured (especially the project* modules and CVS integration). obviously, it wouldn't have the bluebeach theme, but otherwise, it would look fairly similar to d.o in terms of structure, content, permissions, etc.

this would greatly help people who wanted to reproduce bugs and test patches for the project* family of modules, which is something we desperately need more of.

Myself, Webchick and Killes have come up with two proposals for this year's SoC which involve the drupal.org infrastructure and the project module. Both of which could solve some of the worst drupal.org usability problems, and yet are interesting, flexible projects where someone with a lot of creativity and talent could have a huge, highly visible (and valuable) impact on the entire Drupal community.