Re: Upgrading Trac

[Russell Keith-Magee]

On Sat, May 1, 2010 at 1:03 AM, Jeremy Dunck  wrote:
>
> On Apr 30, 2010, at 10:56 AM, Russell Keith-Magee 
> wrote:
>
>> On Fri, Apr 30, 2010 at 11:11 PM, Jeremy Dunck  wrote:
>>>
>>> As long as I'm here, how much interest is there in review board?
>>> http://code.google.com/p/reviewboard/
>>
>> ...
>> 5) The patch is missing some critical component like tests or docs
>> ...
>> Cases 5 is annoying, particularly if it looks like the patch would be
>> in case 1 or 2 if only the contributor had written a test case. This
>> is a major time sink, but a code review tool isn't needed here - the
>> 'needs tests' flag is all that is required.
>>
>
> I guess I didn't realize that commiters were writing tests and docs for
> otherwise good patches. I assumed those just immediately got a needs_* flag
> and sat until an interested party finished it.

Depends on where we are in the development cycle. When we're in normal
development and I'm looking for bug-squashing work to do, I will
generally ignore non-ready tickets unless there's a particularly
compelling reason.

However, when we're in release crunch mode, the list of release
blocking tickets takes priority over the tickets that are technically
ready, and I'll do the development work if nobody else has contributed
something.

There's also a healthy dose of human intuition to the process.
Regardless of where we are in the development cycle, if I see a bug
that doesn't have a good patch, but I can see how the problem will
have a widespread effect (or I'm seeing a lot of reports on
django-users that are stemming from a particular problem), I will put
the time into completing any patch that already exists.

> Ideas how we can fix this?

There are really two problems that need to be solved:

 1. Provide better encouragement for people to contribute to release
candidate blocking bugs in the leadup to a release (where contribute
== implement patches, review patches, improve patches, or recommend
patches as ready)
 2. Provide better feedback to the core on which bugs are ready for
commit during normal development.

I'm not sure how to improve (1) beyond what we're already doing.
Suggestions certainly welcome. As for (2), the 'me too' features I've
spoken about before would solve that.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Russell Keith-Magee]

On Sat, May 1, 2010 at 1:57 AM, Mike Axiak  wrote:
> On Fri, Apr 30, 2010 at 11:56 AM, Russell Keith-Magee
>  wrote:
>> So, if we were to integrate a code review tool, it would only be to
>> support case 3. I don't have any concrete numbers to back me up, but
>> my gut feeling is that case 3 isn't a time sink for me.
>
> There is an added benefit to having a code review tool, though. I
> think you'll find that people who post one patch are more likely to
> post another patch. Using a code review tool will help those patch
> writers to more quickly learn the ropes of writing good Django code
> and improve.
>
> It may not be worth the added effort by the commiters, but it is
> something to keep in mind.

That's a valid point - this is one of those cases where it creates
more work for the core (providing formal review feedback on patches
that are almost correct, rather than just fixing them and committing),
but in the long run giving that feedback might be worth it.

Although a code review tool might make the review process easier,
there's nothing in particular preventing committers from providing
feedback using the tools we have right now. I'll try and provide
better feedback on patches that get committed. If it turns out to be a
useful exercise rather than just busy work, it might provide some
extra incentive to get a code review tool in place.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Luke Plant]

On Friday 30 April 2010 19:22:33 Idan Gazit wrote:
> FWIW, I spoke with Alex the other week about turning piano-man into
> a more finished product.
> 
> So long as core guarantees that they'll at least take a look at
> whatever is made, I'm +1 on rolling our own, and am willing to
> champion this project.

Personally it would take quite a lot to persuade me to look at it 
(sorry for not responding before, but I was prompted by this message).  
I feel similar to Russell about fragmenting the bug tracking 
community, but even more so - especially given that Trac is written in 
Python, and already has a very active community of supporters.  There 
are Trac plugins for almost everything you can think of.

I would also be extremely loathe to switch if there is *any* loss of 
information in the database conversion.  So that includes requiring 
identical bug numbers (so that SVN commit messages don't become 
outdated) and supporting 100% of the wiki formatting in existing pages 
and all bug reports (or being able to convert it losslessly), and 
preserving the history of all changes (including flags) to bugs.  It 
is important to be able to look back at a bug report and see what was 
changed by whom etc.

