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, 12:26 AM
"Nicolas Valcarcel"
 
Default contributions

I think i haven't explain myself as i should. The thing was that: developer A uploaded a package on the past release circle, then a merge was publiched on MoM, a contributor take the merge, work on it and upload the debdiff to launchpad reporting the bug as it needs to be, the developer A commented on that bug report, so we can be sure that he knows about the contributor working on that merge, then developer B work on that merge and upload it by himself without noticing the bug report and contributor's work.

That, on the side of the contributor, being a new one, is a really bad thing because he wanted to be his work on the repos, but not only it isn't there, it has been done and uploaded by someone else.
DaD's comments were a good feature to avoid such things, if contributor left a comment in there, the developer B could see it and work on another merge.



On Tue, May 13, 2008 at 2:43 AM, Mathias Gug <mathiaz@ubuntu.com> wrote:

Hi Nicolas,




On Mon, May 12, 2008 at 07:51:47PM -0500, Nicolas Valcarcel wrote:
> Hi,
> * * Since hardy i have notice that some times contributions are not taking
> into account, mostly on merges. 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.

Are you referring to the fact that the package doesn't show up in the

contributor package list ? Usually the contributor is credited in the
Changelog entry.

--
Mathias Gug
Ubuntu Developer *http://www.ubuntu.com


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



--
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, 12:26 AM
"Nicolas Valcarcel"
 
Default contributions

I think i haven't explain myself as i should. The thing was that: developer A uploaded a package on the past release circle, then a merge was publiched on MoM, a contributor take the merge, work on it and upload the debdiff to launchpad reporting the bug as it needs to be, the developer A commented on that bug report, so we can be sure that he knows about the contributor working on that merge, then developer B work on that merge and upload it by himself without noticing the bug report and contributor's work.

That, on the side of the contributor, being a new one, is a really bad thing because he wanted to be his work on the repos, but not only it isn't there, it has been done and uploaded by someone else.
DaD's comments were a good feature to avoid such things, if contributor left a comment in there, the developer B could see it and work on another merge.



On Tue, May 13, 2008 at 2:43 AM, Mathias Gug <mathiaz@ubuntu.com> wrote:

Hi Nicolas,




On Mon, May 12, 2008 at 07:51:47PM -0500, Nicolas Valcarcel wrote:
> Hi,
> * * Since hardy i have notice that some times contributions are not taking
> into account, mostly on merges. 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.

Are you referring to the fact that the package doesn't show up in the

contributor package list ? Usually the contributor is credited in the
Changelog entry.

--
Mathias Gug
Ubuntu Developer *http://www.ubuntu.com


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



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 05-14-2008, 12:32 AM
Scott Kitterman
 
Default contributions

On Wed, 14 May 2008 08:11:43 +0900 "Emmet Hikory" <persia@ubuntu.com> wrote:
>Scott Kitterman wrote:
>> On Tuesday 13 May 2008 18:11, Jordan Mantha wrote:
>> > My feeling is that the best way to help make sure this kind of thing
>> > doesn't happen is to have *one*, canonical place to track merges.
Launchpad
>> > bugs seems to be the best way we have of doing that currently.
Basically,
>> > file a merge bug if you're going to be working on a merge and *all*
people
>> > working on merges, including MOTU sponsors, should be looking *first*
to
>> > see if somebody has already filed a bug before working on it.
>>
>> Personally I'd find a file a bug first rule very demotivating. One
more rule
>> to convince me to spend my time on other things.
>
> While I can understand the "file a bug first" rule to be
>demotivating, I'm inclined to agree with Jordan that waiting to hear
>from someone who is marginally active can also be demotivating. In
>essence, anything that blocks the immediate gratification of wanting
>something updated and updating it will be demotivating to someone
>(including MoM comments: some mergers don't use MoM). This is further

I'm not sure how one finds out a merge is needed otherwise (I'm assuming
MoM/DaD get merged reasonably quickly). I think a coment field on a page
you need is about the lowest impact we can get.

>complicated for those cases where people are involved in Debian and
>see merge requests as needing an update in Debian, which might be
>waiting for sponsorship at the time someone else wants to process a
>merge, but would later be a sync.

Excellent example of a case where checking is a good idea.

