This discussion is related with ticket
33233(https://code.djangoproject.com/ticket/33233)
There is pagination in ListView and it show 404 error when page number is
out of page range.
It is reasonable but I think the options to control 404 exception always
should be there.
In current Implement
e the
> `setup()` hook. Please do proceed.
>
> Kind Regards,
>
> Carlton
>
>
> On Monday, 7 October 2019 09:20:12 UTC+2, Adam Johnson wrote:
>>
>> Moving the head=get line sounds sensible to me!
>>
>> On Sun, 6 Oct 2019 at 17:31, Felipe Lee wrote:
>>
Hi everyone,
I was looking into ticket #20456 (
https://code.djangoproject.com/ticket/20456), which is to improve the ease
of testing class-based views (cbvs). It's been a while since anyone has
touched it. There was a pull request a while back (
https://github.com/django/django/pull/2368/) whic
I’ve moderated a couple small-medium forums (2k-8k) members as well as
participated in many online.
I am in favor of moving to a forum system for a lot of reasons. I’d be
curious who would be the community manager(s) (not moderators per se) and
if the tone would be similar to the docs and wiki or
That is correct. It is deprecated now (2.2) and will stop working in 3.1.
More info is available at
https://docs.djangoproject.com/en/dev/internals/deprecation/
Lee
On Thu, Jul 25, 2019 at 7:24 AM sajjad Hassanzadeh
wrote:
> in https://docs.djangoproject.com/en/2.2/topics/db/aggregation/ P
like ?wordPos=2,3
On Thu, Jul 19, 2018 at 10:27 PM Zhao Lee wrote:
I have to confess I don’t know much about web development .
I used to expect QueryDict.get(_key_, _default=None_) to return data type that
client side offered, for example , if client side send {'wordPos':(2,3)
I have to confess I don’t know much about web development .
I used to expect QueryDict.get(_key_, _default=None_) to return data type that
client side offered, for example , if client side send {'wordPos':(2,3)} , I
expect get('wordPos') to return it, whereas the current behavior is far from
ex
so maybe we should add to the documentation of
https://docs.djangoproject.com/en/2.0/ref/request-response/#django.http.QueryDict
*If want to get multiple values for the same key, use
QueryDict.getlist(key, default=None) instead of QueryDict.get(key,
default=None)*
add example to
https://docs.d
I was trapped by the behavior of `QueryDict.get(_key_, _default=None_)` for
a bit while before consulting the documentation , for that *If the key has
more than one value, it returns the last value.*
So as for multiple values for the same key, is returning the last value
of key more often expe
>From my perspective, this issue is about silent data loss, which is about
one of the worst bugs you can have and one that Django typically tries very
hard to avoid or fix, even if it breaks compatibility.
It is extremely easy to cause silent data loss with the behaviour being
discussed. For whate
onse 204 site:
> code.djangoproject.com)
>
> On Wednesday, April 5, 2017 at 11:25:44 AM UTC-4, Philip Lee wrote:
>>
>> Every Django view function MUST return an HttpResponse object, sometimes we
>> just want to send data to the server and don't want to send da
Every Django view function MUST return an HttpResponse object, sometimes we
just want to send data to the server and don't want to send data back to the
client , this probably lead Python users want to return None instead, however ,
this is not allowed in Django view function, I found HttpRe
If your django queries is too long (>100 character), you can try this style
person = (
models
.UzbekistaniCitizen
.objects
.filter(occupation__income__taxable__gte=4)
.exclude(face__eyes__color=blue)
.order_by('height')
.select_related('siblings', 'children'))
In t
e
> for the sane default...
>
> Cheers,
>
> Malcolm
>
> On 2 August 2016 at 14:01, Lee Trout > wrote:
>
>> I know there's always resistance to adding more settings but this seems
>> like a candidate for a value in a setting with a sane default that a us
I know there's always resistance to adding more settings but this seems
like a candidate for a value in a setting with a sane default that a user
could quickly and easily change.
On Tuesday, August 2, 2016, James Pic wrote:
> Thanks for your reply Aymeric. If I understand correctly the best way
ees around what is and isn't
called...
It might be best to expand this in to 2 or 3 graphics and show the various
states (or an animated gif)...
Lee
On Mon, May 9, 2016 at 9:48 PM, Tim Graham wrote:
> Would someone like to help update the graphic in this section [0] for the
> new-st
I'm not sure about saying that a project is a "container for apps", and
that a project contains "only" settings and "no database models".
At a basic level, a "project" can be just a settings module, but it may
include other things.
Apps that are sub-packages within a project are generally not p
*I meet some errors when I migrate database, and the error code is
following:*
> Operations to perform:
> Synchronize unmigrated apps: staticfiles, messages
> Apply all migrations: admin, contenttypes, api, auth, sessions
> Synchronizing apps without migrations:
> Creating tables...
> R
I think that while `extra()` gets a bad rap, it is extremely useful when
creating generic pluggable apps, and I for one would miss it if it were to
be removed.
In a comment on #7231 a few years ago I wrote:
I can't reply to the discussion linked on Google Groups anymore, but wanted
> to add my
s:
>>
>> urlpatterns = [
>> admin.site.get_resolver('^admin/'), # or
>> get_resolver(RegexPattern('^admin/')) to be more explicit
>> ]
>>
>> This would solve the namespace issue for the admin, but it would still
>>
I don't want to add any noise here- but I just had a chance to glance over
this conversation and I've basically been doing what Carl describes with
Angular. (In fact I joke often about calling it Djangular). I have a view
that prerenders angular templates (accepts the path to the template in the
ur
>
> An app doesn't necessarily have to use its own patterns. With that said,
> it's up to the user to make sure it works if they are to mess with the
> app_name. Two conflicting apps can be installed with different namespaces,
> but there will always be a default (the last one, if there is no n
Thanks for taking the time to write up this proposal. I agree on pretty
much all counts, but I do have a few comments:
1)
If an app has templates and view code that are reversing
:, then changing the app name (e.g. by an undocumented
feature, passing a (patterns, app_name) tuple), then all tho
I agree, why not always pass the single auth backend into the login
function?
If the backend is inferred by a single value in the settings and not stored
alongside the user ID, what would happen to existing users who are already
logged in when a second backend is added to the settings and deplo
This sounds good. But will it significantly slow down the rollout of new
features into Django that require deprecation? Also, could features that
are deprecated in an LTS be dropped in the next non-LTS release? e.g. if
1.8 still had a feature that was deprecated in 1.5, could it finally be
remo
.utils.log that if it's
updated remember to update the docs).
Thoughts?
Thanks & Happy New Year!
Lee
[0] https://code.djangoproject.com/ticket/21714
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself
I also don't see much benefit in using relative imports. Code is read many
more times than it is written, and I find having the full path makes it
much easier to sort and visually scan imports, and to easily see at a
glance exactly where to find what you need.
If they are to be used, I would re
Right now it seems that for a generic app to support the possibility of
being installed in a URLconf with a namespace, the app author will need to
take care to explicitly define a `current_app` for every call to
`reverse()`, `TemplateResponse`, `RequestContext`, `Context` and `{% url
%}`.
Djan
Looking at it objectively I'm on the fence. Angular's $http is easily
configurable at the provider level and I feel like the onus is on any
front-end tool to be flexible enough to work with different servers. At the
same time if I needed the same code to talk to Django, Flask, and Node then
I would
Let me clarify that I would expect both qs[:1][0] and qs[0] to raise
IndexError if there were no results.
On Thu, May 16, 2013 at 11:05 AM, Lee Trout wrote:
> That's what I thought- But why not just qs[0]?
>
> Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It s
d loads every single model in the
> queryset into Python, potentially the whole database!
> On May 15, 2013 9:24 PM, "Lee Trout" wrote:
>
>> Is qs[:1][0] better form than list(qs)[0]?
>>
>>
>> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong wrote:
>
Is qs[:1][0] better form than list(qs)[0]?
On Wed, May 15, 2013 at 7:48 AM, Selwin Ong wrote:
> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints an
Hi Aymeric & Adrian,
I didn't see any further discussion or consensus on the issue of the
generic localflavor. The 1.5 docs and (accelerated) deprecation of
localflavor are a little hazy regarding the generic localflavor.
The 1.5 docs say that it hasn't been removed (yet), but doesn't say it wi
+1 for logging. It took me way too long to figure out how to get everything
working properly using a different (builtin) class. I agree with #19395
that an example (or two) would be great.
Here's what I'm currently using which makes use of a rotating file handler
and a custom date formatter (If it
you sure you've registered?".
I feel like there could be a better default that doesn't expose the fact
that an email may or may not be in use. (And that probably goes for the
unusable password error, too.)
Relevant bits:
https://github.com/django/django/blob/stable/1.4.x/django/c
Docs have been added (patch should be complete now) and pull request has
been opened, at Anssi's request.
https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discussion
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" gr
Hi Aymeric & Anssi,
Thanks for your feedback. I have updated my branch with an implementation
of a new `HttpStreamingResponse` class plus tests and updated the ticket.
Please take a look and let me know if this is moving in the right
direction, and if there is any other feedback. If the approac
Hi Ryan,
I don't think what you are suggesting would be necessary. Stream-capable
middleware could avoid having to handle both cases by simply wrapping
response.content with a new iterator in all cases, if they want
to. Non-streaming responses can still be iterated. They just have fewer
iterat
I have updated the patch on my GitHub repository after some discussion on
IRC with Anssi. The patch applies on master again now, it consumes
generator content on access instead of on assignment, and raises a
PendingDeprecationWarning if you create an HttpResponse with
stream_content=True and th
After discussion with akaarai and mYk on IRC, I have two updated proposals.
OPTION 6:
1. Consume `HttpResponse.content` on first access, so that it can be read
multiple times and eliminate the current buggy behaviour (e.g.
`response.content != response.content`) when a generator is passed in a
It sounds like the preferred solution is still "don't do that", which I
think corresponds most closely with option 1. Simply consuming generator
content in `HttpResponse.__init__()` in all cases would prevent some of the
surprising behaviour we are seeing, but it would completely break any
supp
I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
streaming responses that is getting quite long in the tooth now, which
Jacob finally "accepted" 11 months ago (after a long time as DDN) and said
that it is clear we have to do *something*, but *what* remains to be seen.
Overall, I like this patch. I think it's a little unbalanced that we
provide `Meta.widgets` but no clearly documented way to override other
properties on fields without replacing entire fields.
I think the doc changes are pretty helpful to users who are looking for a
way to do this, and it is a
Great job!
在 2012年4月28日星期六UTC+8上午11时08分09秒，Adrian Holovaty写道：
>
> On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty
> wrote:
> > We're going to do the migration to GitHub today. This means we'll no
> > longer be committing code to our Subversion repository. Committers,
> > please hold off on
This seems odd to me. Django is generally a very open and community
oriented project, which strives to consult with the community and achieve a
consensus, resorting to a BDFL decision when necessary, after all sides
have put their case.
Maybe I wasn't following closely enough (apologies if that
Is it only me who needs a simple tag with optional assignment, e.g. that
both {% mytag %} and {% mytag as varname %} are possible?
Attached is a patch that make the assignment optional for assignment_tag.
If this change of behavior of assignment_tag is not acceptable, then how
about adding a ne
I agree with this. HTTP 500 error should not occur due to users attempting
to subvert the system somehow. HTTP 500 errors should only be returned when
an unhandled exception occurs (which shouldn't happen).
Cheers.
Tai.
On Tuesday, 10 April 2012 21:34:07 UTC+10, 3point2 wrote:
>
> The admin si
ile() not per app profiles.
>
> It should be used for generic-esque data about a User. e.g. Email, phone
> number, name, etc.
>
> It should not be used for app specific data about a user, e.g. Default
> Gallery, Notification Settings, etc.
> On Tuesday, April 10, 2012 at 6:01 PM
Alex,
I think the problem with this aspect of your proposal is that it signals a
green light for other pluggable apps to follow Django's lead and provide mixing
which must be added to their `User` model in order to use the pluggable app,
instead of creating a profile model for their pluggable a
Tom,
Thanks for raising those issues. I would just like to add that I hope to see
fields currently in `User` that are required by the admin (is_staff, etc.),
moved to an admin profile model, and not simply made available through mixins
that are still required by every `User` model that gets swa
Alex Ogier,
Is it really better to require users to create their own User model that
behaves like an admin user, instead of just shipping with a self contained
admin user (as a profile model) without the auth component?
If the auth app was purely a stub to connect different profiles and
authen
data, doing database scheme migrations, and
duck typing a single model for use with multiple pluggable apps.
Cheers.
Tai.
On 06/04/2012, at 7:42 AM, Anssi Kääriäinen wrote:
> On Apr 5, 11:29 pm, Tai Lee wrote:
>> But I still don't see how a swapped in `User` model which *has* to beh
On 06/04/2012, at 3:09 AM, Ian Lewis wrote:
> The good part about swappable user models is that you don't need to
> necessarily fix the model's DB fields in advance. Your identifier and
> password's length and other properties can be user defined and can be
> reflected in the DB.
>
> Django c
Are we really sure that we can or should stomach a swappable User model as
a special case?
It's highly likely that I am missing something (or a few things), but
aren't the main benefits of swapping the User model just to avoid making a
backwards incompatible change, and to avoid making `select_
I'm not so sure that it's necessary or even desirable to solve the
"general" problem of swappable models. If anyone can swap any model by
changing a setting, that sounds like a recipe for confusion to me.
Seems to me that the main benefit of the swappable models approach is just
to avoid backwa
I like this proposal because I am a big fan of a stripped down `User` model
which is basically just an ID, whic provides a common hook into
groups/permissions and other django and 3rd party profiles.
What I don't like is the magical `data` bag (accessing `User.data` and
filter lookups), the new
I agree that it is not an ideal user experience to raise an exception while
decoding POST data. However, I think the alternatives are arguably just as bad,
or even worse.
I consider silently replacing characters in user data to avoid an exception
while decoding to be a silent data loss / corrup
I've just created an essay *cough* I mean ticket about the way Django
silently mangles POST data that is incorrectly encoded, and how this can
send someone (like me) down the rabbit hole trying to debug it, thanks to
"current transaction aborted" database errors.
This shouldn't normally happen,
How come? The release that can be downloaded from the site already must
correspond to an SVN revision number, right? Why not tag it as such so that
people can easily get the same code from SVN as from the release tarball?
Cheers.
Tai.
On Sunday, 25 March 2012 22:02:30 UTC+11, Florian Apolloner
This is easy to achieve in your own code. Create your own BaseModel
class that all your models subclass. Instead of using
`.filter().update()`, do this:
def update(self, **kwargs):
"""
Updates the fields specified in `kwargs` and then call `save()`.
"""
if kwargs:
On Feb 29, 8:15 am, Leon Matthews wrote:
> Would it be feasible to add some logic, something along the lines of:
>
> "Template lines containing just tags with no literal content do not
> produce a line in the output (unless of course the tag itself
> produces one)"
I believe that is what has b
I think this discussion is focusing on template tags, not template
variables. Maybe even a subset of template tags (e.g. block level tagsif,
for, block, filter, etc). Template variables and inline tags (e.g. now)
shouldn't have white space stripped.
In 100% of cases I can think of I either woul
s and no
actual content. 99% of the time this is the right thing to do, and we
just need a deprecation path and new template tag so that template
authors can opt-in to the new behaviour now.
Cheers.
Tai.
On Feb 25, 4:37 am, Tobia wrote:
> Tai Lee wrote:
> > I don't think adding {# t
I definitely want to see a resolution to this issue. Django templates
when white space matters (e.g. plain text emails) are painful. But, I
don't think adding {# to the end of lines is easy to understand at a
glance, it doesn't even convey a hint of meaning like "dnl" does, but
either option is pre
It's not that hard to just set up a OneToOneField back to User, and
use signals to automatically create a User when you create your own
User/Profile. Then you can still make use of 3rd party apps that rely
on contrib.auth or contrib.sessions, and also make use of groups from
contrib.auth, etc.
Che
I created a generic `accounts` app which has (among other things) it's
own `Profile` model with a username field and a OneToOneField pointing
at `User`. I added an authentication backend to my settings that
checks usernames from my model. Of course there are other supporting
components, forms, sign
I found that Alex's `django-ajax-validation` works pretty well for
this and I think it works the way you described. Perhaps it could be
updated and included into Django core, if there is good support for
it.
https://github.com/alex/django-ajax-validation/
Cheers.
Tai.
On Feb 4, 8:03 am, Adrian
Instead of trying to dynamically change the manager used for reverse
relations or any manager/queryset (either by getting and then throwing
away the default manager, or some other method), or applying manual
filters to achieve the same result, there is another alternative.
Instead of:
{{{
reporte
rofile
profile = Profile.objects.create(first_name='Tai', last_name='Lee',
address='Sydney')
form = ProfileForm({}, instance=profile)
if form.is_valid():
form.save()
}}}
The profile will have no first name, last name or address. The form
will produce no validation errors an
t initial value of "".
>
> Neither error condition is optimal, however A has the additional downside
> that this error is completely outside of the control of the developer whereas
> B is the result of developer error and is under his control.
>
>
>
>
>
>
>
Tom, the problem is not caused by using `exclude`, it is caused by not
using `fields`. If you use `exclude` or simply don't specify `exclude`
or `fields` then all fields will be included. Thanks for your other
example and description of the problem, I just wanted to clarify that
it is not only a pr
Optional or required is not the same thing as important. It is
entirely valid to have important but optional fields on a model.
For example, a field that contains a string reference to a python
callback function that modifies the behaviour of some model methods
when set.
We use this on a Broadcas
There is a potential for data loss with optional form fields that are
(for whatever reason) omitted from an HTML template.
For example, if we take an existing model form and template that
works, add an optional character field to the model but fail to add a
corresponding field to the HTML template
I have had difficulty in finding an easy way to add common methods to
querysets and managers for multiple models in Django.
I solved the problem in my projects by defining a custom `Manager`
class which defines `use_for_related_fields = True` and also overrides
`__getattr__()` to look for queryset
I've run into a bug that is exposed when using defer() or only() with
select_related(). A couple others have come across it, and there is an
existing ticket.
Exceptions appear to be silenced somewhere under normal circumstances
when evaluating `queryset` objects, which made it difficult to track
d
Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where
rounding all halves up would skew results, but I guess not for most
other cases.
If the default rounding behaviour produces different results than a
regular calculator, common spreadsheet and accounting software or even
human (mentally
On Oct 4, 11:17 am, Russell Keith-Magee
wrote:
> I'm completely agreed that the 'soft' deprecation is useful. I'm just
> complaining about the ambiguity in the language: "We're deprecating
> this feature by marking it PendingDeprecation...".
What about just changing "PendingDeprecation..." to
"
Is this really much better than using your own custom manager as the
default automatic manager (used for reverse relations) with
`use_for_related_fields = True`?
Your custom manager could do nothing to filter results by default and
so behave the same as the default automatic manager, but provide
a
On Jul 9, 12:24 pm, Karen Tracey wrote:
> I'm strongly against that idea. Swallowing errors makes it incredibly
> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG` setting to
> turn off much of the error-silencing currently done in template processing.
> Yes, that means differen
On Jul 8, 11:31 pm, Jacob Kaplan-Moss wrote:
> > [...] but some of Django's own template tags (e.g. `widthratio`) don't
> > adhere to
> > this policy.
>
> These are bugs, and should be fixed.
Thanks for this clarification. I will try to review the built-in tags
and submit some patches to fix t
I'd like to raise the topic of exception handling in templates, to see
what people think of the current state and discuss possible
improvements.
I personally find it confusing to use and create template tags at
times, due to exception handling. Sometimes exceptions are supposed to
be silenced, and
On Jun 17, 3:41 pm, David Cramer wrote:
> I'm not suggesting changing the behavior (again due to the
> compatibility concerns), but I completely agree with the original
> poster(s).
>
> Also, in my experience it's a much less common case that you're
> wanting an "I agree" checkbox in your form, ve
This has been discussed many times in the past. For better or worse,
we're stuck with the current behaviour for backwards compatibility.
I personally think it's better this way. Without this behaviour, it
would be a PITA to implement forms that have a "required" boolean
field (must be ticked) with
On Jun 3, 9:32 pm, Jonathan Slenders
wrote:
> I really never want to have the {% block %} names of B/C in previous
> example to be available for overriding in templates which inherit from
> A. This would even cause unexpected collisions between block names.
> The author of the include B, is not
G'day,
There are several open tickets (some getting quite old now) that all
stem from the inconsistent behaviour of the {% include %} tag. When a
quoted string is used for the path, it is treated as a special case
and the include is executed at compile time. Otherwise, it is executed
as the templa
I thought Django already did option 1. If it doesn't, why not? What
are the possible edge cases? Using a date field named "date" as a
foreign key to another model that also contains a "date" field?
On May 10, 1:47 am, Ulrich Petri wrote:
> Currently there are at least 4 open tickets [1-4] that p
On May 3, 9:43 am, Russell Keith-Magee
wrote:
> This stems back to the design motivation of Django's template language
> -- you shouldn't be doing math in the template. Instead, you should be
> doing your math in the view, and providing the template with a
> pre-calculated result.
>
> So, my incli
On Mar 28, 4:08 pm, Justin Holmes wrote:
> By "current app," do you mean the app which contains the view to which
> the current URL is mapped?
I mean the "namespace" (instance name) for the requested URL or the
"current_app" attribute of a context object which is supposed to be
used as a hint for
Now that 1.3 is out, does any core dev have an opinion, feedback or
suggestions on this?
I've solved my immediate need with two template loaders (subclasses of
the app_directories loader) that use thread locals. One prefixes the
requested template name with the app name and the other prefixes it
w
If we're talking about the lowest common denominator and keeping
things simple, this is what I think we'd have:
myapp1/
myapp2/
myproject/
-django.wsgi.sample
-manage.py
-management/
--commands/
---myproject_mycommand.py.sample
-media/
--myproject/
---readme.txt
-models.py
-settings.py
-static/
--
I also don't think it should be considered a security vulnerability to
reveal that an authenticated user does not have permission to access
the admin (or any other) app.
If the credentials are valid and they authenticate against the defined
authentication backends, then we should assume that we ar
I have a generic app which includes base templates (for HTML
documents, emails, etc.) and also template tags that render a template
(for form fields, pagination forms/links, filter forms/links, etc.)
Sometimes I have a project that has several other apps installed which
both use the base template
y of uploads on other
higher traffic sites across different browsers and using different
server side technologies, to see if this really is typical.
Cheers.
Tai.
On Feb 5, 2:23 am, Jacob Kaplan-Moss wrote:
> On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee wrote:
> > It seems to happen with ve
It seems to happen with very small file uploads as well. I've seen it reported
with 30KB uploads, while at the same time 60MB uploads work. If I can't find a
problem with the server causing disconnects, and it is actually on the client
side, I'll just have to continue to ignore the exception rep
actical solution at this time for this.
>
> Graham
>
>
>
>
>
>
>
> On Friday, February 4, 2011 1:55:25 PM UTC+11, Tai Lee wrote:
>
> > There are many questions about this on django-users. The usual answer
> > is to ignore the errors, which are probably g
There are many questions about this on django-users. The usual answer
is to ignore the errors, which are probably generated as a result of
the client prematurely terminating a connection, usually during an
upload.
Nobody seems to be able to reliably reproduce the error, and it seems
to happen with
On Jan 13, 5:06 am, Don Spaulding wrote:
>
> I can't speak to the number of templates actually in the wild that
> rely on the old behavior. I will say that the debug template has been
> "relying on the bug" since 2005. By my estimation, that makes nearly
> every template ever created a candida
If we can, I would be in favour of treating the old behaviour as a bug
and not having to support it while it follows a deprecation path.
However, either way, if the new behaviour stays (and I definitely
think it should) I think we should update the docs to clarify that
there was a change in behavi
I just discussed this with Don on IRC. An example of the use case
described is at:
http://djangosnippets.org/snippets/1016/
The fix for this use case is easy. Pass a list of `(button.func_name,
button.short_description)` tuples as `buttons` in the context instead
of passing a list of callables. B
There are a few tickets that I believe are or should be RFC that I
would like to see committed before the 1.3 feature freeze kicks in,
which I just heard was very soon now. If anyone has time, could they
please review the following and bump to RFC or provide additional
feedback if they're not yet r
1 - 100 of 202 matches
Mail list logo