Once you add these requirements, I suspect that you will be doing much 
more of a 'Trac clone' than you want to be.  And we would still need 
to have compelling reasons to switch - bare feature parity wouldn't be 
anything like enough, especially given the team and community that are 
behind Trac.

I imagine that adding several plugins to Trac would be a much better 
route - in particular a code review plugin, of which there are several 
on trac-hacks I think, and some plugins to do the auto-mail functions 
that Jeremy suggested.  If we fail to review the existing plugins to 
Trac and see how easy it would be to add our own, it would be nothing 
but a massive case of NIH.  I have written some small plugins for Trac 
in the past and found it fairly painless.  While Trac may have it's 
problems, we would have to be crazy - not to mention extremely 
arrogant - to think that we could do better without a huge amount of 
work.

And before anyone starts work on any of these, whichever approach, 
please do get some consensus about what features are actually 
desirable!

Luke

-- 
"It is a truth universally acknowledged, that a single man in 
possession of a good fortune, must be in want of a wife." (Jane 
Austen)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Silvio]

Owen,

The file is only created once, so the compression only happens once.
Only when any of the files being aggregated is changed does the file
get recreated.

In other words, the process is automatic, but it has no performance
penalty.

Silvio

On Apr 30, 10:27 am, Owen Nelson  wrote:
> In this case you're compressing at runtime... or am I missing something?
>
> I think I'm just going to burrow for a little while and prototype some
> helpers.  I've got a project coming up shortly with some room for R on
> this front, so hopefully I'll be able to put them into production for a
> while before I bug anyone again.
> I'll be back (at some point) when I've got something I think will
> benefit the community.
>
> Thanks for all the interest in the topic though - I think that proves we
> are all hungering for *something* even if we're not exactly sure as to
> what it is.
>
> Silvio wrote:
> > Consider taking a look at an app I 
> > wrote,http://www.sgawebsites.com/projects/django-aggregator/.
>
> > It aggregates all JS and CSS files using a very simple syntax. It can
> > also pipe the content through YUI Compressor before saving the
> > aggregate.
> > My aim was to make it extremely easy to use. It's not an asset manager
> > though; I've yet to see or come up with a great solution.
>
> > Regards,
>
> > Silvio
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Gabriel Hurley]

Is it worth upgrading to the 0.11.X branch with Trac 0.12 scheduled to
be out the door within a couple weeks?

On the one hand, a brand new Trac release would be more likely to
contain bugs than a bugfix branch that's now on it's 7th revision. The
configurable workflows and per-user permissions were the big features
for 0.11, and both of those require an inordinate amount of setup to
be made useful (inordinate being relative to how those tasks are
managed in other trackers).

On the 0.12 side, the improved query system sounds like it would be a
big boost for some of the issues that have been discussed, and live
previews, ticket interface improvements, and translations all sound
like really good features to have.

Just throwing it out there.

All the best,
- Gabriel

On Apr 30, 8:06 am, Jeremy Dunck  wrote:
> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
> to 0.11.7 would buy us?  If not, I can go read changelogs.
>
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.
>
> Who has access to the server?  What do I need to do to convince to let
> me upgrade?
>
> This is purely exploratory-- I imagine the workflow stuff I'm trying
> to do doesn't really need the upgrade, but Russ complained a bit about
> nits, so I thought I'd at least see what's what.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Alex Gaynor]

