contributions

[Stephan Hermann]

Moins,

On Wed, 14 May 2008 18:02:43 +0900
"Emmet Hikory" <persia at ubuntu.com> wrote:

> 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.


in time means mostly: less then 12 hours, but that's me. Actually, you
can see who is active and who not.
Reading MoM lists every day, you can see who was the last uploader, and
who is doing some work on those packages (reading -changes that is). 
If there is no interest from the last uploader, ping active devs to get
things reviewed and uploaded.

The first rule, we should be commited to, get your packages, which you
touched last, done...then deal with others...
Regarding contributors, this should be known...most people are busy
doing the merges now, and dealing with the rest at later times...or as
I'm doing it, when I'm on IRC, and someone pings me to review merges or
whatever...I'll do that in time...regarding my real life workflow et
all. I think it should be normal to say: ok, I'll assign the bugs to
me, and deal with it later...please stay tuned.

> >  >     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.

IMHO would it be useful, if an active dev is just sending a mail to our
lists, and just state: "I'm busy because of work" or "I'm on holiday"
so other people know, when he/she's busy for more then the normal day ;)

For inactive devs...well, this is a problem for every OSS project.

> 
>     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.

Yes, just fix MoM and push a website like DaD in front of it...
I'm, <--- me,  not using DaD, because I don't want to look at two
places for the very same thing. I use MoM, as official central starting
point. And we should get this fixed first. Or just create a ML with a
simple shell script which sends mail about "Hey, I'm working on this,
don't touch".

> 
> >  >     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.  

We have a lot of bugs still sleeping with patches or upstream patches
from older times (I remember the xemacs maximize bugfix patch from
pre-dapper?!) ... most of the bugs, which were revealed by Daniels
script, are old (fixed in newer versions upstream/debian) , outdated
(old code, patch not working), or people not answering questions from a
dev. So, having devs concentrating on the actual dev release, what
should those people do? IMHO it's easier to push stuff first, and fix
later, because the time for bugfixing is longer then the merge time.

Regarding workflow, I think, we need to focus on different areas of
work...merging/syncing, bugfixing, new stuff, old stuff (SRU), security.
Some of those areas work great (security e.g.), others are only working
because some of us are caring about special packages. No one, can, want
and will do everything...and this is a good thing.

> 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.  

As long there is no real way to automate checking for bugreports in a
package, it will take a lot of time.
"no real way" means, a simple way of querying LP for special reports,
without scripting python or whatever.
The idea, behind that, is old...I would like to have a simple shell
tool, ncurses based, or UI based Xtool, to say: "Give me all bugs of
package X, filtered by "New" or "Triaged", so I don't have to fiddle
all the way with my firefox...and a horrible search page.

I'm working most of the time with the CLI...and using the browser
during this process is bugging me.

> 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.

As said, everyone of us has his/her own workflow...this is good.
Changing those workflows is a loss of energy...and this should be
avoided. When I merge first, bug fix later...it's ok for me, not for
others (e.g.).
Regards,

\sh