Since no one has complained about this, I take it as acceptance that we should move things over. Does everyone on t.e.o have a trac-hacks account so we can setup the permissions correctly?
--Noah On Dec 11, 2009, at 10:31 AM, Noah Kantrowitz wrote: > Does anyone have a good reason to not transfer development of these > plugins > to trac-hacks? That seems far more consistent and I see no reason > not to > other than historical stuffs. > > --Noah > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Christian Boos >> Sent: Friday, December 11, 2009 1:44 AM >> To: [email protected] >> Subject: Re: [Trac-dev] [RFC] /plugins toplevel on t.e.o >> >> Remy Blank wrote: >>> Christian Boos wrote: >>> >>>> /plugins >>>> /0.10 >>>> /WebAdmin >>>> /0.11 >>>> /mercurial-plugin >>>> /spam-filter >>>> /0.12 >>>> /spam-filter >>>> /multirepos >>>> /mercurial-plugin >>>> >>> >>> (snip) >>> >>> >>>> 0.X/trac/* >>>> 0.X/trac/<module>/* >>>> 0.X/tracopt/<module>/* >>>> ... >>>> /plugins/0.X/<plugin>/tracext/* >>>> 0.X/sample-plugins/<single-file-plugin>.py >>>> ... >>>> 3rd party plugins >>>> >>> >>> I assume you chose the {version}/{name} scheme instead of >>> {name}/{version} as on trac-hacks for symmetry with the rest of the >> Trac >>> repository? That may make it a bit more difficult to find the latest >>> version of a plugin, in the case where e.g. there's no 0.12 version >> for >>> a plugin, and the 0.11 version can be used. But I think I like your >>> scheme better, too. >>> >> >> The big advantage is that this makes it more natural to phase out >> plugins that were integrated in the core. Otherwise we would carry a >> /plugins/webadmin forever, and with the above scheme it gets hidden >> in >> the /plugins/0.10 folder where nobody will look at ;-) >> >> The disadvantage is as you said, but I guess people will quickly >> get to >> look into the folder for the version they are using. >> >> For plugins that are actually unchanged between different versions, >> we >> could just have a copy and use merge tracking. >> This is to be preferred to "linking", as: 1/ we don't support linking >> (#2566), 2/ we should better change the plugin version anyway (e.g. >> 0.11.0.2 vs 0.12.0.2). >> >> For "branches", we should put only the plugin(s) relevant to that >> branch, the others can be taken from the version on which the >> branch is >> based upon. >> >> -- Christian >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Trac Development" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to trac- >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/trac-dev?hl=en. >> > > > -- > > You received this message because you are subscribed to the Google > Groups "Trac Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] > . > For more options, visit this group at > http://groups.google.com/group/trac-dev?hl=en > . > > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
