[TYPO3-dev] Contribution to community extensions
Jan Bartels
j.bartels at arcor.de
Sun Aug 17 22:02:42 CEST 2014
Am 17.08.2014 um 08:46 schrieb Xavier Perseguers:
> Starting with 1), shortly. I tweeted about 2 days ago that I'd like
> to see every SVN project on Forge being migrated to Git (did not say
> Git, Git+Gerrit, or GitHub, or ..., just "Git"). (My) rationale is
> that sending patches to the author or attaching them to a ticket
> sounds old-fashioned to me. BUT as Jan told us, that's the workflow
> he's currently accustomed to and he likes it as it is.
Maybe I would change to Git, but as I wrote in my original posting: I'm
not aware of the advantages of Git. It may be just a lack of information
but I have to admit that I haven't ever looked for Git actively. At
first sight the Git-approach looks complicated and confusing to me. The
only function on Github I'm using is the "Download as ZIP"-button. On
the other hand I'm used blindly to the old-school SVN as I'm using
similar VCS at work (I'm a Typo3-hobbyist only).
> USE CASE 1 ==========
>
> You - as a user - spot a problem.
>
> 1) How difficult is it to report it? It may be asking for help in
> the mailing list/forum/social network/friend/... or in a bug tracker
Mainly on Forge, though I find it hard to search for existing tickets
(especially for core issures). I think this was easier done on mantis.
If the project doesn't have an issue tracker on forge I report it to the
author via email.
> 2) Do you think of creating a ticket? Are you comfortable with that?
> Do you feel like creating a ticket means additional work such as
> going back regularly (maybe in a tool you are not usually monitoring)
> to see if there is something new?
I prefer opening a (Forge-)ticket because it helps me to track the
development of a solution and ensures a clear way of communication on a
single topic. I'm not reporting on other platforms as I don't want to
have accounts on thousands of platforms (including Github).
> 3) Regarding a bug tracker, do you get notification about changes,
> author asking for further detail, fix being prepared and waiting for
> double-check, ... or not? I must admit that some times (usually?),
> those notification land in my spam folder but as I'm "actively"
> monitoring my own stuff, it isn't a big deal.
Haven't had trouble so far.
> 4) How do you feel with *testing* a fix? You reported a bug (or
> found someone else having the same and already having reported it),
> and suddenly either a one line change is proposed in one of the
> comments or a patch is attached (typically SVN) or a review on
> Gerrit (review.typo3.org) is waiting approval, or a pull request is
> ready, ...
I apply patches like these if I'm the reporter of the ticket usually
without any delay for testing or in other cases if they are approved by
some other users. In other cases I'm waiting a few days for further
comments if I don't understand the solution if it's a minor issue.
> As a user, is it something you understand how to test, are ready and
> able to do? (productive system or local environment, FTP only or
> SSH/console/tools to apply patches, understand how a patch is to be
> "applied" or don't get what that means, ...).
I've setup a test-system with a very similar configuration like our
production system, so that I can test the patches before applying them
to the production system.
Usually I apply small patches by editing the files manually.
> USE CASE 2 ==========
>
> You - as an extension author - get a report about a problem.
>
> 1) Did you get it using the way you wanted (email if you don't have
> any bug tracker, ticket if you have a bug tracker). If that's not the
> case (e.g., email asking for help although you have a bug tracker),
> what is your standard position? Ask the person to report it again
> correctly, tell him/her that you prefer the bug tracker and creating
> the ticket yourself, informing where the follow-up will be done,
> going on with email / other method to discuss problem?
It depends on the problem. If it's a minor issue I answer emails
directly and don't open a ticket. If there are additional information to
gather I use the ticket systems and redirect the user if possible.
For major issues I open a ticket if that's not done by the reporter.
> 2) What is your general feeling about getting additional info from
> the author (or anyone else participating in the discussion), do you
> usually get it in a reasonable amount of time (few hours/days)?
In most cases I get user-responses within a few days but I have some
tickets open for my extensions that have been issued in a
fire-and-forget manner. I tend to ignore them if the originators don't
answer. As I'm working on the Typo3-extensions in my spare-time only
it's more a matter of days than of hours anyway.
> 3) In case you have a fix, do you usually need feedback from the
> reporter. Maybe you have various kind of extensions and see
> different behaviours (little to no feedback on fix for end-user
> targeted extensions, more feedback for developer targeted
> extensions)?
I prefer to get feedback, of course. If I was able to reproduce the
issue exactly and if I'm sure the the new version solves the problem
feedback is not that important.
> 4) How do you feel about releasing new version to TER, is it
> something you do blindly, you want to avoid to do too often, you
> dislike much (why?), ...
If there are only minor issues I usually wait with a release until there
are "enough" issues.
On Typo3 4.5 releasing a version to TER is quite simple. Just click on
"Upload to TER" and select the version-scheme. On Typo3 6.2 it requires
more steps (either raw command-line tools or downloading and zipping and
uploading to t3o). Therefore I would prefer to have a release and upload
mechanism integrated in Typo3 again. This need not be integrated in the
core but may be served by an external extension. I haven't found a
working one so far[*].
[*] This is a perfect example for a project w/o a bug-tracker. After
mailing the extension author the problem including screen-shots I didn't
get any response...
Jan
More information about the TYPO3-dev
mailing list