FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-14-2008, 07:00 AM
Daniel Holbach
 
Default contributions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman schrieb:
> According to Henrik, the workflow bugs shouldn't exist anyway (bugsquad list) and any attempt
> to help bugsquad understand how to use them gets removed from the wiki unilaterally. I don't
> think we should invest time in this unless there is some agreement from
> bugsquad not to mess with it.

Henrik wants to discuss possible fixes (to whatever bug handling policy
necessary) some more, also during UDS. The more confusion we can remove
by getting bug statuses, etc in sync the better.

Also for completeness' sake: Henrik said "using the bug tracker in an
unorthodox way to track issues that are not really bugs".

Have a nice day,
Daniel

- --
My 5 today: #229670 (libgtk2-ex-podviewer-perl), #229574 (netdude),
#229377 (grass), #229895 (libdbi-perl), #229720 (kazehakase)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKo39RjrlnQWd1esRAu2/AJ0TXq6NAi/3uLcvuG35aU/LTssEqgCfUw//
yonfJbiCK3wlsKkcasyBBwQ=
=OAGv
-----END PGP SIGNATURE-----

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 07:03 AM
Daniel Holbach
 
Default contributions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Valcarcel schrieb:
> For MOTUs and core devels is not needed to
> file a bug since it's only needed to upload the package, but some times, a
> contributor, which need to file a bug, upload his debdiff and ask for
> sponsorship, make the work for nothing, becase one developer (no one in
> special) work on that merge and upload it. I think is not fair, and
> discourage for new contributor, so i think it lack for a common process
> where this things doesn't happen.

What do you think about summing up the ideas on a wiki page and
discussing it on ubuntu-devel@? I think it's important to discuss this
with all Ubuntu developers.

Have a nice day,
Daniel

- --
My 5 today: #229670 (libgtk2-ex-podviewer-perl), #229574 (netdude),
#229377 (grass), #229895 (libdbi-perl), #229720 (kazehakase)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKo7dRjrlnQWd1esRAsQ2AJ9e9gUk5MDYh31r5kQgul +hesXwtgCfS0EE
yeW3Mf1U6wHUl/HRtDE0cOQ=
=bD7T
-----END PGP SIGNATURE-----

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 07:05 AM
"Emmet Hikory"
 
Default contributions

Stephan Hermann wrote:
> 1. Dev/Contributor should work as first duty on the packages he/she
> touched the last time. Therefore, the dev/contributor don't have to
> check for merge/sponsor bugs in the first place.

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.

> 2. LP is hard to track to. Regarding, that we don't have special
> maintainers for packages, you can't track all the time the status or
> new bugs of all packages/bugs filed at LP. Yes, it sometimes sad for
> the contributor...but the easiest way is to go online and ping someone
> for checking.

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.

> I, for myself, don't check for the packages I touched last for bugs,
> because it takes too much time...and time for bugfixing and other
> things can be done, after I checked if the package I touched last is a
> sync or 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.

--
Emmet HIKORY

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 07:09 AM
Sarah Hobbs
 
Default contributions

Emmet Hikory wrote:

2. LP is hard to track to. Regarding, that we don't have special
maintainers for packages, you can't track all the time the status or
new bugs of all packages/bugs filed at LP. Yes, it sometimes sad for
the contributor...but the easiest way is to go online and ping someone
for checking.


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.


Fortunately, there is email too, and I'd imagine that Ubuntu developers
read mail more than once every 24 hours.


Hobbsee

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 07:26 AM
Stephan Hermann
 
Default contributions

Hi,

On Wed, 14 May 2008 16:05:25 +0900
"Emmet Hikory" <emmet.hikory@gmail.com> wrote:

> Stephan Hermann wrote:
> > 1. Dev/Contributor should work as first duty on the packages he/she
> > touched the last time. Therefore, the dev/contributor don't have to
> > check for merge/sponsor bugs in the first place.
>
> 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...

>
> > 2. LP is hard to track to. Regarding, that we don't have special
> > maintainers for packages, you can't track all the time the status
> > or new bugs of all packages/bugs filed at LP. Yes, it sometimes sad
> > for the contributor...but the easiest way is to go online and ping
> > someone for checking.
>
> 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.


>
> > I, for myself, don't check for the packages I touched last for
> > bugs, because it takes too much time...and time for bugfixing and
> > other things can be done, after I checked if the package I touched
> > last is a sync or 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.

