Tags:
archive_me1Add my vote for this tag gateway1Add my vote for this tag create new tag
view all tags
OLD WORKFLOW: The following is using the old WebForm workflow. We are now using ChangeProposals. Forms for creating new topics should have been removed. See WebCreateNewTopic for alternate forms.

Any topics listed here in dynamic tables will need to be converted from WebForm to the new ChangeProposalForm if you want to propose them for a release. Please read the preferred method to use for conversion.

Patch Proposals

This is a central location to allow contributors to officially propose a change for inclusion in the TWiki core. Patches should ideally be against the latest Subversion checkout, but patches against beta or production releases might work as well. Patches should be unified diffs (diff -U), and please attach them to the topic as well as including pertinent bits in the text for discussion. Please recategorize existing topics with pending patches so that the CoreTeam can evaluate them promptly. Also, please do not directly add topics to other TopicClassifications along the Patch* workflow.

On the other hand, it should be noted that this TopicClassification is specifically for something with an already-working patch that the contributors think is fully ready to go into core. If you have an idea (even fully specced and ready to code), it should be a FeatureEnhancementRequest, not a PatchProposal. The CoreTeam does implement good FeatureEnhancementRequests, but that's much more difficult than integrating an already-finished patch. If after writing a FeatureEnhancementRequest you or someone else does finish the feature and prepare a patch, feel free to put it in here. In fact, if you're looking for something to do for TWiki, try turning FeatureEnhancementRequests into PatchProposals.

Responsibility

Patch Coordinator Role

Part of Task Summary Performed by
CoreTeamRoles Coordinate inclusion of patches into alpha release HelpWanted

Tasks

  • Refine patch process and PatchGuidelines so that patches can get discussed, decided on, and included in core code in an efficient manner
  • Coordinate inclusion of patches into TWikiAlphaRelease

-- PeterThoeny - 02 Aug 2003

Feedback and Comments

Should this role be retired and merged into the DevelopBranchFacilitatorRole?

-- PeterThoeny - 28 Oct 2004

Note Submission Form removed, see note at top

*Notice*: Due to the recent extraction of all of the code in the various scripts under /bin to the TWiki::UI module, accepting patches applied to these scripts has become something of a chore. Patch authors wishing to see their patches in SVN promptly are advised to acquire a recent SVN version and apply their modifications to the affected code in its new home. Recent svn diff patches are very welcome and can be treated much, much more expediently than patches against Beijing, due to these changes. Even a if a SVN patch gets a bit old, it includes the exact versions of the files affected and so is very easy to work with, as long as major refactoring hasn't taken place between the patch's checkout and the current alpha. Apologies for this added hurdle to contribution. -- WM

Patch Topic Creation Date Stinkiness Topic Creator Core Assignment
Could not perform search. Error was: Undefined subroutine &main:: called

Also, note that the TWikiPatches category existed before this classification, and there may be core-suitable material there that we simply haven't examined in awhile...but much of it may also be out of date or unnecessary, or already integrated. However, the TWikiPatches label is still useful so that you can mark a page as containing a patch without asserting that the patch is ready and suitable to be committed to the core code.

-- WalterMundt - 11 Feb 2004

Discussions

I think it would be clearer if we instead make TWikiPatches show all patches (not just unready ones) and a further category for patches in discussion but not submitted. Perhaps PatchProposal should cover discussions and PatchOffered should be for patches that the patcher thinks is ready.

-- MartinCleaver - 11 Feb 2004

Yes, TWikiPatches should show all patches, and indeed, people should leave their topics marked as TWikiPatches even after submitting them to the core via the PatchProposal classification. Anything marked with TWikiPatches but not in one of the Patch* classifications is a patch that is available for discussion and use but that nobody has decided is ready for the core. Note how I said that last bit: there may be core-suitable TWikiPatches available, that nobody has decided to back and make into PatchProposals.

I'd personally rather have unready patches discussed as FeatureEnhancementRequests or BugReports until completed, but if many contributors think a separate "holding bin" for patches needing work or discussion is appropriate I can create one.

Your terminology may be better; when I thought of "PatchProposal" it was with the idea that it is a proposal that an existing patch be intergated into the core, and not a proposal that a patch should be written or improved. That doesn't seem to be how most other people are interpreting it without some explanation...and if we are going to change we should do it before it becomes difficult to recategorize the topics in the workflow manually.

Does anyone else have any opinions on this? I'll rename PatchProposal to PatchOfferedToCore in a day or two if nobody has any specific objections.

-- WalterMundt - 12 Feb 2004

Walter, just a quick note the say that I really appreciate your recent work. The patch process is now much clearer and should allow us to incorporate ready patches at a faster pace smile

