New Release System

This group should probably have more organizers. See documentation on this recommendation.

This group will be for discussing future work and other ideas relating to the new system for releasing Drupal contributions that is now in use.

This is a place for news, announcements, and general discussion. Actual bugs and well-defined feature requests should still be submitted to the issue queue of the appropriate modules:

If it's specific to the CVS integration (the form for adding a release, etc), open a new issue here: http://drupal.org/node/add/project_issue/cvslog (please be sure to set the Component field to "Project releases").

If it's specific to browsing projects, finding releases, etc, open a new issue here: http://drupal.org/node/add/project_issue/project (please be sure to set the Component field to "Releases").

If it's regarding how version numbers work within the issue queue: http://drupal.org/node/add/project_issue/project_issue

Thanks, and welcome to the group!
-Derek (dww)

Future work

Posted by dww on November 11, 2006 at 7:40am

[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.

is there any new modules can out to show the issues from jira??

Posted by newbie88 on September 11, 2010 at 9:14am

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

Packaged distributions now deployed on drupal.org!

Posted by dww on December 1, 2009 at 7:02am

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

Full packaging for installation profiles/distributions on drupal.org ready for testing

Posted by dww on November 29, 2009 at 4:03am

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

Fast Private File Transfer using X-send file

Posted by heshanlk on September 23, 2009 at 4:45am

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/

(Optional) Registration of submodules to prevent namespace conflicts

Posted by babbage on July 3, 2009 at 10:07pm

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.

Git and Drupal Core workflow

Posted by CorniI on April 9, 2009 at 4:32pm

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:

cvs contrib procedure

Posted by aufumy on September 16, 2008 at 6:53pm

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.

Commit restrictions in distributed version control

Posted by jpetso on January 29, 2008 at 4:47pm

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.

A complete solution for task/project/issue/case/ticket management with Drupal

Posted by mikey_p on December 26, 2007 at 11:07pm

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.

Project* roadmap for D6

Posted by dww on September 18, 2007 at 8:38am
Last updated by dww on Mon, 2011-06-27 22:06

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 discusses his issue tracking design

Posted by alpritt on August 21, 2007 at 1:58pm

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/

Project* TODO list

Posted by dww on August 7, 2007 at 7:55pm
Last updated by dww on Tue, 2007-12-11 08:04

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:

Issues to resolve in project* before a 5.x-1.0 release

Posted by dww on August 5, 2007 at 12:00am
Last updated by scor on Mon, 2008-04-14 18:53

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

Still new?

Posted by moshe weitzman on July 19, 2007 at 9:30pm

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

How to help with the project* modules

Posted by dww on April 16, 2007 at 9:45am
Last updated by cpliakas on Sat, 2011-06-04 14:00

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.

Help Me to Help You

Posted by alpritt on April 13, 2007 at 8:44pm

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.

Improve module categorization

Posted by Frando on April 1, 2007 at 1:34pm
Last updated by jlin on Tue, 2008-09-23 06:54

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.

Proposal: drupal.org testsite install profile

Posted by dww on March 25, 2007 at 11:06am
Last updated by Harry Slaughter on Sun, 2007-04-22 23:18

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.

2 important Project module and drupal.org improving SoC ideas

Posted by dww on March 17, 2007 at 9:11am

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.

Subscribe with RSS