> That said, I'm a big fan of the "file a bug first" rule, as it
>provides the corresponding "check the outstanding bugs first" rule.

Not really. I find I file a lot bugs via email now. I think the two are
not nearly as related as they once were. Additionally, I'm strongly
opposed to adding process steps and work on the theory that if we make MOTU
do B then they'll have to do A they were supposed to do all along.

>It's this latter rule that I think is more important, as many packages
>don't get comprehensive bug triage, and would benefit from periodic
>review of the outstanding issues. Further, it may be that some of
>these issues are resolved by the merge, and that others can be
>resolved easily at the same time. By encouraging anyone processing a

Agreed.

>merge to review the outstanding bug list against the package at the
>time of merge, there is an increased likelihood that other useful
>fixes will be done to the package, and that the package will be in a
>known good state at the end of the merge, rather than just having had
>the previous changes copied blindly.

Agreed, but I don't think forcing me to write an email to Launchpad
furthers that goal.

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:50 AM
Morten Kjeldgaard
 
Default contributions

> Jordan Mantha wrote:
>
>> My feeling is that the best way to help make sure this kind of thing
>> doesn't happen is to have *one*, canonical place to track merges.
>> Launchpad
>> bugs seems to be the best way we have of doing that currently.
>> Basically,
>> file a merge bug if you're going to be working on a merge and
>> *all* people
>> working on merges, including MOTU sponsors, should be looking
>> *first* to
>> see if somebody has already filed a bug before working on it.

I agree with Jordan. Using LP to track the progress of merges is the
only realistic way to go if we are to avoid that people are
duplicating efforts, and that MOTUs short-circuit the endeavors of
contributors.

ScottK wrote:

> Personally I'd find a file a bug first rule very demotivating. One
> more rule
> to convince me to spend my time on other things.

It _should_ be possible to write a simple CLI tool that would submit
an email merge request to new@bugs.launchpad.net given a package name
and -version. The script could fill in the necessary fields, assign
the bug to the submitter, gpg-sign the message, etc. Although it may
be a bit of a bother to some of the more proficient and experienced
MOTUs, the reward is a greater satisfaction on the part of the
contributors, as well as a better documentation of the merging workflow.

Another possibility is to let MoM file the merging bugs as the merges
are processed. I can't overview the consequences of this, though.

Cheers,
Morten


--
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, 02:31 AM
"Emmet Hikory"
 
Default contributions

Scott Kitterman wrote:
> On Wed, 14 May 2008 08:11:43 +0900 "Emmet Hikory" wrote:
> > While I can understand the "file a bug first" rule to be
> >demotivating, I'm inclined to agree with Jordan that waiting to hear
> >from someone who is marginally active can also be demotivating. In
> >essence, anything that blocks the immediate gratification of wanting
> >something updated and updating it will be demotivating to someone
> >(including MoM comments: some mergers don't use MoM). This is further
>
> I'm not sure how one finds out a merge is needed otherwise (I'm assuming
> MoM/DaD get merged reasonably quickly). I think a coment field on a page
> you need is about the lowest impact we can get.

My personal common methods are tracking the output of
multidistrotools or reviewing the packages.qa.debian.org output for
selected packages (although I do occasionally also use MoM). I'm
usually more interested in clusters of things, or classes of efforts
than specific packages, which may be part of that.

> >complicated for those cases where people are involved in Debian and
> >see merge requests as needing an update in Debian, which might be
> >waiting for sponsorship at the time someone else wants to process a
> >merge, but would later be a sync.
>
> Excellent example of a case where checking is a good idea.

While I don't disagree with this, I don't see how this is an
argument for checking with the previous uploader vs. checking for a
filed bug vs. checking for a comment in some location. It's just a
matter of there being some official place where all merge efforts are
tracked, and common agreement that all people working on merges will
keep that resource updated. Given that a number of the people also
working on Debian belong to various collaborative maintenance teams, I
would not expect it to be a rare case where the last uploader would
not be the person working on the Debian package, even when a sync is
expected.

> > That said, I'm a big fan of the "file a bug first" rule, as it
> >provides the corresponding "check the outstanding bugs first" rule.
>
> Not really. I find I file a lot bugs via email now. I think the two are
> not nearly as related as they once were. Additionally, I'm strongly
> opposed to adding process steps and work on the theory that if we make MOTU
> do B then they'll have to do A they were supposed to do all along.

