Re^5: Responsibilities of a module author

I felt that if a few, long term users expended their time and effort coming up with one or more patches that met their collective needs, and demonstrated both their commitment and collaboration to getting something that worked for more than a single application, the author my feel more inclined to see their point of view and incorporate those patches back into the original module.

Or, hopefully, feel more confident to relinquish control. (Or, if s/he starts maintaining her/his version again, have the forkers merge back upstream and phase out the fork.)

(I think the free software world is poorer for not having sufficiently good distributed source control systems that everyone can effortlessly branch/fork projects locally while still tracking upstream patches. The lack of technical solutions turns questions like these into huge social headaches.)

Makeshifts last the longest.

Comment on Re^5: Responsibilities of a module author

Replies are listed 'Best First'.

Re^6: Responsibilities of a module author
by BrowserUk (Patriarch) on Nov 26, 2005 at 16:50 UTC

... not having sufficiently good distributed source control systems ...

Agreed. I think that most if not all SC/VC software still have interfaces geared around the mechanics of what they do, rather than around the needs of the user.

For example, the need to go through a 3 stage process of setup to move existing code into them combined with the need to explicitly PUT after modifications.

A system that used the OS change notify mechanism to detect and record changes automatically could be so much better. Setup would be a case of telling it to monitor a subdirectory (tree) for changes. That's it. No copying involved, just a crc check of each of the files and register them for change notifications.

Anytime the file gets changed, it receives a notification and immediately records the deltas in the background; locking the file against writes until it is done. Reads (eg. compiler) continue whilst it works.

DARCS is meant to be good for the distributed side of things; allowing greater flexibility and less traffic for localised changes that only get merged if the need arises. I'll get around to checking it out one day.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]


P is for Practical
	PerlMonks