On Fri, Apr 30, 2010 at 3:57 PM, Gabriel Hurley  wrote:
> I'd also be interested in working on this, as long as I'm not alone on
> it. Have you and/or Alex set up any kind of mailing list for it? Do
> you plan to use git's issue tracker or something else? What's the
> process plan for getting development kick-started on it?
>
>    - Gabriel
>
> On Apr 30, 11:22 am, Idan Gazit  wrote:
>> FWIW, I spoke with Alex the other week about turning piano-man into a
>> more finished product.
>>
>> So long as core guarantees that they'll at least take a look at
>> whatever is made, I'm +1 on rolling our own, and am willing to
>> champion this project.
>>
>> I think having something we can easily shape to meet our process needs
>> will be a Good Thing. A good ticket tracker helps devs paw through the
>> pile of tickets and keep kicking the ball forward with a minimum of
>> effort. Reducing the overhead on core will make those people's lives
>> more pleasant (and free up their time for dealing with, you know,
>> code.)
>>
>> Another benefit: one of the complaints I (anecdotally) hear all the
>> time is that it is hard to contribute to django. Part of that is the
>> high bar we set for contribution, and the (necessary) process we
>> impose in order to prevent oopses, but I posit that a significant part
>> of the feeling stems from people confusing a lack of activity on their
>> ticket with a lack of activity. Making it easier for devs to update
>> tickets will help, and providing some kind of dashboard on project
>> stats will give us something to point to next time somebody throws
>> their toys out of the pram because their pony isn't being seen to.
>>
>> I'll be in Berlin, and plan to sprint on piano-man there. Plan:
>>
>> 1. Figure out a handful of "most useful" tricks that trac doesn't
>> accomplish, and adding those to piano-man. I particularly like the
>> idea of baking in some behaviors like timed ticket death and other
>> things that prevent a buildup of detritus and cut down on ticket
>> gardening chores.
>> 2. Put up a test instance with a dump of data from trac.
>> 3. Kick the tires and see if it engenders interest.
>>
>> If people think it's awesome, we'll keep going. :)
>>
>> -I
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group 
>> athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

To keep from bothering everyone on -dev about this I'll setup a
mailing list this evening, I'll put a link in the piano-man readme
when I do.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

I'd also be interested in working on this, as long as I'm not alone on
it. Have you and/or Alex set up any kind of mailing list for it? Do
you plan to use git's issue tracker or something else? What's the
process plan for getting development kick-started on it?

- Gabriel

On Apr 30, 11:22 am, Idan Gazit  wrote:
> FWIW, I spoke with Alex the other week about turning piano-man into a
> more finished product.
>
> So long as core guarantees that they'll at least take a look at
> whatever is made, I'm +1 on rolling our own, and am willing to
> champion this project.
>
> I think having something we can easily shape to meet our process needs
> will be a Good Thing. A good ticket tracker helps devs paw through the
> pile of tickets and keep kicking the ball forward with a minimum of
> effort. Reducing the overhead on core will make those people's lives
> more pleasant (and free up their time for dealing with, you know,
> code.)
>
> Another benefit: one of the complaints I (anecdotally) hear all the
> time is that it is hard to contribute to django. Part of that is the
> high bar we set for contribution, and the (necessary) process we
> impose in order to prevent oopses, but I posit that a significant part
> of the feeling stems from people confusing a lack of activity on their
> ticket with a lack of activity. Making it easier for devs to update
> tickets will help, and providing some kind of dashboard on project
> stats will give us something to point to next time somebody throws
> their toys out of the pram because their pony isn't being seen to.
>
> I'll be in Berlin, and plan to sprint on piano-man there. Plan:
>
> 1. Figure out a handful of "most useful" tricks that trac doesn't
> accomplish, and adding those to piano-man. I particularly like the
> idea of baking in some behaviors like timed ticket death and other
> things that prevent a buildup of detritus and cut down on ticket
> gardening chores.
> 2. Put up a test instance with a dump of data from trac.
> 3. Kick the tires and see if it engenders interest.
>
> If people think it's awesome, we'll keep going. :)
>
> -I
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

On Apr 30, 8:02 am, Jeremy Dunck  wrote:
> I haven't heard one proposed.  I'll take a look at RedMine and/or
> steal ideas from launchpad -- but writing a new tracker isn't the
> problem I'm trying to solve.

FWIW, I currently use (and administer) Redmine for my company. I'd say
it's only a marginal improvement over Trac overall. We like it better
because it's more friendly towards non-software project management,
and has easy workflow setup. But the big downside: it's Ruby/Rails.
The thing is a resource hog, and tends to be slower than I'd like
overall. There's a fair plugin community to add cool features, but
having tried a bunch of them I'd say they fall in the "unstable"
category more often than not.

Those are my two cents on Redmine.

- Gabriel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Brian Rosner]

