Backport/Performance patch repository?
Hello, first off I apologize if this is inappropriate for this list. I just leaned that custom logging (by Kahlid) and JS aggregation (by M3avrck) has been backported to 5.x. So I was thinking does it make sense to have a central repository for all these fine backport/performance patches, which may never land in the official 5.x release? (Or does it already exist?) Another high profile patch I am aware of is the tracker query patch (by David Strauss). There gotta be more, including some of the locally applied to d.o. ones that never got released. All these patches (at least the above 3 I mentioned) would be great to have on my existing 5.x sites. But they are buried deep in the issue queue or comment thread, thus easy to miss. My guess is most ppl aren't even aware of them unless they follow issue queue and dev list closely. Can we somehow organize them in a central place, Group, Document page or even a Project? Does it make sense and worth the efforts? Any comments? Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Li schrieb:
Hello, first off I apologize if this is inappropriate for this list.
It is more infrastructue related, me thinks.
I just leaned that custom logging (by Kahlid) and JS aggregation (by M3avrck) has been backported to 5.x. So I was thinking does it make sense to have a central repository for all these fine backport/performance patches, which may never land in the official 5.x release?
Will never.
(Or does it already exist?) Another high profile patch I am aware of is the tracker query patch (by David Strauss). There gotta be more, including some of the locally applied to d.o. ones that never got released.
All the patches that are applied to d.o are availabl ein the issue tracker.
All these patches (at least the above 3 I mentioned) would be great to have on my existing 5.x sites. But they are buried deep in the issue queue or comment thread, thus easy to miss. My guess is most ppl aren't even aware of them unless they follow issue queue and dev list closely. Can we somehow organize them in a central place, Group, Document page or even a Project? Does it make sense and worth the efforts? Any comments? Thanks.
Frankly, no, to me this does not make sense. Promoting these patches will lead to a support nightmare from 1) people who can't patch to save their lives, but want these patches (and probably don't need them) 2) people who can patch and then forget they did patch when they upgrade. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGZa2Lfg6TFvELooQRAm5pAKCS/wobJxms0C1k5jIiF+s9XsS+AwCgqLSM AEBRK2YVF3Wib1hgtYslCQ0= =XlPq -----END PGP SIGNATURE-----
I assume the tracker query patch will be backported to 5.x, when it's finalized. Obviously this is a bug fix, and not a feature. -Peter On 6/5/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
(Or does it already exist?) Another high profile patch I am aware of is the tracker query patch (by David Strauss). There gotta be more, including some of the locally applied to d.o. ones that never got released.
All the patches that are applied to d.o are availabl ein the issue tracker.
actually I was considering making a project similar to what you described. I wanted to include both backports and other patches that are useful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Douglass schrieb:
actually I was considering making a project similar to what you described. I wanted to include both backports and other patches that are useful.
Please don't. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGZbZofg6TFvELooQRAnZtAJ9Vb9P/2my3pGtBVCq8hFWItbDQ0QCfXgKi aexx1YXYYzuyYtLeTue0EuI= =ZZG5 -----END PGP SIGNATURE-----
On 6/5/07, Robert Douglass <rob@robshouse.net> wrote:
actually I was considering making a project similar to what you described. I wanted to include both backports and other patches that are useful.
We pick and choose this, but any backports we do end up including in our main load is available from our public SVN repo. I think this is too much work to expect to happen / support at Drupal.org. A wiki page on groups.drupal.org called Backports for 5.x which aggregated / pointed to issues (set to won't fix, as Neil suggested, so it doesn't clutter work flow) would seem to be a happy medium. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Boris Mann schrieb:
On 6/5/07, Robert Douglass <rob@robshouse.net> wrote:
actually I was considering making a project similar to what you described. I wanted to include both backports and other patches that are useful.
We pick and choose this, but any backports we do end up including in our main load is available from our public SVN repo. I think this is too much work to expect to happen / support at Drupal.org.
A wiki page on groups.drupal.org called Backports for 5.x which aggregated / pointed to issues (set to won't fix, as Neil suggested, so it doesn't clutter work flow) would seem to be a happy medium.
That would be acceptable for me. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGZdiTfg6TFvELooQRAtBrAJ9gjxCjWkFdSgSKcCypGzblPvd4qgCfbhGv qb2watcLmL/2GGpEKpctjH4= =lVHe -----END PGP SIGNATURE-----
On 6/5/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Li schrieb:
Hello, first off I apologize if this is inappropriate for this list.
It is more infrastructue related, me thinks.
I just leaned that custom logging (by Kahlid) and JS aggregation (by M3avrck) has been backported to 5.x. So I was thinking does it make sense to have a central repository for all these fine backport/performance patches, which may never land in the official 5.x release?
Will never.
(Or does it already exist?) Another high profile patch I am aware of is the tracker query patch (by David Strauss). There gotta be more, including some of the locally applied to d.o. ones that never got released.
All the patches that are applied to d.o are availabl ein the issue tracker.
I would like to not see these patches mixed in with issues which are on track to go in a stable version. I do not think using the 'patch (code needs review)' or 'patch (ready to be committed)' statuses are appropriate. The best fit I see is 'won't fix.' -- Neil Drumm http://delocalizedham.com
On 6/5/07, Jim Li <jimmydami@gmail.com> wrote:
Hello, first off I apologize if this is inappropriate for this list.
I just leaned that custom logging (by Kahlid)
No, he did not do it. I did it.
All these patches (at least the above 3 I mentioned) would be great to have on my existing 5.x sites. But they are buried deep in the issue queue or comment thread, thus easy to miss. My guess is most ppl aren't even aware of them unless they follow issue queue and dev list closely. Can we somehow organize them in a central place, Group, Document page or even a Project? Does it make sense and worth the efforts? Any comments? Thanks.
Maybe just a catcall project called "backports". If not, then a taxonomy term, called "backports" that these patches can go against? This is of course with the appropriate disclaimers: "use at your own risk, may kill your unborn children, block upgrade paths, ...etc." -- 2bits.com http://2bits.com Drupal development, customization and consulting.
I am really sorry Khalid for the mis-spelling, I know it's you from 2bits did the work. I make sure it's correct this time by copy/paste ... Gerhard, thanks for your inputs. I understand your concern on support issue, but I still feel it's pity these fine patches would be buried deep in the threads, yet they could be quite useful in knowlegeble hands. And I agree to drumm that issue queue actually is not a proper place for these patches either, or at least they will be 'wont fix's, and further 'closed' to make it harder to reach. Maybe a contrib project makes sense, as Robert and Khalid suggested? A bold big-font disclaimer of course would be needed. Maybe also create a dummy module, so every time update.php is run there will be a big warning box: You have patched core! Undo these patches before you upgrade! .....hehe... On 6/5/07, Khalid Baheyeldin <kb@2bits.com> wrote:
On 6/5/07, Jim Li <jimmydami@gmail.com> wrote:
Hello, first off I apologize if this is inappropriate for this list.
I just leaned that custom logging (by Kahlid)
No, he did not do it. I did it.
All these patches (at least the above 3 I mentioned) would be great to have on my existing 5.x sites. But they are buried deep in the issue queue or comment thread, thus easy to miss. My guess is most ppl aren't even aware of them unless they follow issue queue and dev list closely. Can we somehow organize them in a central place, Group, Document page or even a Project? Does it make sense and worth the efforts? Any comments? Thanks.
Maybe just a catcall project called "backports". If not, then a taxonomy term, called "backports" that these patches can go against?
This is of course with the appropriate disclaimers: "use at your own risk, may kill your unborn children, block upgrade paths, ...etc." -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 6/5/07, Jim Li <jimmydami@gmail.com> wrote:
Gerhard, thanks for your inputs. I understand your concern on support issue, but I still feel it's pity these fine patches would be buried deep in the threads, yet they could be quite useful in knowlegeble hands. And I agree to drumm that issue queue actually is not a proper place for these patches either, or at least they will be 'wont fix's, and further 'closed' to make it harder to reach.
As far as I can tell, only 'fixed' issues are marked 'closed.' Won't fix won't change. -- Neil Drumm http://delocalizedham.com
participants (7)
-
Boris Mann -
Gerhard Killesreiter -
Jim Li -
Khalid Baheyeldin -
Neil Drumm -
Peter Wolanin -
Robert Douglass