Hi
I am looking into upgrading the scala package to the newest scala 2.12.8
and creating a new package for the scala build tool, Sbt, 1.2.
I have been discussing this with the Debian-java team, but since scala
must be built with the previous version of scala and sbt, and the same
for sbt,
Moins,
On Sun, 18 May 2008 20:22:25 +0200
Reinhard Tartler [EMAIL PROTECTED] wrote:
Stephan Hermann [EMAIL PROTECTED] writes:
Why not moving away from this LP thingy for merges?
We could use something like the RT for those tasks?
Do you think about rt.canonical.com?
Definitly not...
Scott Kitterman [EMAIL PROTECTED] writes:
This would help with preventing duplicate work, but I do see how that
would address my concern about having to wait to get a bug number?
What would you need the bug number for? The only reason I see is to add
a propoer comment in debian/changelog.
Per definition, the assignee of a malone bugtask is the one working on
the merge. It would be very useful if DaD was taught about these merge
bugs and reproduce that piece of information.
Currently if you enter Bug #nn as a comment in DaD it knows that's a
bug number and adds a link to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott Kitterman schrieb:
Does Launchpad/python-launchpad expose an interface for this? With email
reported bugs you have to wait for LP to get around to mailing you the bug
number.
import launchpadbugs.connector
Bug =
Scott Kitterman [EMAIL PROTECTED] writes:
a) Too cumbersomely
b) The round-trip time is too high that make duplicate work more likely
c) the use of lp restricts possible contributors
d) The complete list of outstanding merges must be easily visible.
For a), I image that we can craft scripts
Moins,
On Sun, 18 May 2008 09:56:16 +0200
Reinhard Tartler [EMAIL PROTECTED] wrote:
Scott Kitterman [EMAIL PROTECTED] writes:
a) Too cumbersomely
b) The round-trip time is too high that make duplicate work more
likely c) the use of lp restricts possible contributors
d) The complete
Scott Kitterman [EMAIL PROTECTED] writes:
a) Too cumbersomely
b) The round-trip time is too high that make duplicate work more likely
c) the use of lp restricts possible contributors
d) The complete list of outstanding merges must be easily visible.
For a), I image that we can craft scripts
Stephan Hermann [EMAIL PROTECTED] writes:
Why not moving away from this LP thingy for merges?
We could use something like the RT for those tasks?
Do you think about rt.canonical.com? Or shall we setup another RT
instance? What features do RT offer over malone? AFAIUI you would need a
RT
ScottK wrote:
This would help with preventing duplicate work, but I do see how that
would address my concern about having to wait to get a bug number?
AFAICS there is no reason why the claim-merge.py script should not be
able to return the bug number right away.
-- Morten
--
Ubuntu-motu
ScottK wrote:
This would help with preventing duplicate work, but I do see how that
would address my concern about having to wait to get a bug number?
AFAICS there is no reason why the claim-merge.py script should not be
able to return the bug number right away.
Does
Scott Kitterman [EMAIL PROTECTED] writes:
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.
Could you please elaborate here? What specifically is the annoying part
of filing a bug? Possible reasons I can image:
a)
On Sat, 17 May 2008 17:46:47 +0200 Reinhard Tartler [EMAIL PROTECTED]
wrote:
Scott Kitterman [EMAIL PROTECTED] writes:
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.
Could you please elaborate here? What
Moins,
On Mon, 12 May 2008 19:51:47 -0500
Nicolas Valcarcel [EMAIL PROTECTED] 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
-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 [EMAIL PROTECTED] given a package name
and -version. The script could fill in the necessary fields, assign
the bug to
On Wed, 14 May 2008 08:23:46 +0200 Daniel Holbach
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] given a package name
and
-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
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
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
Hi,
On Wed, 14 May 2008 16:05:25 +0900
Emmet Hikory [EMAIL PROTECTED] 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.
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
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
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
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
On Wednesday 14 May 2008 06:13, Morten Kjeldgaard wrote:
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
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
On Monday 12 May 2008 20:51, 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
On Tuesday 13 May 2008 17:22, Nicolas Valcarcel wrote:
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
On Tue, May 13, 2008 at 2:48 PM, Scott Kitterman [EMAIL PROTECTED]
wrote:
On Tuesday 13 May 2008 17:22, Nicolas Valcarcel wrote:
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,
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
On Tue, May 13, 2008 at 3:26 PM, Scott Kitterman [EMAIL PROTECTED]
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
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.
AM, Mathias Gug [EMAIL PROTECTED] 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
On Wed, 14 May 2008 08:11:43 +0900 Emmet Hikory [EMAIL PROTECTED] 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.
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
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,
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
AM, Scott Kitterman [EMAIL PROTECTED]
wrote:
On Monday 12 May 2008 20:51, 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
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
Do you think that http://wiki.ubuntu.com/SponsorshipProcess is that
complicated? (File a bug, link to the package / attach the patch,
subscribe the right team)
The process isn't at all complicated, but it is difficult. Any process
is useless unless there is the manpower in the target review
Am Mittwoch, den 17.10.2007, 13:06 -0400 schrieb Scott Kitterman:
I think the most important thing is that the person be trusted not to upload
broken stuff very often and to fix it when they do. I wouldn't mind having
MOTUs with only casual interest as long as when they did upload something
On 10/18/07, Daniel Holbach [EMAIL PROTECTED] wrote:
Am Mittwoch, den 17.10.2007, 13:06 -0400 schrieb Scott Kitterman:
I think the most important thing is that the person be trusted not to upload
broken stuff very often and to fix it when they do. I wouldn't mind having
MOTUs with only
Can I suggest a way forward.
I'm not at all interested in being a MOTU. I'm working on a specific
piece of open source software, and from that the occassional Ubuntu
package drops out which I think would be of use to the general community.
Having gone through the Gutsy development process I feel
Am Donnerstag, den 18.10.2007, 11:20 +0100 schrieb Neil Wilson:
Having gone through the Gutsy development process I feel that package
submission is difficult if you are not one of the inner circle or are
wanting to join it. And from the other side of the fence there are too
many packages and
Emmet Hikory wrote:
In recent discussion in -devel-discuss, there was the folllowing
excerpted exchange:
Am Mittwoch, den 17.10.2007, 09:24 -0400 schrieb Peter (Ubuntu List):
I did check to see if I could help out creating packages for as some
call it, the inside Ubuntu community. All I
On Wednesday 17 October 2007 13:45, Peter (Ubuntu List) wrote:
Do you have to be a MOTU to contribute to the backports?
No. We take backports from the developmental Ubuntu release. What backports
most needs is people to test packages. To be a member of the group that
approved backports,
On 10/18/07, Peter (Ubuntu List) wrote:
I believe that your mechanism to have somebody becoming a MOTU is teh
right way. You have to protect the product from deteriorating and make
sure your product remains on the high level it is right now.
I'd agree that it's important to be sure that
47 matches
Mail list logo