OK. Let me restate it then, as "Any potential merger should check
all outstanding bugs prior to processing a merge". If this step is
expected, it seems least invasive to file a bug if there is none,
rather than tracking some separate resource when one wants to process
a merge. Further, a LP-oriented workflow supports those developers
who are focused on bugfixes, rather than merges, as they will be
notified when someone else is processing a merge, and may want to
collaborate to generate the next revision. At least speaking for
myself, I'm much more likely to consider processing a merge when I am
otherwise working on a package (review the bug, check is there is a
Debian update, check for upstream code, prepare a patch, prepare a
revision (which may be a merge), upload). This may be different for
those focused on merges as a goal, but I'm not convinced that merges
for the sake of merging is inherently a good thing (although it may be
the best current practice to ensure that improvements in Debian are
available in Ubuntu).

Morten Kjeldgaard wrote:
> Another possibility is to let MoM file the merging bugs as the merges
> are processed. I can't overview the consequences of this, though.

Assuming the continuation of workflow bugs (see separate
discussion in ubuntu-bugs), this seems a sensible solution to me.
When MoM discovers a merge candidate, that is filed as a bug. When
someone wishes to work on it, the bug is assigned. If the merge isn't
useful, the bug can be given a won't fix status for a task in the
current development release.

Note that any implementation ought track the status of bugs filed,
and only report a new bug for a new Debian update in the case where
the previous bug has been closed as "Fix Released": any other update
ought just update / retitle the existing bug (and perhaps reset the
status). Any potential implementation of this ought be drafted as a
blueprint, and receive wide discussion within both the development and
quality assurance communities to ensure that it will not be
disruptive.

--
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, 03:24 AM
Scott Kitterman
 
Default contributions

On Tuesday 13 May 2008 22:31, Emmet Hikory wrote:
> Scott Kitterman wrote:
> > On Wed, 14 May 2008 08:11:43 +0900 "Emmet Hikory" wrote:
> > > While I can understand the "file a bug first" rule to be
> > >demotivating, I'm inclined to agree with Jordan that waiting to hear
> > >from someone who is marginally active can also be demotivating. In
> > >essence, anything that blocks the immediate gratification of wanting
> > >something updated and updating it will be demotivating to someone
> > >(including MoM comments: some mergers don't use MoM). This is further
> >
> > I'm not sure how one finds out a merge is needed otherwise (I'm assuming
> > MoM/DaD get merged reasonably quickly). I think a coment field on a
> > page you need is about the lowest impact we can get.
>
> My personal common methods are tracking the output of
> multidistrotools or reviewing the packages.qa.debian.org output for
> selected packages (although I do occasionally also use MoM). I'm
> usually more interested in clusters of things, or classes of efforts
> than specific packages, which may be part of that.

OK. Fair enough.

> > >complicated for those cases where people are involved in Debian and
> > >see merge requests as needing an update in Debian, which might be
> > >waiting for sponsorship at the time someone else wants to process a
> > >merge, but would later be a sync.
> >
> > Excellent example of a case where checking is a good idea.
>
> While I don't disagree with this, I don't see how this is an
> argument for checking with the previous uploader vs. checking for a
> filed bug vs. checking for a comment in some location. It's just a
> matter of there being some official place where all merge efforts are
> tracked, and common agreement that all people working on merges will
> keep that resource updated. Given that a number of the people also
> working on Debian belong to various collaborative maintenance teams, I
> would not expect it to be a rare case where the last uploader would
> not be the person working on the Debian package, even when a sync is
> expected.

People who are more familiar with (e.g. touched recently) the package are more
likely to know this stuff.

