On Tue, Apr 6, 2010 at 18:46, Manoj Srivastava sriva...@debian.org wrote:
Personally, I'd draw the line more at considering Manoj as someone who
tends to his packages, and thus is someone worth talking to about
them, but who doesn't have any authority over them beyond how well he
can persuade
Hi,
On Fri, Apr 2, 2010 at 18:54, Wouter Verhelst wou...@debian.org wrote:
On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote:
BTW, does Manoj own those package?
Yes.
Another word for something that's owned by someone is proprietary,
so another way of saying the above in English
On Tue, Apr 06 2010, Anthony Towns wrote:
Hi,
On Fri, Apr 2, 2010 at 18:54, Wouter Verhelst wou...@debian.org wrote:
On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote:
BTW, does Manoj own those package?
Yes.
Another word for something that's owned by someone is proprietary,
On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote:
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!)
They can use standard interfaces to modify the package, should they want
to. Manoj does the same.
BTW, does Manoj
On Wed, 2010-03-31 at 18:13 -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
My father, for instance, often drives a screw into a piece of
wood with a chisel when he doesn't have a screwdriver around.
And I've also seen him chop off bits of wood with a
screwdriver,
Hi,
I think this discussion is beginning to veer off topic, since it
is far from figuring out who to vote for, etc. This is my last post on
ths topic here, if you want to covince me of the error of my ways,
please take it to private email. If you want to change how we do things
to
On Thu, Apr 01, 2010 at 05:15:38AM -0700, Manoj Srivastava wrote:
What about peer review of the packages?
My *peers* have no problems dealing with the build system, IMO.
As long as you tautologically define your *peers* as the set of people
willing to tolerate the gratuitous overhead
Le mardi 30 mars 2010 à 15:42 -0700, Manoj Srivastava a écrit :
I might agree that maintenance of my packages might raise a
competence bar for the would-be-maintainer, and some people might fail
to meet that bar.
Let’s say we find this in a package:
define create_md5sum
On Wed, Mar 31 2010, Josselin Mouette wrote:
Le mardi 30 mars 2010 à 15:42 -0700, Manoj Srivastava a écrit :
I might agree that maintenance of my packages might raise a
competence bar for the would-be-maintainer, and some people might fail
to meet that bar.
Let’s say we find this
Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit :
I just update code in one place, test it, and then run a script
that does a git pull for all my packages. The next time I build the
package, it will pull in the change.
Which is what I already explained in other
On Wed, Mar 31 2010, Josselin Mouette wrote:
However a newcomer not aware of your fanatic rejection of any kind of
standard tools would absolutely not understand what this is about. And
the same goes about everything else in the package.
Manoj Srivastava wrote:
I just update code in
On Wed, Mar 31 2010, Josselin Mouette wrote:
Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit :
I just update code in one place, test it, and then run a script
that does a git pull for all my packages. The next time I build the
package, it will pull in the change.
Le mercredi 31 mars 2010 à 05:53 -0700, Manoj Srivastava a écrit :
I wouldn’t expect you to be able to question your own choices anyway.
I personally think that would apply to present company as well.
Wow.
--
.''`. Josselin Mouette
: :' :
`. `' “A handshake with whitnesses
Manoj Srivastava wrote:
Now when we upgrade our policies and/or infrastructures, like what was
recently proposed for sha1sums instead, this requires manual updating of
all our packages for no good reason.
That would be the naive way to implement things. And yes, that
would be
On Wed, Mar 31 2010, Joey Hess wrote:
Manoj Srivastava wrote:
Abillity to understand fairly simple shell script is not a
matter of tenure. It is a matter of competence. I am dismayed that a
fairly bland invocation of find seems opaque, in your opinion, to
people coming into the
On Wed, Mar 31, 2010 at 09:48:56PM +0200, Frank Lin PIAT wrote:
Doesn't the Unix philosophy implies that I should reuse tools and code,
rather than re-writing my's own?
No.
The Unix philosophy is do one thing, and do it well. It implies that
there's a useful toolbox from which you can use
Wouter Verhelst wou...@debian.org writes:
The same is true with Manoj. You may think debhelper is the best thing
since sliced bread (it might be), but Manoj just disagrees. And as long
as Policy does not specify that debhelper is to be used, it's perfectly
within his right to not use it. As
On Thu, 25 Mar 2010, Manoj Srivastava wrote:
This is great!! perhaps we can get rid of the abomination that
is vi and get everyone to use the one true editor all at once.
I suggest you change your tone. You have the right to not share my point
of view, but there's no need to be
On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote:
On Thu, 25 Mar 2010, Manoj Srivastava wrote:
What did you say? What difference does it make what tool is used
when the result is equal?
It doesn't make a difference for a the end-user, but it makes a difference
to
On Tue, Mar 30 2010, Marc Haber wrote:
On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote:
On Thu, 25 Mar 2010, Manoj Srivastava wrote:
What did you say? What difference does it make what tool is used
when the result is equal?
It doesn't make a difference for a the
Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit :
I am not sure that follows. How has my not using debhelper made
it harder for newcomers?
Your packages are absolutely impossible to maintain by anyone but
yourself.
And that in itself should be considered a bug.
--
.''`.
Josselin Mouette j...@debian.org writes:
Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit :
I am not sure that follows. How has my not using debhelper made
it harder for newcomers?
Your packages are absolutely impossible to maintain by anyone but
yourself.
I am an existence
On Tue, Mar 30 2010, Russ Allbery wrote:
Josselin Mouette j...@debian.org writes:
Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit :
I am not sure that follows. How has my not using debhelper made
it harder for newcomers?
Your packages are absolutely impossible to maintain
On Thu, Mar 25 2010, Raphael Hertzog wrote:
Hello,
those questions are for all candidates. By standardization I mean that
something should be used as default tool unless reasons exist to use
something else
This is great!! perhaps we can get rid of the abomination that
is vi and
On Thu, 25 Mar 2010, Joey Hess wrote:
The exciting potential of dpkg source v3 to me is that it potentially
opens an area that had stifled most innopvation, by allowing subtypes of
the source format to be developed. But this area is still relatively
closed to innovation; dpkg's maintainers
Hello,
those questions are for all candidates. By standardization I mean that
something should be used as default tool unless reasons exist to use
something else (I do not mean that we sould impose something to
everybody for all cases, but it should still be what's used in 95% of the
cases).
1/
Le Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog a écrit :
those questions are for all candidates. By standardization I mean that
something should be used as default tool unless reasons exist to use
something else (I do not mean that we sould impose something to
everybody for all
Raphael Hertzog, 2010-03-25 11:22:36 +0100 :
[...]
1/ Do you believe that it's a good move to standardize our packaging tools?
(example: debhelper is almost standard, quilt is gaining status of the
standard patch system thanks to the new source format)
Please define “standardize” here.
On Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog wrote:
Hello,
those questions are for all candidates. By standardization I mean that
something should be used as default tool unless reasons exist to use
something else (I do not mean that we sould impose something to
everybody for
On Thu, Mar 25, 2010 at 7:22 AM, Raphael Hertzog hert...@debian.org wrote:
1/ Do you believe that it's a good move to standardize our packaging tools?
(example: debhelper is almost standard, quilt is gaining status of the
standard patch system thanks to the new source format)
I do not
On Thu, 25 Mar 2010, Wouter Verhelst wrote:
How can we change our processes so that doing/organizing such changes
is less of a burden?
They are not.
I can't accept the premise that we can't do better at this level.
I managed to get my own project through the end (it's deployed,
On Thu, 25 Mar 2010, Margarita Manterola wrote:
4/ Organizing changes that have an impact on (a large part of|all) the
archive is very difficult:
[...]
How can we change our processes so that doing/organizing such changes
is less of a burden?
The only way is to make it easy
On Thu, Mar 25, 2010 at 2:17 PM, Raphael Hertzog hert...@debian.org wrote:
You got me wrong. I don't want to change our processes to force people to
adopt new tools. I want to change our processes so that it's easier to
complete far-reaching projects: in my case, it includes everything from
On Thu, Mar 25, 2010 at 06:07:19PM +0100, Raphael Hertzog wrote:
On Thu, 25 Mar 2010, Wouter Verhelst wrote:
How can we change our processes so that doing/organizing such changes
is less of a burden?
They are not.
I can't accept the premise that we can't do better at this
* Raphael Hertzog (hert...@debian.org) [100325 18:18]:
On Thu, 25 Mar 2010, Margarita Manterola wrote:
4/ Organizing changes that have an impact on (a large part of|all) the
archive is very difficult:
[...]
How can we change our processes so that doing/organizing such changes
Wouter Verhelst wrote:
A very good example of that is debhelper; nobody ever told anyone to use
it, yet most of our packages do, directly or otherwise.
Parts of Debian encourage experimentation, innovation, and evolution of
better solutions: parts don't. That debian/rules is a flexible,
36 matches
Mail list logo