I do not have a strong opinion on the name of this page; I like short names for frequently accessed topics so that you can "Go" to it quickly.

-- PeterThoeny - 12 Feb 2004

What is not totally clear from above is what version of TWiki these patches should be against. My proposal would be the last officially released version, but another candidate is the latest beta. However, depending on the speed of examining patches, the latter may often be out of date...

-- ThomasWeigert - 12 Feb 2004

To quote from the intro above: "Patches should ideally be against the latest CVS checkout, but patches against beta or production releases might work as well." E.g. the patches that are easiest to accept are those that apply cleanly against CVS (e.g. the most recent TWikiAlphaReleases). Anything else will have to be updated before it can be used. Again, this topic is for patches that want to go into the core and be present in the next official release. Patches designed as enhancements for current releases are probably FeatureHacks. Of course, patch authors are welcome to maintain "backports" against the current production release so that production users can apply a selected few enhancements without having to wait for a new release or upgrade to a beta or alpha.

Again, if the feature is interesting enough, a CoreTeam member will make the additional effort necessary to update a patch that was built on a release or beta version so that it works with the version in CVS. It's just that much easier to commit something and be done with it if it is already set up to operate on the latest alpha.

-- WalterMundt - 13 Feb 2004

You realize, of course, that "latest" is a constantly moving target. It seems to put pretty heavy burden on submitters to constantly update their patches without having a commitment that these will be actually integrated....

-- ThomasWeigert - 14 Feb 2004

I realize this. I'm not requesting this out of some arbitrary decision. It's simply a fact that, to integrate the patches, we must apply them to the latest version available. If the author of the patch is willing to assume the burden of keeping his or her patch up to date with respect to TWiki CVS, then that absolves us of having to do so. If not, then we'll take whatever is contributed as we have time. It just takes a greater time commitment to commit a patch if a patch requires updating than if it doesn't.

Understand that this is only a recommendation - patches against any version of TWiki are far, far better than no patches at all. As long as the patch author clearly marks what version the patch is based on, we can work with it. The ideal format for this specification is either the production or beta release identifier, or a date for a CVS checkout. Given either of these we can retrieve the version they worked from, see how the patch works, and apply those ideas to the new version. Because it's no harder to do this for any arbitrary (specified) version than it is for some standard "patch base", there's no real reason to ask everyone to base their patches on the same version.

Also, as I'm sure you're aware, software development at this stage is a very evolutionary process. At least for now, there's a good chance that a patch that works for the last release will work with only minor changes in the current CVS checkout. Of course, the further along I get with the TWikiRefactoringProject, the less likely that will be to be the case.

I hope I've clarified my stance on this; if you think I'm wrong and wish to argue for a different policy, please do so. Your point with respect to "latest" being a moving target is a very valid one, and I understand that keeping a patch up to date when you don't know whether or not it will be applied any time soon is a big burden. I've tried to convey the impression that the PatchProposal status is supposed to be short-term, and as soon as we know what we plan to do with a patch it will be moved further along the workflow. Part of the reason for this is that, that being the case, authors are ideally only under this burden until their patch's status has been resolved, rather than for an indefinite period.

-- WalterMundt - 14 Feb 2004

22 Mar to 16 Apr - almost a month so far. What definition of prompt treatment of Patches does the CoreTeam intend? Rejecting patches is fine, but if you want contributions then please let me know what to expect.

-- MartinCleaver - 16 Apr 2004

Well, honestly I think that leaving a patch proposal here for more than a week is hurting the purpose of having this workflow in place to begin with. However, I've been largely unable to put any time at all into TWiki for the past month or so; also, sometimes I'm not sure what to do with a patch, and so I leave it with the hopes that other CoreTeam members will make a decision on any patches they have an opinion on. I think it's better to make a bad decision in these cases than no decision at all, and I'm afraid that after a great community response, we're off to a moderately bad start.

With this in mind I'm going to go through and make some comments tonight, and hopefully shrink the queue a good bit. Understand that as I'll be making these decisions quickly so as to get as many done before I go to bed as possible; as such, I'm not going to be as generous with my time and effort as I otherwise would. If things IRL go the way I think they will and I get some more time to spend on TWiki over the next month, you may find patches migrating from PatchAdjustmentRequired to PatchReadyForCVS to PatchAccepted. But until I'm sure I'll have the time I'm going to try to avoid making promises I can't keep.

-- WalterMundt - 20 Apr 2004

ColasNahaboo? RichardDonkin? As official looker-afters of this process, can you take a look? Given that "it's better to make a bad decision in these cases than no decision at all" - can we push the RenderedWikiWordHandler through? We've had no objections and the week has passed.

If we can't make these processes work, I question this whole mode of thinking that the kernel should be thus protected. It would be better if the process works, even if its not very OpenSource.

