I have been playing around with the new jira, confluence, sso,
stuff without understanding much of how it works and what it is
good for. I managed to get a sso login with a password, and to
log in into confluence, and found a link not working there.
Then I found that there is a "user page" in confluence which
displays an e-mail address of mine, which I thought I had entered
only in order to retieve a forgotten password, if need be.
It does show the e-mail address, even while I am logged out.
That means, the e-mail address is being published to the world.
I have this e-mail address now redirected to /dev/null/
(I am happy enough that, I had been using a special new address
solely for this playing around)
I shall NOT be using any of these programs, unless there is a way
to keep e-mail addresses confidential, safe, and out of the reach
of SPAMbots.
I am not mentioning URLs here on purpose, since this text will be
published in the e-mail archive, and I do not want to establish links
that could invite e-mail address collector bots.
Greetings - Purodha
I am more than unhappy with the fact that, now we are not using
mediazilla as our bug tracker, that we are not using the same
svn browser as mediawiki does, etc.
Having to learn the operation of yet another tool, and yet another tool,
and yet another bug trackers, and yet another account creation and
maintenance system, etc. is imho just a waste of my time.
I'd wish to rather be doing productive work.
Greetings - Purodha
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.
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.
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.