> > > That said, I'm a big fan of the "file a bug first" rule, as it
> > >provides the corresponding "check the outstanding bugs first" rule.
> >
> > Not really. I find I file a lot bugs via email now. I think the two
> > are not nearly as related as they once were. Additionally, I'm strongly
> > opposed to adding process steps and work on the theory that if we make
> > MOTU do B then they'll have to do A they were supposed to do all along.
>
> OK. Let me restate it then, as "Any potential merger should check
> all outstanding bugs prior to processing a merge". If this step is
> expected, it seems least invasive to file a bug if there is none,
> rather than tracking some separate resource when one wants to process
> a merge. Further, a LP-oriented workflow supports those developers
> who are focused on bugfixes, rather than merges, as they will be
> notified when someone else is processing a merge, and may want to
> collaborate to generate the next revision. At least speaking for
> myself, I'm much more likely to consider processing a merge when I am
> otherwise working on a package (review the bug, check is there is a
> Debian update, check for upstream code, prepare a patch, prepare a
> revision (which may be a merge), upload). This may be different for
> those focused on merges as a goal, but I'm not convinced that merges
> for the sake of merging is inherently a good thing (although it may be
> the best current practice to ensure that improvements in Debian are
> available in Ubuntu).

I think they are two separate, but related goals:

1. Keep Ubuntu in sync with Debian (as much as is feasible) and gain benifits
of Debian updates/fixes and overall synergy from being a downstream distro.

2. Fix specific problems in Ubuntu.

Often #1 will accomplish #2 and also often one can mix the two together.

> Morten Kjeldgaard wrote:
> > Another possibility is to let MoM file the merging bugs as the merges
> > are processed. I can't overview the consequences of this, though.
>
> Assuming the continuation of workflow bugs (see separate
> discussion in ubuntu-bugs), this seems a sensible solution to me.
> When MoM discovers a merge candidate, that is filed as a bug. When
> someone wishes to work on it, the bug is assigned. If the merge isn't
> useful, the bug can be given a won't fix status for a task in the
> current development release.

Given there are no alternatives to workflow bugs offerred, I don't think that
one person's opinion is going to make them go away. The ubuntu-bugs position
seems to me to be that it's to inconvenient for them to actually worry about
disrupting development efforts and so we can just lump it. We had an
agreement about some changes to make things clearer and they were unlaterally
dumped.

> Note that any implementation ought track the status of bugs filed,
> and only report a new bug for a new Debian update in the case where
> the previous bug has been closed as "Fix Released": any other update
> ought just update / retitle the existing bug (and perhaps reset the
> status). Any potential implementation of this ought be drafted as a
> blueprint, and receive wide discussion within both the development and
> quality assurance communities to ensure that it will not be
> disruptive.

I'll be glad to be as worried about disruptiont to the QA community as they
appear to be worried about disruption to my work.

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, 04:25 AM
"Emmet Hikory"
 
Default contributions

Scott Kitterman wrote:
> On Tuesday 13 May 2008 22:31, Emmet Hikory wrote:
> > While I don't disagree with this, I don't see how this is an
> > argument for checking with the previous uploader vs. checking for a
> > filed bug vs. checking for a comment in some location. It's just a
> > matter of there being some official place where all merge efforts are
> > tracked, and common agreement that all people working on merges will
> > keep that resource updated. Given that a number of the people also
> > working on Debian belong to various collaborative maintenance teams, I
> > would not expect it to be a rare case where the last uploader would
> > not be the person working on the Debian package, even when a sync is
> > expected.
>
> People who are more familiar with (e.g. touched recently) the package are more
> likely to know this stuff.

Certainly, although these individuals may not be available at any
given time, hence the continued discussion regarding notification vs.
personal contact. Neither is ideal, and any solution is at best a
compromise. For the case where one must claim merges, it adds burden
to those who care about a package who must claim a merge or have
someone else do it. For the case where one must request permission
for a merge, it adds burden to those with time and inclination to
process merges, as the appropriate counterparty may not be available
(and may never become available, depending on their level of
involvement). Unfortunately, any solution that is not strictly one or
the other of these is prone to confusion (especially so when someone
uploads a candidate without having either checked for an outstanding
merge notice nor with the last uploader, as apparently started this
discussion). The primary reason for my preference for a notification
solution is that it rewards people who act, rather than rewarding
those who may have acted in the past, and may contribute to a faster
pace of updates and development. On the other hand, even in the
presence of a notification system, I'd expect collaboration: with a
"file bug in LP" model, if someone starts on a merge of a package
which I know to be complex, and about which I am likely to have
significant information, I will receive bugmail about the merge
(because I am subscribed to bugmail for the package), and may share
information about the merge to either assist or dissuade them from
continuing (depending on the specifics of the package).

