You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Mark Thomas <ma...@apache.org> on 2006/12/19 01:36:28 UTC
Help needed?
Hi,
Following up on the recent thread on general@jakarta is there anything
I can do to lend a hand around releases and the like?
Regards,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Help needed?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/20/06, Nick Burch <ni...@torchbox.com> wrote:
> On Mon, 18 Dec 2006, Mark Thomas wrote:
> > Following up on the recent thread on general@jakarta is there anything I
> > can do to lend a hand around releases and the like?
>
> Henri's given us a long list of things we should try to sort out in the
> builds. I'm planning to try to fix all of them over Christmas (few long
> train journeys should help), but it'd be useful to have another set of
> eyes looking over the new build process when it's sorted.
KEYS file is top of my list in terms of fixing things.
> It looks like we're going to aim for a FINAL release in the early new
> year, so whoever opts to be release manager for it will probably ping you
> to check they've remembered everything, if that's ok?
A final in the new year would be very cool.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Help needed?
Posted by Mark Thomas <ma...@apache.org>.
Nick Burch wrote:
> On Mon, 18 Dec 2006, Mark Thomas wrote:
>> Following up on the recent thread on general@jakarta is there anything I
>> can do to lend a hand around releases and the like?
>
> Henri's given us a long list of things we should try to sort out in the
> builds. I'm planning to try to fix all of them over Christmas (few long
> train journeys should help), but it'd be useful to have another set of
> eyes looking over the new build process when it's sorted.
>
> It looks like we're going to aim for a FINAL release in the early new
> year, so whoever opts to be release manager for it will probably ping you
> to check they've remembered everything, if that's ok?
Happy to. I'll check out trunk and get the build running on my machine
in the mean time. If you want a hand with any of the specific tasks -
just shout.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
Re: Jakarta Voting
Posted by "C.Grobmeier" <gr...@possessed.de>.
Hi,
> I think that Jakarta needs a voting application that can include PMC
> quorum requirements, direct email vote requests, committer approval,
> etc.
do you really expect people to click at a link in an email and vote via webinterface when they don't press reply and write +1? :-)
Cheers,
Chris
P.S.: for archiving reasons it may be good
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Roland Weber <ht...@dubioso.net>.
Hi Henri,
> [...] I was mostly thinking
> about it because I felt like writing something new rather than
> maintaining code):
That's the best reason of all :-)
> * Simplifies calling a vote.
> * Adds a better audit trail.
> * Can know about the binding votes and it can decide whether a vote is
> successful or not.
> * Enforces things - so having an end date to a vote for example.
>
> Problems it causes:
>
> * Might make us vote more often rather than just agree consensus has
> been reached.
* Complicates casting a vote
> Thoughts on implementation.
> [...]
> It needs to be listening to emails,
> [...]
> Vote through the webapp and not an email,
> [...]
> People often comment with a vote
> though
> [...]
> Another would be to just monitor the mailing list. Create a bot that
> listens to emails and a script that sends out emails in a particular
> format. Might work, but parsing replies would probably suck.
Correct me if I am wrong: the actual collecting of the votes from
a vote thread is not that time-consuming, or is it? The following
sorting and checking for binding/non-binding status is the really
tedious work?
If somebody feels like simplifying the voting by coding, I would
rather suggest to define a simple text input format for votes. The
one who called the vote goes through the replies and collects all
votes into a text file, in random (or chronological) order. That
could look like this:
# allowed votes
+1 +0 -0 -1
# cast votes
-0 whoever@test.invalid
+1 somebody@test.invalid
...
That text file can then be processed by a script which:
- checks for invalid votes (like -0 if only +1, -1 are allowed)
- checks for duplicates (somebody changing his or her vote)
- checks for binding/non-binding status based on email address
- sorts the cast votes into groups
- generates a text summary for pasting into an email
That alone is tricky enough, if one should consider MailAliases.txt
for the binding/non-binding check and maybe also the duplicate check.
With a plain text format as the input, it is also easier to create
an exhaustive set of unit test cases. Compare that to setting up a
new mailing list plus generating emails there just for testing the
voting application.
But what I like most about this approach is that the voter experience
doesn't change. You can still reply by email using informal language.
The original mail can be quoted internet style, or TOFU, or not at
all. You can write your +1 above the quote, or below, or you put
your X into the line the lists the appropriate vote option, or you
embed it in natural language. If the mails are parsed automatically,
expect communications like this:
>> Here's my +1.
>>
> Could you write that again with just the +1 in a single line,
> with an empty line before and after?
or if the parser is more flexible:
>> I would have voted +1, but I'd like to get an answer to the
>> following question first: [...]
>
> Oh, sorry, that was counted as +1 by the voting application.
> Could you send another mail with the text 1-- to undo that?
Such syntactical ambiguities are easily enough resolved by
an HVC preprocessor (Human Vote Collector) before the script
ever gets to see the data.
Mandating that votes be cast through a web application would
solve the input format problem. But it would also require the
voter to change from the email application to a web browser,
and maybe from the keyboard to the mouse, to cast the vote.
That may not be much of a problem (except for accessibility),
but it is surely not an improvement of the voter experience.
Vote casting by email encourages the lively discussions that
are so important for community building ;-)
Once such a script is done and thoroughly tested, there is still
time to think about an automated input interface. I would suggest
connecting to the mailing list archive rather than to the
mailing list though. Since vote threads run for several days,
you can't expect the voting application to run through without
interruption. To allow for regular shutdown and startup, you'd
need a persistent data store for the votes that have already been
counted. Even so, if there is a crash and the server needs to be
restored from a backup, the mails that came in between the backup
and the crash would not be counted.
And I guess no automated tool can deal with off-thread votes.
Consider a controversial vote that is started, and people joining
the mailing list afterwards just to cast their votes. These folks
will not have the original mail to reply to. They might reply to
another mail in that thread, or they might just type the subject
line into a new mail. In the latter case, the mail would not be
considered as belonging to the vote thread, or would it?
In summary: if somebody wants to spend time on simplifying
vote counting, I recommend to focus on the actual counting
while leaving it to the human who called for the vote to
collect the input. That should also help to keep the number
of vote calls in check :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Jesse Kuhnert <jk...@gmail.com>.
Maybe someone could just create a script of some sort to parse out the
vote tallies from a group of emails? ..
On 12/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> I don't know... a secure webapp for votes seems overkill for most situations.
>
> I like the informal nature of the voting on the lists. It encourages
> participation. People can vote with non-binding votes, which is a
> good thing, I think -- they get to express their opinion and influence
> the discussion (as long as it's clear who counts and who doesn't).
> Voting can also be used for small issues (such as a new capability) as
> well as big issues (releases)-- there's a continuum.
>
> Has there ever been a case of a fraudulent emailed vote? The public
> nature of the voting means that as long as the real person is reading
> email, such a vote would be quickly noted.
>
> WILL
>
> On 12/21/06, Henri Yandell <ba...@apache.org> wrote:
> > On 12/20/06, David Fisher <df...@jmlafferty.com> wrote:
> > > Hi Jakarta Board-
> > >
> > > A suggestion after reading with interest the recent POI vs. Jakarta
> > > smoke and flames threads.
> > >
> > > I think that Jakarta needs a voting application that can include PMC
> > > quorum requirements, direct email vote requests, committer approval,
> > > etc.
> > >
> > > Maybe it already exists?
> > >
> > > Anyone want to +1 this ;-)
> >
> > Was pondering on this a little while ago.
> >
> > Problems it solves (and they're not very big, so I was mostly thinking
> > about it because I felt like writing something new rather than
> > maintaining code):
> >
> > * Simplifies calling a vote.
> > * Adds a better audit trail.
> > * Can know about the binding votes and it can decide whether a vote is
> > successful or not.
> > * Enforces things - so having an end date to a vote for example.
> >
> > Problems it causes:
> >
> > * Might make us vote more often rather than just agree consensus has
> > been reached.
> >
> > Problems it shouldn't solve:
> >
> > * Security. We're not currently secure - I could send an email as
> > someone else's name to the list and vote for them. It's hard to get
> > secure and yet still encourage contributors to throw in their +1s or
> > -1s.
> >
> > ------
> >
> > Thoughts on implementation.
> >
> > It needs to use some svn files behind the scenes to know that someone
> > is in a PMC (and thus binding). That's easy enough - there's a file
> > that contains that, though the formatting sucks.
> >
> > It needs to be listening to emails, and communicate with a mailing
> > list. It needs to offer archival view via a webapp, and a current
> > state view through a webapp. Calling a vote is interesting - ideally
> > we'd limit that to committers simply to stop from getting spammed,
> > however that means the webapp (presuming the webapp would be the one
> > that held the admin system) would need to know about auth.
> >
> > As we get more and more into auth, it becomes tempting to auth the
> > whole thing. Vote through the webapp and not an email, put it behind
> > SSL and the svnpasswd file (which is just htaccess from memory -
> > though getting access to that file might be tricky). Still allow a
> > guest vote.
> >
> > Allowing a guest vote still raises spam as a possibility if we have
> > each vote be sent to the list. Possibly the solution is for the voting
> > tool to send voting summaries rather than votes themselves. Daily it
> > could send out the current state. People often comment with a vote
> > though - so that would be weak to not send it to the list.
> >
> > Another option is to tie into the list management - let emails who are
> > subscribed vote. Painful dealing with ezmlm I suspect.
> >
> > Another would be to just monitor the mailing list. Create a bot that
> > listens to emails and a script that sends out emails in a particular
> > format. Might work, but parsing replies would probably suck. That
> > could be completely webapp-less; more like an IRC bot for an email
> > list.
> >
> > The only existing vote stuff at the ASF is for member/board voting
> > each year, but that's ssh/email and defined to be secure and private.
> > Not much use for us.
> >
> > Think that's about where my thinking got...
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Will Glass-Husain <wg...@forio.com>.
I don't know... a secure webapp for votes seems overkill for most situations.
I like the informal nature of the voting on the lists. It encourages
participation. People can vote with non-binding votes, which is a
good thing, I think -- they get to express their opinion and influence
the discussion (as long as it's clear who counts and who doesn't).
Voting can also be used for small issues (such as a new capability) as
well as big issues (releases)-- there's a continuum.
Has there ever been a case of a fraudulent emailed vote? The public
nature of the voting means that as long as the real person is reading
email, such a vote would be quickly noted.
WILL
On 12/21/06, Henri Yandell <ba...@apache.org> wrote:
> On 12/20/06, David Fisher <df...@jmlafferty.com> wrote:
> > Hi Jakarta Board-
> >
> > A suggestion after reading with interest the recent POI vs. Jakarta
> > smoke and flames threads.
> >
> > I think that Jakarta needs a voting application that can include PMC
> > quorum requirements, direct email vote requests, committer approval,
> > etc.
> >
> > Maybe it already exists?
> >
> > Anyone want to +1 this ;-)
>
> Was pondering on this a little while ago.
>
> Problems it solves (and they're not very big, so I was mostly thinking
> about it because I felt like writing something new rather than
> maintaining code):
>
> * Simplifies calling a vote.
> * Adds a better audit trail.
> * Can know about the binding votes and it can decide whether a vote is
> successful or not.
> * Enforces things - so having an end date to a vote for example.
>
> Problems it causes:
>
> * Might make us vote more often rather than just agree consensus has
> been reached.
>
> Problems it shouldn't solve:
>
> * Security. We're not currently secure - I could send an email as
> someone else's name to the list and vote for them. It's hard to get
> secure and yet still encourage contributors to throw in their +1s or
> -1s.
>
> ------
>
> Thoughts on implementation.
>
> It needs to use some svn files behind the scenes to know that someone
> is in a PMC (and thus binding). That's easy enough - there's a file
> that contains that, though the formatting sucks.
>
> It needs to be listening to emails, and communicate with a mailing
> list. It needs to offer archival view via a webapp, and a current
> state view through a webapp. Calling a vote is interesting - ideally
> we'd limit that to committers simply to stop from getting spammed,
> however that means the webapp (presuming the webapp would be the one
> that held the admin system) would need to know about auth.
>
> As we get more and more into auth, it becomes tempting to auth the
> whole thing. Vote through the webapp and not an email, put it behind
> SSL and the svnpasswd file (which is just htaccess from memory -
> though getting access to that file might be tricky). Still allow a
> guest vote.
>
> Allowing a guest vote still raises spam as a possibility if we have
> each vote be sent to the list. Possibly the solution is for the voting
> tool to send voting summaries rather than votes themselves. Daily it
> could send out the current state. People often comment with a vote
> though - so that would be weak to not send it to the list.
>
> Another option is to tie into the list management - let emails who are
> subscribed vote. Painful dealing with ezmlm I suspect.
>
> Another would be to just monitor the mailing list. Create a bot that
> listens to emails and a script that sends out emails in a particular
> format. Might work, but parsing replies would probably suck. That
> could be completely webapp-less; more like an IRC bot for an email
> list.
>
> The only existing vote stuff at the ASF is for member/board voting
> each year, but that's ssh/email and defined to be secure and private.
> Not much use for us.
>
> Think that's about where my thinking got...
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Roland Weber <ht...@dubioso.net>.
Hi Danny,
> It would only be necessary for binding votes to be signed. No?
That's a possibility. On the other hand, that could send
a wrong signal to the non-binding voters: you don't have
to sign your votes, they're not important anyway. I'd be
very careful with such distinctions.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Danny Angus <Da...@slc.co.uk>.
Roland Weber <ht...@dubioso.net> wrote on 22/12/2006 09:21:51:
> Hi Danny,
>
> >> As we get more and more into auth, it becomes tempting to auth the
> >> whole thing. Vote through the webapp and not an email,
> >
> > You could sign your mail with a key you register for the purpose.
>
> that's a big hurdle for a guest voter.
It would only be necessary for binding votes to be signed. No?
*******************************************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
********************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Roland Weber <ht...@dubioso.net>.
Hi Danny,
>> As we get more and more into auth, it becomes tempting to auth the
>> whole thing. Vote through the webapp and not an email,
>
> You could sign your mail with a key you register for the purpose.
that's a big hurdle for a guest voter.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Danny Angus <Da...@slc.co.uk>.
> As we get more and more into auth, it becomes tempting to auth the
> whole thing. Vote through the webapp and not an email,
You could sign your mail with a key you register for the purpose.
> listens to emails and a script that sends out emails in a particular
> format. Might work, but parsing replies would probably suck.
You'd be suprised.. If the rule is that everyone must return a signed
reply to the original mail and enclose their vote in [] ensuring that
there's only one [] it mightn't be too hard.
d.
*******************************************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
********************************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta Voting
Posted by Henri Yandell <ba...@apache.org>.
On 12/20/06, David Fisher <df...@jmlafferty.com> wrote:
> Hi Jakarta Board-
>
> A suggestion after reading with interest the recent POI vs. Jakarta
> smoke and flames threads.
>
> I think that Jakarta needs a voting application that can include PMC
> quorum requirements, direct email vote requests, committer approval,
> etc.
>
> Maybe it already exists?
>
> Anyone want to +1 this ;-)
Was pondering on this a little while ago.
Problems it solves (and they're not very big, so I was mostly thinking
about it because I felt like writing something new rather than
maintaining code):
* Simplifies calling a vote.
* Adds a better audit trail.
* Can know about the binding votes and it can decide whether a vote is
successful or not.
* Enforces things - so having an end date to a vote for example.
Problems it causes:
* Might make us vote more often rather than just agree consensus has
been reached.
Problems it shouldn't solve:
* Security. We're not currently secure - I could send an email as
someone else's name to the list and vote for them. It's hard to get
secure and yet still encourage contributors to throw in their +1s or
-1s.
------
Thoughts on implementation.
It needs to use some svn files behind the scenes to know that someone
is in a PMC (and thus binding). That's easy enough - there's a file
that contains that, though the formatting sucks.
It needs to be listening to emails, and communicate with a mailing
list. It needs to offer archival view via a webapp, and a current
state view through a webapp. Calling a vote is interesting - ideally
we'd limit that to committers simply to stop from getting spammed,
however that means the webapp (presuming the webapp would be the one
that held the admin system) would need to know about auth.
As we get more and more into auth, it becomes tempting to auth the
whole thing. Vote through the webapp and not an email, put it behind
SSL and the svnpasswd file (which is just htaccess from memory -
though getting access to that file might be tricky). Still allow a
guest vote.
Allowing a guest vote still raises spam as a possibility if we have
each vote be sent to the list. Possibly the solution is for the voting
tool to send voting summaries rather than votes themselves. Daily it
could send out the current state. People often comment with a vote
though - so that would be weak to not send it to the list.
Another option is to tie into the list management - let emails who are
subscribed vote. Painful dealing with ezmlm I suspect.
Another would be to just monitor the mailing list. Create a bot that
listens to emails and a script that sends out emails in a particular
format. Might work, but parsing replies would probably suck. That
could be completely webapp-less; more like an IRC bot for an email
list.
The only existing vote stuff at the ASF is for member/board voting
each year, but that's ssh/email and defined to be secure and private.
Not much use for us.
Think that's about where my thinking got...
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Jakarta Voting
Posted by David Fisher <df...@jmlafferty.com>.
Hi Jakarta Board-
A suggestion after reading with interest the recent POI vs. Jakarta
smoke and flames threads.
I think that Jakarta needs a voting application that can include PMC
quorum requirements, direct email vote requests, committer approval,
etc.
Maybe it already exists?
Anyone want to +1 this ;-)
Regards,
Dave Fisher
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Help needed?
Posted by Rainer Klute <kl...@rainer-klute.de>.
Nick Burch schrieb:
> Henri's given us a long list of things we should try to sort out in the
> builds. I'm planning to try to fix all of them over Christmas (few long
> train journeys should help), but it'd be useful to have another set of
> eyes looking over the new build process when it's sorted.
>
I can at least run the build on my machine and check whether I notice
anything obvious.
Best regards
Rainer Klute
Rainer Klute IT-Consulting GmbH
Dipl.-Inform.
Rainer Klute E-Mail: klute@rainer-klute.de
Körner Grund 24 Telefon: +49 172 2324824
D-44143 Dortmund Telefax: +49 231 5349423
OpenPGP fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E
Re: Help needed?
Posted by Nick Burch <ni...@torchbox.com>.
On Mon, 18 Dec 2006, Mark Thomas wrote:
> Following up on the recent thread on general@jakarta is there anything I
> can do to lend a hand around releases and the like?
Henri's given us a long list of things we should try to sort out in the
builds. I'm planning to try to fix all of them over Christmas (few long
train journeys should help), but it'd be useful to have another set of
eyes looking over the new build process when it's sorted.
It looks like we're going to aim for a FINAL release in the early new
year, so whoever opts to be release manager for it will probably ping you
to check they've remembered everything, if that's ok?
Thanks
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/