As known, I'm always there for sponsoring requests via IRC, and for
others as well via jabber or email.

regards,


sh

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 09:02 AM
"Emmet Hikory"
 
Default contributions

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

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 10:13 AM
Morten Kjeldgaard
 
Default contributions

It seems the main concern of many of the posters in this thread is
that you may have a package you care about and would like to
maintain, and you do not want a random contributor grabbing it in
front of your nose.

I am a big believer in letting computers solve as many problems as
possible. That way we humans don't need to argue needlessly :-)

The concern above can be solved if people subscribe to bugmail for a
specific source package that they want to claim. If that involves
several people, they will have to work it out among themselves. This
can be detected by software (i.e. MoM or other automated procedures)
and a note could be given that a given package is claimed and should
not be touched unless otherwise agreed.

My guess is that the number of claimed packages is rather small, and
that in most cases, the last merger will be happy that someone else
carries out the next merge.

Cheers,
Morten

PS: At the moment, there is collective maintainership of all packages
in Universe. Does this discussion in reality stem from a wish that
Ubuntu maintainership of some packages should be possible? If so,
that question should be dealt with politically.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 01:13 PM
Scott Kitterman
 
Default contributions

On Wednesday 14 May 2008 03:00, Daniel Holbach wrote:
> Scott Kitterman schrieb:
> > According to Henrik, the workflow bugs shouldn't exist anyway (bugsquad
> > list) and any attempt to help bugsquad understand how to use them gets
> > removed from the wiki unilaterally. I don't think we should invest time
> > in this unless there is some agreement from bugsquad not to mess with it.
>
> Henrik wants to discuss possible fixes (to whatever bug handling policy
> necessary) some more, also during UDS. The more confusion we can remove
> by getting bug statuses, etc in sync the better.
>
> Also for completeness' sake: Henrik said "using the bug tracker in an
> unorthodox way to track issues that are not really bugs".
>
I think we've been doing it since roughly launchpad existed. I think we are
well past this being "unorthodox". So far his contribution to this effort
has been to unilaterally revert wiki entries that tried to clarify the
situation. From reading the bugsquad archive it seems he pretty clearly has
a position that we can just lump it and put up with whatever bugsquad does to
workflow bugs.

I don't really see that as a basis for discussion.

There are quite a number of core development processes that depend on such
bugs.

unorthodox [1]

Main Entry:
un·or·tho·dox Listen to the pronunciation of unorthodox
Pronunciation:
-ˈȯr-thə-ˌdäks
Function:
adjective
Date:
1657

: not orthodox

orthodox [2]

Main Entry:
1or·tho·dox Listen to the pronunciation of 1orthodox
Pronunciation:
ˈȯr-thə-ˌdäks
Function:
adjective
Etymology:
Middle English orthodoxe, from Middle French or Late Latin; Middle French
orthodoxe, from Late Latin orthodoxus, from Late Greek orthodoxos, from Greek
orth- + doxa opinion — more at doxology
Date:
15th century

1 a: conforming to established doctrine especially in religion b: conventional

So having looked at the dictionary, his opinion is that workflow bugs are not
conforming to established doctrine. He is actively resisting any attempts to
assist bugsquad in documenting their use. Given the actual meaning of the
word he used, I think that my characterization is entirely fair. Apparently
Launchpad exists to support bugsquad.

What is there to discuss?

Scott K

[1] http://www.merriam-webster.com/dictionary/unorthodox
[2] http://www.merriam-webster.com/dictionary/orthodox


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 01:15 PM
Scott Kitterman
 
Default contributions

On Wednesday 14 May 2008 03:05, Emmet Hikory wrote:

....

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

OTOH, volunteer effort is elastic. Try to hard to push people to your
definition of an effective workflow and you'll find yourself with fewer
people doing less work.

This needs to be solved through balance and sense rather than more rules and
bureacracy.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-14-2008, 01:17 PM
Scott Kitterman
 
Default contributions

On Wednesday 14 May 2008 05:02, Emmet Hikory 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.
>
Agreed, but the system that completely solves this problem (and I'm entirely
sympathetic to the contributor who's work was ignored, that should be
minimized - and an apology from the MOTU in question would be useful - if
that's me, let me know) would also be a lot less fun to work in. We need to
be careful that in optimizing for this case we don't optimize volunteers out
of contributing.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 04:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org