> > OK. Let me restate it then, as "Any potential merger should check
> > all outstanding bugs prior to processing a merge". If this step is
> > expected, it seems least invasive to file a bug if there is none,
> > rather than tracking some separate resource when one wants to process
> > a merge. Further, a LP-oriented workflow supports those developers
> > who are focused on bugfixes, rather than merges, as they will be
> > notified when someone else is processing a merge, and may want to
> > collaborate to generate the next revision. At least speaking for
> > myself, I'm much more likely to consider processing a merge when I am
> > otherwise working on a package (review the bug, check is there is a
> > Debian update, check for upstream code, prepare a patch, prepare a
> > revision (which may be a merge), upload). This may be different for
> > those focused on merges as a goal, but I'm not convinced that merges
> > for the sake of merging is inherently a good thing (although it may be
> > the best current practice to ensure that improvements in Debian are
> > available in Ubuntu).
>
> I think they are two separate, but related goals:
>
> 1. Keep Ubuntu in sync with Debian (as much as is feasible) and gain benifits
> of Debian updates/fixes and overall synergy from being a downstream distro.
>
> 2. Fix specific problems in Ubuntu.
>
> Often #1 will accomplish #2 and also often one can mix the two together.

Perhaps. I see different goals, being:

1. Fix as many issues as can be discovered in Ubuntu (or inferred to
be present in Ubuntu due to existence upstream).

2. Ensure that any Ubuntu-specific bugfixes are passed upstream as far
as they remain applicable in order to free upstream developers to
focus on yet unsolved issues.

Within this context, a merge is simply a convenient way to package
a selection of fixes from upstream as part of goal #1, and often a
convenient point to review the outstanding patches to verify that
those not Ubuntu-specific have indeed been forwarded upstream for
review and inclusion.

Note that there is an implicit assumption above that "upstream"
includes Debian, and as such it is often best to have similarity of
packaging towards reducing the number of outstanding bugs and ease
adoption of upstream fixes.

--
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, 06:11 AM
Stephan Hermann
 
Default contributions

Moins,

On Mon, 12 May 2008 19:51:47 -0500
"Nicolas Valcarcel" <nvalcarcel@ubuntu.com> wrote:

> Hi,
> Since hardy i have notice that some times contributions are not
> taking into account, mostly on merges. 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.

I read now the whole thread about this issue...
I think there are two problems here:


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

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

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, 06:23 AM
Daniel Holbach
 
Default contributions

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

Morten Kjeldgaard schrieb:
> It _should_ be possible to write a simple CLI tool that would submit
> an email merge request to new@bugs.launchpad.net given a package name
> and -version. The script could fill in the necessary fields, assign
> the bug to the submitter, gpg-sign the message, etc.

Also should it be possible to make use of python-launchpad-bugs (for
those who don't have a local mail server set up) - small snippet from
/usr/bin/requestsync:

Bug = launchpadbugs.connector.ConnectBug()
Bug.authentication = cookiefile
bug = Bug.New(product = product, summary = bugtitle, description =
bugtext)
bug.importance = 'Wishlist'
bug.status = status
bug.subscriptions.add(subscribe)
bug.commit()

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

iD8DBQFIKoVxRjrlnQWd1esRAutpAJ4qDz8rz3OFeVFp/Ks0XdMHe/pApwCfdmWD
IwqnCXFFKrBGmNzorZBWuds=
=zE92
-----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, 06:31 AM
Scott Kitterman
 
Default contributions

On Wed, 14 May 2008 08:23:46 +0200 Daniel Holbach
<daniel.holbach@ubuntu.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Morten Kjeldgaard schrieb:
>> It _should_ be possible to write a simple CLI tool that would submit
>> an email merge request to new@bugs.launchpad.net given a package name
>> and -version. The script could fill in the necessary fields, assign
>> the bug to the submitter, gpg-sign the message, etc.
>
>Also should it be possible to make use of python-launchpad-bugs (for
>those who don't have a local mail server set up) - small snippet from
>/usr/bin/requestsync:
>
> Bug = launchpadbugs.connector.ConnectBug()
> Bug.authentication = cookiefile
> bug = Bug.New(product = product, summary = bugtitle, description =
>bugtext)
> bug.importance = 'Wishlist'
> bug.status = status
> bug.subscriptions.add(subscribe)
> bug.commit()
>
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.

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 11:56 PM.

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