-- MartinCleaver - 27 Apr 2004

I've taken care of RenderedWikiWordHandler and the two minor patches in PatchReadyForCVS. While I agree that a more open model might be a good thing to try, I hope this process is at least better than nothing. I'm doing my best, but I'm afraid I don't seem to be getting a lot of help from the rest of the core...

Oh, and Martin, thank you for providing your recent patches in "cvs diff" format. It makes them so much easier to integrate.

-- WalterMundt - 29 Apr 2004

Again, we have patches sitting in here that have been untended to for ages. ColasNahaboo? RichardDonkin? Can you please acknowledge that you do not want the responsibility or delegate it? Peter, if this process is not working perhaps you can find a way to make it do so?

-- MartinCleaver - 13 Jun 2004

So TWiki is back in the pattern of ignoring PatchProposals. I find this bitterly disappointing and a breach of Peter's pledge to make the community function properly.

I almost couldn't be bothered to write anything here. Like, what difference does it make? Its just going to be ignored.

-- MartinCleaver - 03 Jul 2004

Hi Martin, good to hear your voice again.

Right now all energy is concentrated on getting Cairo out the door (even if it means some things get shluffed off to Dakar). If a PatchProposal is not slated for Cairo it won't even be looked at for awhile. Of the core team only Sven has had the time and interest to do twiki work lately, so the force of that energy is small relative to the size of the mountain.

Peter cannot "make the community function properly". He is only one man while the community is made of many. If we sit around and wait for him, or any of the core, to fix it, it won't get fixed. Not because of ill-will or laziness but because the scale and nature of the group is outside the reach of individuals. I've been thinking a lot about our dysfunctional group lately. I haven't been able to label the missing link, the catalyst which empowers change, the seed which grows the crystal, the oil which greases and speeds development. I do know some of what it isn't. It isn't griping and complaining. It isn't apathy. It isn't anger at what others are not or are doing. It isn't hopelessness. It isn't watching and doing nothing. None of which is to say those feelings are not present. I experience them all to some degree everytime I come here. It is to say there are more than enough expressions of that nature already present. Matt saying one more time "just put savemulti in dammit!" is not going to have it's intended effect. If anything it will delay it further. Like attracts like and when the bitter tar pit gets too big, people wander away.

>I almost couldn't be bothered to write anything here. Like, what difference does it make? Its just going to be ignored.

What difference indeed. That is a very good question. It's the one which has been leading me. If I write things, and they make no difference, then I have written without power. To have effect, something must change. I have the ability to change what I write. I cannot change what other people write or how they react to what I write. Therefore if I am not to sit idly by and wait for the world to change so that my words do have effect, I must change what I write.

-- MattWilkie - 03 Jul 2004

From a Core point of view, I can tell you that people that give us Patches seem to be most disinterested in also helping document those changes. to that end, I've stopped accepting patches that are not also acompanied by approriate docco. If you look at all the patches that Watler rushed in, you will see that they are going to hold up CairoRelease because they have not been documented.

Crawford and I just spent the last week trying to get Cairo significantly closer to releaseing, Martin - what did you do?

-- SvenDowideit - 04 Jul 2004

Unfortunately I cannot patch the core myself. I require others to implement my patches. However, when I got no response on them I concluded again that there is no point writing them in the first place. The patch proposal process is a vital link between contributors and the core.

I am happy to write documentation for the patches I produce once they are agreed in principle.

To avoid feelings of discontent, can we thus please add a step to the patch process, before PatchReadyForCVS: PatchNeedsDocumenting? Then we can more clearly engage people what kind of help is required and when.

-- MartinCleaver - 09 Jul 2004

Every day that passes between a patch being written and being it merged is a day with which the competition's has a chance to push out TWiki with their products. Look at the stinkiness figures. 1 week = 7 days. What's with > 40 days? What kind of incentive is this to a contributor that they should bother writing anything?

I have no problem if Patches are rejected, but our process continues to fail our community even that.

As for Sven's question "what did I do?" my main concern is that there should be as little centralisation as possible. Its a bottleneck. At that time I was busy studying. I have no problem people not doing anything as long as they are not in the way of people who do want to do something.

Do you need help implementing the PostCairoDevelopmentModel? Peter please comment. This is more important than support queries.

-- MartinCleaver - 13 Oct 2004

The patch model only works if the CoreTeam is staffed enough to review and incorporate the patches. Currently we are understaffed, and as mentioned before, the patch model has its limitations mainly because we do not yet have a working TWikiTestInfrastructure to test contributions. The DEVELOP branch model scales better.

-- PeterThoeny - 31 Oct 2004

Edit | Attach | Watch | Print version | History: r33 < r32 < r31 < r30 < r29 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r33 - 2006-05-05 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.