contributions

[Emmet Hikory]

Stephan Hermann wrote:
>  "Emmet Hikory" wrote:
>  >     While this is often the case, there are sometimes dependencies
>  > between packages that mean that other packages must be merged first.
>  > Also, depending on the focus of the individual developer, it may be
>  > that upgrading a specific package is of significant importance towards
>  > meeting some goal, and so efforts on that package may be prioritised.
>
>  Yes...for this there is, as mentioned, IRC or eMail to ask the last
>  uploader to take care about it, or if there is no message in time, I
>  would do the merge myself, or a contributor is doing it, and ping on
>  the channel for sponsoring...

    Sure, but it's the definition of "in time" that causes the very
event that sparked this thread.  There is nothing more demotivating
than performing work and having it discarded without comment, or
ignored completely.

>  >     This is extremely timezone dependent: it is not infrequent for
>  > developers to be involved primarily in their personal evening (~4
>  > hours).  This often means that during a given week, finding the
>  > appropriate person may require that the seeker be relatively close,
>  > and that developers in e.g. Western United States, Australia, and
>  > Central Europe may find little active time in common.
>
>  As people are aware of irc proxies and running them 24 hours on a
>  server, I think it's ok, to just ping on irc..and via backlog there is
>  the possibility to get the ping just in time..
>  Even more, freenode has notes which you can send to the user directly.

    While these are useful technological tools to communicate with
people (and yes, email works just fine), it doesn't solve the case
where someone is asleep, or occupied by employment, or on holiday for
a few days, or similar.  Further, the person being sought may have
previously privately communicated to some third person that they could
perform the merge, again causing undocumented contention.

    I'm very much not arguing against communicating with the previous
developer, or finding ways to merge quickly, only in favor of there
being a single agreed place for those working on merges to notify
others of their work in progress to prevent duplicate work, and for
this resource to be public for review by any third party who may
consider the merge.

>  >     While I can understand that this workflow works faster for you,
>  > I'm not certain it actually saves total time, as it seems to me that
>  > combining all available fixes from several bugs for a single
>  > upload/build cycle is likely less effort overall than repeatedly
>  > updating the same package to address various reported issues.
>  >
>
>  The problem here is, that many bugs are fixed with new upstream
>  versions. Right now, there is no way to tell, (only via guessing) for
>  which release the bugreport is for. As the time of doing merges/syncs
>  is counted, we need to get things done...which means, more syncs, less
>  work more time for real bugfixing.

    This is an artifact of a previous lack of review of bugs for
various versions.  Ideally, it would be appropriate to verify the bugs
as present in the current version in the archives, and not present in
the new candidate version (for bugs fixed upstream).  Ignoring this
process further swells the number of completely ignored bugs, and
makes the process of actually identifying useful bugs much more
difficult for all.  Yes, checking bugs takes a little time, but having
the bugtracker roughly accurate makes it much easier to identify
targets for real bugfixing.  If a bug is considered serious enough by
somebody to qualify for a fix by some means other than an update of
the current development repositories, this ought be done by other
documented processes (security updates, SRUs, etc.), and ought not
affect the primary task for a given bug.

-- 
Emmet HIKORY