incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher (Apache)" <>
Subject Re: Questions ad Allura ...
Date Sat, 25 Aug 2012 10:47:35 GMT
Hi Dave,

thank you for your feedback, which leaded to the creation of the following four tickets, hoping
their description and content can be understood out of context as well:

  * #4792 Please allow normal users to receive notification e-mails for all commits and patches:
  * #4789 Please add links to the file's diffs for commits and patches in the notification
e-mail :
  * #4790 Allow additional fields to be shown on bug tracker:
  * #4791 Please add a popup to determine sort (fields, sorting position and kind):


On 23.08.2012 23:58, Dave Brondsema wrote:
> Hi again Rony.  Thanks for the feedback.
> On 8/23/12 5:09 AM, Rony G. Flatscher (Apache) wrote:
>> Hi Dave,
>> On 22.08.2012 20:00, Dave Brondsema wrote:
>>> Patches:  Perhaps I am not understanding the problem clearly.  Are you
>>> talking about a ticket in your "Patches" tracker?  E.g.
>>>  On there I can see the
>>> attached patch file and can open it fine.  If you are subscribed to a
>>> ticket, you should get an email when a file is attached.  It'll have the
>>> attachment metadata, but not the whole file included.  Emailing the
>>> attachments could be a problem if they are very large.  Can you provide
>>> an example if I'm not on the right track here?
>> Maybe the following helps understand the built  "attitude/expectation" better: when
following a
>> project like ooRexx over the years as a former/potential developer it is important
to learn about
>> *all* supplied patches and *all* commits in general. Then, if patches, commits occur
it used to be
>> the case that an e-mail including the diffs got sent out via a relay-e-mail-list
and anyone who
>> subsribed to that e-mail list received it. Now, the diffs embedded in the e-mail
would not be
>> necessary, if the e-mail contained a list of files that got changed each with a link
to get to its
>> diff (and ultimately one link that would present all diffs at once). For study purposes
or merely
>> documentation printing out those diffs (either physically or as a pdf) is important,
if an area got
>> changed that one has special interest in.
>> Following a specific tracker item needs the prerequisite, that one learns that a
tracker item got
>> created in the first place, which is quite cumbersome. [In the example
>> "" one would be able to get access to
the patch
>> attachment, but I have not found a way to display it inline with color highlighting.]
>> So maybe the bottom line would be: allow for sending out any patch (and commit) via
a relay
>> e-mail-list, which can be subscribed by interested parties. This would allow for
a push model, where
>> one would be informed that a patch (commit) got submitted/applied. If that e-mail
contained the
>> aforementioned links to get to diffs (on each file or optionally having one big diff
for all
>> affected files), then this would be great!
> There is a setting that should get you most of the way there, I think.
> If you go to Admin, Tools and then click on Options for the tracker,
> there is a "Email ticket notifications to:" field.
> The remaining piece would be to easily get to the attached patches.
> Allura doesn't have that now, but a new ticket to make the attachment
> references include a direct link seems appropriate.
>>> Sorting bugs:  There is a ticket
>>> for making the sort order
>>> oldest-first by default.  Several people have voted for it already, so
>>> we'll probably get to it soon.  Of course, patches are welcome too :)
>>> After you do a search, there is a 'Help' button near the search box.
>>> That help box details the fields available for searching and sorting
>>> (near the bottom of that help box).
>> Thank you, yes, I have studied the help box. (It seems that now the initial order
of the bug tracker
>> is newest first, oldest last, which is great! However, when doing a search on the
bug tracker
>> system, the order is oldest first, newest last.)
>> Here there would be the following ideas/requests: allow for displaying the column
>> and in addition allow/show a field/column "reported on".and "mod_date_dt".
>> Also, in general a RFE (not sure whether I should open a ticket for it) for sorting:
how about
>> having a popup (like the field popup where one can determine which fields to display)
that displays
>> all sortable fields which one can activate for sorting (having a radio button group
of "ascending",
>> "descending", "none") and which allows to move the fields up and down to determine
the sorting
>> order, if sorting should be done on more than one field and make it saveable for
the user as well?
>> (If such a definable sort order becomes available, then it should be applied on search
results as well.)
> Feel free to create a ticket.  A few points of reference: the "Fields"
> admin page lets you specify whether custom field display in ticket
> listings or not.  And there is a widget in the upper right of ticket
> listings to let you choose some columns to display, but its not a
> permanent setting.  And neither of those cover the fields you mention
> (reported by, on, etc)
>>> Commit diffs in emails:  I see there are a lot of votes and comments on
>>>  I assume many are from
>>> ooRexx developers.  It certainly is on our radar due to that, and
>>> something we'd like to add.  When subscribed (btw, admins are
>>> automatically subscribed to all tools including SVN) emails will be sent
>>> with each commit, including a link to view the diff.
>> Maybe making this feature available for regular users (maybe as an option to activate)
would already
>> solve this requeust?
> Yeah, I agree.
>>> In the mean time, you could consider using the RSS feed at
>>>  I know that's not as good
>>> as an email.  We also want to get svn-notify available as a post-commit
>>> hook, but it isn't available yet.
>> Great, thank you, looking forward to it!
>> Maybe a last pointer: personally, I have been active in many opensource projects
to the point, where
>> I am totally "overdrawn". Therefore it is extremely helpful to get notifications
(but also to be
>> able to turn them off, if too many come along).
>> ---
>> Ad "patches are welcome": please believe me, if I had time available, I would love
to help!
>> Unfortunately, at this time I have been overwhelmed with too much work and projects
and simply do
>> not have the resources free to help personally in this interesting project. The only
thing I can do
>> at the moment is trying to give constructive feedback and trying to explain the reasons
why I would
>> request something that seems to be very importang/helpful as a person who has been
following and
>> participating in sourceforge projects for many years. [I think everyone on the ooRexx
>> team is courageous, adventerous and constructively trying to adopt the new Allura
system. It seems
>> that this is of mutual benefit bringing experienced opensource developers together
to help each other!]
>> ---rony
>>> On 8/22/12 6:15 AM, Rony G. Flatscher (Apache) wrote:
>>>> Hi there,
>>>> having been many years interested/active in <>
I have
>>>> experienced the project's switch to Allura.
>>>> The project is a long standing one, which means that the trackers have quite
a few entries and
>>>> developers have been accustomed to learning/seeing/printing code diffs right
away to make it easy to
>>>> study what got changed.
>>>> After some time of using the new system (to get accustomed to it) there are
many, many
>>>> questions/problems opened, some of which can be answered/solved on the ooRexx
developer list, some
>>>> via Allura-trackers, but it seems for very important aspects of a developer
system, there is (yet?)
>>>> no solution or knowledge available.
>>>> Therefore I would like to kindly request comments/hints/pointers to the following
three items, that
>>>> are coming into ones way, being accustomed to the old system and not having
found the counterparts
>>>> in the new Allura:
>>>>     -------- Original Message --------
>>>>     Subject: 	[Oorexx-devel] Ad Allura interface: a few questions ...
>>>>     Date: 	Wed, 22 Aug 2012 09:50:29 +0200
>>>>     From: 	Rony G. Flatscher
>>>>     Reply-To: 	Open Object Rexx Developer Mailing List <>
>>>>     To: 	Open Object Rexx Developer Mailing List <>
>>>>     Sorry, if this has been answered already, just do not know the latest
>>>>       * Ad Patches: it is possible (following Mark's directions) to subscribe
Patch messages by
>>>>         merely pressing the envelope symbol on the Patch UI. However, how
would one be able to see
>>>>         the patch file (the diffs) from such a message?
>>>>           o One (a little bit cumbersome) way is to look in the left pane
of commits and somehow
>>>>             pick the right commit from the bullet list that appears after
a while in the center
>>>>             pane. However, once one gets to the diff page and tries to print
it, the printout does
>>>>             not contain any of the nicely formatted code! :(
>>>>       * Ad Bugs: is it possible to get the opening date, the submitter, such
that one becomes able
>>>>         to sort by them as well. It is strange that the order of showing
tracker entries is from
>>>>         oldest to latest, rather than the other way round (maybe the developers
only use small
>>>>         databases where the order does not matter for them, but in a long
standing project one may
>>>>         have hundreds, maybe more tracker entries).
>>>>       * Ad svn commit diffs: it would be great, if the commit message contained
links directly to
>>>>         the files that got committed with links to diffs. (The same would
be helpful for any code
>>>>         submission, including the patches).
>>>>     Is there anything I could do to help get the above items tackled/resolved
>>>>     ---rony
>>>> Thanks in advance for any comments/hints/pointers (maybe time frames to expect
feature changes that
>>>> could help)!
>>>> N.B.: Please excuse my addressing this to allura-users and allura-dev, as
I do not know which e-mail
>>>> list is appropriate for such questions.
>>>> ---rony

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message