On Apr 30, 2010, at 9:06 AM, Jeremy Dunck wrote:

> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
> to 0.11.7 would buy us?  If not, I can go read changelogs.
> 
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.
> 
> Who has access to the server?  What do I need to do to convince to let
> me upgrade?

I've volunteered off-list by speaking to Jacob. We were supposed to meet up
this week, but haven't made contact yet. I do plan on helping/performing the
upgrade to 0.11.X. I do not yet know what it will take.

Brian Rosner
http://oebfare.com
http://twitter.com/brosner

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Idan Gazit]

FWIW, I spoke with Alex the other week about turning piano-man into a
more finished product.

So long as core guarantees that they'll at least take a look at
whatever is made, I'm +1 on rolling our own, and am willing to
champion this project.

I think having something we can easily shape to meet our process needs
will be a Good Thing. A good ticket tracker helps devs paw through the
pile of tickets and keep kicking the ball forward with a minimum of
effort. Reducing the overhead on core will make those people's lives
more pleasant (and free up their time for dealing with, you know,
code.)

Another benefit: one of the complaints I (anecdotally) hear all the
time is that it is hard to contribute to django. Part of that is the
high bar we set for contribution, and the (necessary) process we
impose in order to prevent oopses, but I posit that a significant part
of the feeling stems from people confusing a lack of activity on their
ticket with a lack of activity. Making it easier for devs to update
tickets will help, and providing some kind of dashboard on project
stats will give us something to point to next time somebody throws
their toys out of the pram because their pony isn't being seen to.

I'll be in Berlin, and plan to sprint on piano-man there. Plan:

1. Figure out a handful of "most useful" tricks that trac doesn't
accomplish, and adding those to piano-man. I particularly like the
idea of baking in some behaviors like timed ticket death and other
things that prevent a buildup of detritus and cut down on ticket
gardening chores.
2. Put up a test instance with a dump of data from trac.
3. Kick the tires and see if it engenders interest.

If people think it's awesome, we'll keep going. :)

-I

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Mike Axiak]

On Fri, Apr 30, 2010 at 11:56 AM, Russell Keith-Magee
 wrote:
> So, if we were to integrate a code review tool, it would only be to
> support case 3. I don't have any concrete numbers to back me up, but
> my gut feeling is that case 3 isn't a time sink for me.

There is an added benefit to having a code review tool, though. I
think you'll find that people who post one patch are more likely to
post another patch. Using a code review tool will help those patch
writers to more quickly learn the ropes of writing good Django code
and improve.

It may not be worth the added effort by the commiters, but it is
something to keep in mind.

Cheers,
Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Jeremy Dunck]

On Apr 30, 2010, at 10:56 AM, Russell Keith-Magee  wrote:


On Fri, Apr 30, 2010 at 11:11 PM, Jeremy Dunck   
wrote:

As long as I'm here, how much interest is there in review board?
http://code.google.com/p/reviewboard/

...
5) The patch is missing some critical component like tests or docs
...
Cases 5 is annoying, particularly if it looks like the patch would be
in case 1 or 2 if only the contributor had written a test case. This
is a major time sink, but a code review tool isn't needed here - the
'needs tests' flag is all that is required.



I guess I didn't realize that commiters were writing tests and docs  
for otherwise good patches. I assumed those just immediately got a  
needs_* flag and sat until an interested party finished it.


Ideas how we can fix this?

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Russell Keith-Magee]

On Fri, Apr 30, 2010 at 11:11 PM, Jeremy Dunck  wrote:
> As long as I'm here, how much interest is there in review board?
> http://code.google.com/p/reviewboard/

I'm not sure.

Like Alex, I've never used reviewboard itself. I have used
codereview.appspot to review some patches (mostly because Alex and
Mike Malone have uploaded patches there), but I haven't really had
occasion to use it on a regular basis.

My impression is that it's probably overkill for our current workflow.

Broadly, patches fall into 5 categories:
 1) The patch is completely correct
 2) The patch is mostly correct, but has some minor problems (typos,
simple edge cases) that are easily fixed
 3) The patch is mostly correct, but has one or two questionable sections
 4) The patch is solves the problem in the wrong way
 5) The patch is missing some critical component like tests or docs

