new JIRA plugin: planning board

hello,

i've installed the GreenHopper 'planning board' plugin for JIRA.  this 
provides a different way to view issues.  at the moment it's using an 
evaluation license; if people are interested in using it, let me know and 
i'll request a free license.

you can access it via the 'planning board' link in the jira menu.

	- river.

hello,

i've installed the GreenHopper 'planning board' plugin for JIRA.  this 
provides a different way to view issues.  at the moment it's using an 
evaluation license; if people are interested in using it, let me know and 
i'll request a free license.

you can access it via the 'planning board' link in the jira menu.

	- river.

stable server candidates

hello,

to justify buying a stable server, we need people willing to use it.  so, if 
anyone is interested in maintaining stable tools, please add your name 
somewhere (i suggest [[m:Toolserver/Stable server/Candidates]] as a good 
place).  the initial proposal suggested at least two maintainers per project, 
but that isn't set in stone.  more maintainers is probably better.

* do not add other people's projects, or list other people as maintainers 
without asking them.  don't add yourself as a maintainer without checking 
with the tool's author.

* you can list people without toolserver accounts.

this is only for stable, established projects; if your project still breaks 
hemlock once a week, or you aren't certain it's working well, please don't 
add it.  similarly, new project proposals will not be considered (these 
should go to hemlock instead).

if the stable server goes ahead, projects which are accepted will no longer be 
owned by the original author; the development team members will each have 
equal responsibility in their development. 

the exact configuration of the stable server, how it'll work, etc. are still 
in discussion.  (please feel free to edit [[m:Toolserver/Stable server]] if 
you have any suggestions).

	- river.

Re: stable server candidates

stable as in "stable versions"?

On 11/3/07, River Tarnell <river <at> wikimedia.org> wrote:
> hello,
>
> to justify buying a stable server, we need people willing to use it.  so, if
> anyone is interested in maintaining stable tools, please add your name
> somewhere (i suggest [[m:Toolserver/Stable server/Candidates]] as a good
> place).  the initial proposal suggested at least two maintainers per project,
> but that isn't set in stone.  more maintainers is probably better.
>
> * do not add other people's projects, or list other people as maintainers
> without asking them.  don't add yourself as a maintainer without checking
> with the tool's author.
>
> * you can list people without toolserver accounts.
>
> this is only for stable, established projects; if your project still breaks
> hemlock once a week, or you aren't certain it's working well, please don't
> add it.  similarly, new project proposals will not be considered (these
> should go to hemlock instead).
>
> if the stable server goes ahead, projects which are accepted will no longer be
> owned by the original author; the development team members will each have
> equal responsibility in their development.
>
> the exact configuration of the stable server, how it'll work, etc. are still
> in discussion.  (please feel free to edit [[m:Toolserver/Stable server]] if
> you have any suggestions).
>

Re: stable server candidates

Oh, stable as opposed to instable. Never mind.

On 11/3/07, James Hare <messedrocker <at> gmail.com> wrote:
> stable as in "stable versions"?
>
> On 11/3/07, River Tarnell <river <at> wikimedia.org> wrote:
> > hello,
> >
> > to justify buying a stable server, we need people willing to use it.  so, if
> > anyone is interested in maintaining stable tools, please add your name
> > somewhere (i suggest [[m:Toolserver/Stable server/Candidates]] as a good
> > place).  the initial proposal suggested at least two maintainers per project,
> > but that isn't set in stone.  more maintainers is probably better.
> >
> > * do not add other people's projects, or list other people as maintainers
> > without asking them.  don't add yourself as a maintainer without checking
> > with the tool's author.
> >
> > * you can list people without toolserver accounts.
> >
> > this is only for stable, established projects; if your project still breaks
> > hemlock once a week, or you aren't certain it's working well, please don't
> > add it.  similarly, new project proposals will not be considered (these
> > should go to hemlock instead).
> >
> > if the stable server goes ahead, projects which are accepted will no longer be
> > owned by the original author; the development team members will each have
> > equal responsibility in their development.
> >
> > the exact configuration of the stable server, how it'll work, etc. are still

Re: stable server candidates

James Hare:
> stable as in "stable versions"?

http://meta.wikimedia.org/wiki/Toolserver/Stable_server

	 - river.

A: Because it disrupts the natural flow of conversation.
Q: Why is top-posting bad?

James Hare:
> stable as in "stable versions"?

