[Nitro] Patch management
bryan.a.soto at gmail.com
Tue Jan 3 02:52:26 EST 2006
Hi Aleksi and Peter,
I don't know either of you and perhaps public patches and discussion would
help that :)
Another benefit would be to identify common areas of interest for
collaboration. As it stands, most people who submit patches are developing
in isolation probably duplicating effort. As a silly example, how many
people submitted a patch for the recent Store.for_name bug? I did ;) This
would also cut down on the number of patches and help them not be missed.
And yes, patches will be missed. George is only human, after all :)
Plus, it would be a good way for new(er) people, I include myself in this
group, to ease into things. I'd also like to add to Peter's list of docs
that perhaps a proposed feature list for upcoming releases might be helpful?
It seems to me that it would give people a concrete task as an entry point.
I will finish off by saying, Aleksi, thank you for hosting the glycerin
rdocs on your website. I believe the next gem will build the rdocs on
install, so that will be a good thing.
Peter, I'm not sure if you're aware, or perhaps it just doesn't meet your
definition of "a real bug tracker", but there is one available on the Nitro
Rubyforge site. I don't think that it's monitored though.
On 1/2/06, Peter Abrahamsen <rainhead at gmail.com> wrote:
> Thanks for your message. I haven't had trouble with my patches
> disappear, although sometimes it's taken a while to get a response or
> see them committed, and I've wondered if they did disappear.
> Regardless, I think publishing patches and opening them up to general
> discussion is a very good idea. If patches are sent to the list,
> given the wonderful distributed nature of darcs, other users could
> apply e.g. an emergency patch without waiting for it to be approved
> and committed.
> Transparency and bookkeeping are also very important, and something
> that Nitro could use a good bit more of. I don't feel like it's a
> trust issue so much as an incomplete transition from being a private
> project to a public one.
> Publishing patches is one step in the right direction; a real bug
> tracker a la trac is another one. We don't have the resources to
> build our own tracker. We need one yesterday. If this would happen
> faster with some help from a sysadmin, that is my area of expertise.
> There are many documents besides traditional documentation that we
> desperately need in order to collaborate on documentation.
> Principally, these are: a development road map, a style guide, and a
> "map" of nitro's functions. George, you're in the best position to
> write these documents. If you need help editing, or if it would be
> helpful to be supplied with questions to guide your writing, let me/
> us know.
> My $0.03 (inflation, donchya know)
> On Jan 2, 2006, at 11:54 AM, Aleksi Niemela wrote:
> > I've heard there might be patches that are not accepted into Glycerin.
> > I'd like to see few things happen:
> > 1) In case George has looked at patches but doesn't accept for
> > whatever
> > reason (and that's his right) it would be nice if the reasons are made
> > explicit. If some more work is needed to get the patch accepted,
> > saying
> > that would be most important. If there're ideological or other reasons
> > making those public would provide sense of direction for the rest
> > of devs.
> > I propose all Patch talk is kept in this same Nitro mailing list but
> > message subjects would be prefixed with "PATCH:". In time, I hope, the
> > patch traffic will grow to annoying level and dedicated mailing list
> > should be spawned.
> > I hope no message containing a Patch won't go unanswered. Simple
> > "committed" or "won't make into glue per
> > http://www.nitrohq.com/view/ArchitecturalGuidelines"<http://www.nitrohq.com/view/ArchitecturalGuidelines%22>shouldn't be too
> > much. Discussions might emerge for accepted and not-accepted patches.
> > 2) All the patches would be public. Those shouldn't be sent only to
> > George but for example to aforementioned public mailing list or they
> > could be placed into separate directory at nitrohq for rest of Devs to
> > fetch and work upon.
> > One could go forward with public patches and more maintainers might
> > show
> > up naturally. In case George is busy sometime another maintainer could
> > prepare glycerin "upgrade" bundle by accepting dozens of patches and
> > testing those. George would then have an easy job to put that one
> > bigger
> > bundle in official glycerin.
> > I guess this kind "parallel development" is one of the great ideas
> > Darcs
> > should enable.
> > ----
> > I have no standing patches, I guess, so these points don't touch me
> > personally, but I could imagine any dev could get frustrated if
> > sending
> > patches feels like throwing them into (mostly friendly) black hole.
> > - Aleksi
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> Nitro-general mailing list
> Nitro-general at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nitro-general