In the case of a workflow that requires signoff from multiple parties
before commit, smoothing the review process for cases 1-3 is vital.
However, in Django's current workflow, cases 1 and 2 are absorbed by
the committer doing their thing.

Cases 5 is annoying, particularly if it looks like the patch would be
in case 1 or 2 if only the contributor had written a test case. This
is a major time sink, but a code review tool isn't needed here - the
'needs tests' flag is all that is required.

Determining if a fix falls into Case 4 is a time sink, but once I've
made the determination that a patch falls into case 4, a comment and
the "patch needs improvement" flag works fine -- and in this case,
works better than a line-based code review tool, since the comments
are specific to the entire patch, not a specific line of code.

So, if we were to integrate a code review tool, it would only be to
support case 3. I don't have any concrete numbers to back me up, but
my gut feeling is that case 3 isn't a time sink for me. Sometimes I do
need to confirm why a patch works a particular way, and for those
cases, I can drop a comment in Trac or on IRC without too much
inconvenience. My intuition tells me that most of my commit time is
spent determining if a patch fits into case 4, or adding tests for a
patch in case 5.

That said, if a code review tool was elegantly integrated into Trac
(or any other bug tracker for that matter), it might be worthwhile.
The vital keyword here is "integration". It needs to be as simple as
"click on a patch in Trac, add a comment". If well integrated, it
would be easier to leave a comment on a patch rather than on a ticket,
so it becomes clear which patch is being reviewed. However, I don't
know if this level of integration is even possible, and if it is
possible, how difficult it is to achieve.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Russell Keith-Magee]

On Fri, Apr 30, 2010 at 11:06 PM, Jeremy Dunck  wrote:
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.

To the best of my knowledge, the only things standing in the way of a
Trac upgrade are:
 * Enthusiasm
 * Time

The available quantities of these resources (especially the former)
have been depleted by past nightmare upgrades.

> Who has access to the server?  What do I need to do to convince to let
> me upgrade?

To the best of my knowledge, the list of people with access to the server is:
 * Jacob
 * James Bennett
 * A couple of sysadmins at the Journal World who have instructions to
kick various reset buttons if smoke starts pouring out and the first
two aren't contactable.

As for who do you have to convince? If you're volunteering to look
after Trac, you don't have to convince me :-)

> This is purely exploratory-- I imagine the workflow stuff I'm trying
> to do doesn't really need the upgrade, but Russ complained a bit about
> nits, so I thought I'd at least see what's what.

Agreed. Thanks for doing this, Jeremy.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Alex Gaynor]

On Fri, Apr 30, 2010 at 11:11 AM, Jeremy Dunck  wrote:
> As long as I'm here, how much interest is there in review board?
> http://code.google.com/p/reviewboard/
>
> On Fri, Apr 30, 2010 at 10:06 AM, Jeremy Dunck  wrote:
>> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
>> to 0.11.7 would buy us?  If not, I can go read changelogs.
>>
>> Separate from that, I'd like to open discussion on what it would take
>> to do the upgrade.
>>
>> Who has access to the server?  What do I need to do to convince to let
>> me upgrade?
>>
>> This is purely exploratory-- I imagine the workflow stuff I'm trying
>> to do doesn't really need the upgrade, but Russ complained a bit about
>> nits, so I thought I'd at least see what's what.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

I don't have a particular opinion on reviewboard (I've never gotten
the demo version to show me anything useful), however I've just used
http://codereview.appspot.com/ to do code review on patches in past
successfully.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Upgrading Trac

[Jeremy Dunck]

As long as I'm here, how much interest is there in review board?
http://code.google.com/p/reviewboard/

On Fri, Apr 30, 2010 at 10:06 AM, Jeremy Dunck  wrote:
> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
> to 0.11.7 would buy us?  If not, I can go read changelogs.
>
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.
>
> Who has access to the server?  What do I need to do to convince to let
> me upgrade?
>
> This is purely exploratory-- I imagine the workflow stuff I'm trying
> to do doesn't really need the upgrade, but Russ complained a bit about
> nits, so I thought I'd at least see what's what.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Upgrading Trac

[Jeremy Dunck]