http://meta.wikimedia.org/wiki/Toolserver/Stable_server

	 - river.

A: Because it disrupts the natural flow of conversation.
Q: Why is top-posting bad?

new JIRA plugin: planning board

I strongly recommend requesting the license, I find it a great little 
resource that the JIRA users can use.  I watched the introduction video on 
GreenHopper's website yesterday and learnt how to use the addon, it is quite 
user friendly. I don't know about anyone else, but I will sure use it if it 
becomes a permanent addon.

Kind regards,

User:E
English Wikipedia

--------------------------------------------------
From: "River Tarnell" <river <at> wikimedia.org>
Sent: Saturday, November 03, 2007 10:35 PM
To: <toolserver-l <at> lists.wikimedia.org>
Subject: [Toolserver-l] new JIRA plugin: planning board

hello,

i've installed the GreenHopper 'planning board' plugin for JIRA.  this
provides a different way to view issues.  at the moment it's using an
evaluation license; if people are interested in using it, let me know and
i'll request a free license.

you can access it via the 'planning board' link in the jira menu.

	- river. 

Re: stable server candidates

i have borrowed ragweed from Wikimedia to do testing of the stable server on 
(e.g. figuring out how things are going to work).  so, if you're interested 
in testing it, and have a candidate project, let me know...

	- river.

i have borrowed ragweed from Wikimedia to do testing of the stable server on 
(e.g. figuring out how things are going to work).  so, if you're interested 
in testing it, and have a candidate project, let me know...

	- river.

ipblocks table available

I have created a view for the ipblocks table.  This view hides private
data related to autoblocks.

There were two possible ways that I could have created this view. I
could have created so that it hides all autoblocks, or I could have
created it so that it only hides the private data in autoblocks.

The second choice is obviously more flexible, but it prevents the use
of indexes on the ip address columns (ipb_address, ipb_range_start,
ipb_range_end).

Because the ipblocks tables are fairly small (even on large projects
like enwiki) and because some tools already do things with autoblocks,
I have decided to choose this slower option.

If we have performance problems related to this view, I will change
the it to the first type without any autoblocks, and potentially
provide a second autoblocks only view for tools that need to see the
autoblocks.

Re: ipblocks table available

<div>
Don't forget ipb_deleted. Eventually that should require Oversight access to view things flagged with that.<br><br>-Aaron Schulz<br><br>&gt; Date: Mon, 5 Nov 2007 16:57:13 -0500<br>&gt; From: gmaxwell <at> gmail.com<br>&gt; To: toolserver-l <at> lists.wikimedia.org<br>&gt; Subject: [Toolserver-l] ipblocks table available<br>&gt; <br>&gt; I have created a view for the ipblocks table.  This view hides private<br>&gt; data related to autoblocks.<br>&gt; <br>&gt; There were two possible ways that I could have created this view. I<br>&gt; could have created so that it hides all autoblocks, or I could have<br>&gt; created it so that it only hides the private data in autoblocks.<br>&gt; <br>&gt; The second choice is obviously more flexible, but it prevents the use<br>&gt; of indexes on the ip address columns (ipb_address, ipb_range_start,<br>&gt; ipb_range_end).<br>&gt; <br>&gt; Because the ipblocks tables are fairly small (even on large projects<br>&gt; like enwiki) and because some tools already do things with autoblocks,<br>&gt; I have decided to choose this slower option.<br>&gt; <br>&gt; If we have performance problems related to this view, I will change<br>&gt; the it to the first type without any autoblocks, and potentially<br>&gt; provide a second autoblocks only view for tools that need to see the<br>&gt; autoblocks.<br>&gt; <br>&gt; _______________________________________________<br>&gt; Toolserver-l mailing list<br>&gt; Toolserver-l <at> lists.wikimedia.org<br>&gt; http://lists.wikimedia.org/mailman/listinfo/toolserver-l<br><br>Boo!&nbsp;Scare away worms, viruses and so much more! Try Windows Live OneCare! <a href="http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews" target="_new">Try now!</a>
</div>

Re: ipblocks table available

On Nov 5, 2007 5:35 PM, Aaron Schulz <jschulz_4587 <at> msn.com> wrote:
>  Don't forget ipb_deleted. Eventually that should require Oversight access
> to view things flagged with that.

Yep. I exclude any rows where ipb_deleted!=0.

(it's currently unused so, I'm *assuming* that my behavior is conservative)