Does anyone have crib notes on what upgrading from (presumed) 0.10.4
to 0.11.7 would buy us?  If not, I can go read changelogs.

Separate from that, I'd like to open discussion on what it would take
to do the upgrade.

Who has access to the server?  What do I need to do to convince to let
me upgrade?

This is purely exploratory-- I imagine the workflow stuff I'm trying
to do doesn't really need the upgrade, but Russ complained a bit about
nits, so I thought I'd at least see what's what.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Jeremy Dunck]

On Fri, Apr 23, 2010 at 10:26 PM, Russell Keith-Magee
 wrote:
...
>>> I'm not a huge fan of Trac - it's
>>> got lots of quirks and bugs that annoy the bejezus out of me,
>> ...
>> Perhaps upgrading would get us some distance?
>
> Possibly. Was that you volunteering to become our Trac jockey? :-)
>

I've read the TracHacks wiki, it doesn't seem too bad.  ;-)

I've just set up trac locally for testing (0.10.5, hoping that's
accurate), auth/xmlrpc working, hooray.

To be clear, I'm not against switching to a better ticket tracker, but
I haven't heard one proposed.  I'll take a look at RedMine and/or
steal ideas from launchpad -- but writing a new tracker isn't the
problem I'm trying to solve.

If people want to propose other trackers they've been happy with,
please do.  It would save me a lot of time if there was something that
already addresses my concerns.  But meantime, I'm doing work against
trac, since it seems the shortest path to solving the problem I'm
seeing.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Alex Gaynor]

On Fri, Apr 30, 2010 at 10:56 AM, Jeremy Dunck  wrote:
> On Sun, Apr 25, 2010 at 1:27 AM, Stephen Wolff  
> wrote:
>>> I recognize running tests w/ regressions pass would be useful, but
>>> it's getting into CI-land -- once we have some CI infrastructure in
>>> place, I'd be happy to use that.
>>>
>>>
>>
>> In case you missed it, there already is some CI infrastructure a bunch
>> of servers made available to django for testing via Hudson:
>>
>> http://hudson.djangoproject.com/
>>
>
> I knew Eric was noodling on it, but didn't know it was up.
>
> Eric, two questions:
> 1) is there (or could there easily be) a way to run the suite against
> uncommitted patches (or a mirror repo with branch-per-patch attempt)?
>
> 2) in general, what happens if a malicious patch is run?  I'm not
> looking for total sandbox here -- but at least the understanding that
> putting a machine into the test system means taking the risk that the
> machine gets rm -rf'd or similar.
>
> (Does anyone know of a general container for testing untrusted patches 
> safely?)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

Trying out patches needs separate infrastructure from what Hudson
already provides AFAIK, plus as you point out there are various
sandboxing issues.

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Jeremy Dunck]

On Sun, Apr 25, 2010 at 5:37 PM, yml  wrote:
...
> While spending some more time looking at launchpad.net I stumbled upon
> another very neat feature you can also sort the bug by heat [1].

Thanks for this -- I'll be reading it shortly.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Jeremy Dunck]

On Sun, Apr 25, 2010 at 1:27 AM, Stephen Wolff  wrote:
>> I recognize running tests w/ regressions pass would be useful, but
>> it's getting into CI-land -- once we have some CI infrastructure in
>> place, I'd be happy to use that.
>>
>>
>
> In case you missed it, there already is some CI infrastructure a bunch
> of servers made available to django for testing via Hudson:
>
> http://hudson.djangoproject.com/
>

I knew Eric was noodling on it, but didn't know it was up.

Eric, two questions:
1) is there (or could there easily be) a way to run the suite against
uncommitted patches (or a mirror repo with branch-per-patch attempt)?

2) in general, what happens if a malicious patch is run?  I'm not
looking for total sandbox here -- but at least the understanding that
putting a machine into the test system means taking the risk that the
machine gets rm -rf'd or similar.

(Does anyone know of a general container for testing untrusted patches safely?)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Owen Nelson]

In this case you're compressing at runtime... or am I missing something?

I think I'm just going to burrow for a little while and prototype some
helpers.  I've got a project coming up shortly with some room for R on
this front, so hopefully I'll be able to put them into production for a
while before I bug anyone again.
I'll be back (at some point) when I've got something I think will
benefit the community.

Thanks for all the interest in the topic though - I think that proves we
are all hungering for *something* even if we're not exactly sure as to
what it is.

Silvio wrote:
> Consider taking a look at an app I wrote, 
> http://www.sgawebsites.com/projects/django-aggregator/.
>
> It aggregates all JS and CSS files using a very simple syntax. It can
> also pipe the content through YUI Compressor before saving the
> aggregate.
> My aim was to make it extremely easy to use. It's not an asset manager
> though; I've yet to see or come up with a great solution.
>
> Regards,
>
> Silvio
>   

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: @Meebo - 2 Django Contractors Needed!

[Russell Keith-Magee]

On Fri, Apr 30, 2010 at 4:24 PM, Joshua Partogi
 wrote:
> I've noticed that the mailing list name 'django-developers' always
> creates confusion for first time users.

You aren't the first person to make this suggestion. Here's the most
recent discussion about the topic that I could find:

http://groups.google.com/group/django-users/browse_thread/thread/f7e60519fef30d2f

My opinion hasn't changed since that time.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: @Meebo - 2 Django Contractors Needed!

[Joshua Partogi]

I've noticed that the mailing list name 'django-developers' always
creates confusion for first time users.

Kind regards,
Joshua

--
http://twitter.com/scrum8

On Apr 28, 9:51 am, Alex Gaynor  wrote:
> On Tue, Apr 27, 2010 at 7:14 PM, Kiko Griffin  wrote:
> > Hello All,
>
> > Thanks for reviewing and sharing with your network.  We are actively hiring
> > 2 Django Developers on a contract basis (3-6 months) with an opportunity to
> > convert full-time if interested.  I am hoping to fill the two openings by
> > the end of the week, so if interested please reply directly to
> > k...@meebo-inc.com immediately!
>
> > In case we're not on your radar, Meebo is a web based instant messaging
> > client that serves over 95 million users and allows you to chat with your
> > friends no matter what chat service they call home. We're now starting to
> > show up on top content sites, such as Mashable and Justin.tv, as an embedded
> > universal chat and sharing feature called Community IM. We are also known
> > for the innovative rich media and interactive ads we've developed for some
> > of the top brands in the world for display on our site and on partner sites
> > through Community IM. These activities have all led to quite an upswing in
> > media buzz about meebo making now a great time to consider joining our team.
>
> > Job Description:
>
> > Django Development Contractor
>
> > Meebo's Django Development Contractor will join the UX team and work
> > directly on developing the core site pages. Our ideal candidate will have a
> > passion for developing clean content-driven user interfaces, an eye for
> > off-by-one pixel issues, and a ninja at the art of Django. This is a
> > fantastic opportunity to apply your talents in a fun, fast paced startup
> > environment. Members of our team tend to be nice, humble, genuine, and fun!
>
> > Responsibilities include:
>
> >    * Work towards weekly and bi-weekly deadlines on the creation and
> > development of high-visibility, high-quality content-driven user interfaces
> >    * Work collaboratively with developers and visual designers to ensure a
> > clean product
> >    * Assist in testing regularly scheduled releases
> >    * Willingness to have fun and be part of an exciting growing team! Did we
> > mention fun?
>
> > Our ideal candidate will have:
>
> >    * 2+ years solid experience in building sites with Django
> >    * 2+ years of experience in HTML, visual/Web design
> >    * Degree in Human Computer Interaction, Computer Science (or equivalent)
> >    * Excellent communication and collaboration skills
> >    * A fastidious attention to detail (you noticed the double space in the
> > intro paragraph)
> >    * Previous experience with DHTML, CGI, CSS, JavaScript, AJAX, Python and
> > other Web applications a plus
> >    * An appreciation for visual design (e.g. color schemes, typography, and
> > layouts)
> >    * An obsession with delivering the best user experience possible
> >    * A passion for visual design and Web technologies and the desire to work
> > in a fast-paced, collaborative, and fun environment!
>
> > Look forward to connecting with you!
>
> > Regards,
>
> > Kiko
> > k...@meebo-inc.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> The django-developers list is for discussion about the development of
> django itself, and as such this message is inapprorpiate.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.