[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: package ownership in Debian



On 7/29/06, Manoj Srivastava <srivasta@debian.org> wrote:
On Sat, 29 Jul 2006 16:27:26 +0000, Gustavo Franco <gustavorfranco@gmail.com> said:

> On 7/29/06, Manoj Srivastava <srivasta@debian.org> wrote:
>> On Fri, 28 Jul 2006 14:38:52 -0300, Gustavo Franco
>> <gustavorfranco@gmail.com> said:
>>
>> > * Promote NMU LowThreshold wiki list giving it some official
>> >   status.
>>
>> What does this mean?

> That you're out of date on what's going on and trying to make jokes
> of my opinions before reading for a second time.

        Actually, it just reinforces my view that you jump to wild
 conclusions with inadequate data.

> FYI, http://wiki.debian.org/LowThresholdNmu

        *Sigh*. I see I'll have to use non polysyllabic words here.

        I know about the LowThresholdNmu page. What exactly do you
 mean about giving it "official status"?

I wrote that it could be integrated with PTS, somebody else suggested
a new header in control. I think subscribe/unsubscribe a package
(using signed messages) to "LowThresholdNMU" with notes that could be
queried by mail and included in PTS web interface, would do.

>> > I think with something similar to what i wrote above we will end
>> > up with almost all the packages maintained by groups and some
>> > packages maintained by Debian as a whole and not individuals.
>> > The next step would be groups allowing other groups to upload
>> > some of "their" packages.
>>
>> I am mostly unconvinced that this would improve the quality of
>> distribution.

> Yes, so let us keep the lack of communication and "my packages,
> don't touch team" approach or do you have suggestions for the
> problems on the table? Don't you see any problem?

        We have a policy on NMU's. I think the release team has
 authorized 0-day NMU's, while following the rest of the NMU
 guidelines (nmudiff to the BTS, etc), in order to correct lacunnae in
 packages.

0day NMU's for RC bugs more than a week old - send the patch to the
BTS before upload apply. This is different than Joerg's idea.

        There is nothing wrong with offering to help out with packages
 either -- and nothing wrong with people forming teams. Rammning it
 down people's throats won't work, though.

Don't you see that the team thing is to avoid a random developer that
have no idea what's going on with the history of that package, do the
upload ? The packages that aren't under group maintenance and will
never be, needs more not so strict NMU rules.

> My experience with Debian Python Modules Team, pkg-ltsp and
> pkg-gnome, show me that groups, communication in these groups,
> cooperation from non DDs are better than "mail me and i'll reply in
> two weeks...".  Again, my point isn't that every package should be
> under group (as in alioth) maintenance, some packages would be under
> group maintenance as in Debian under some less restrict rules for
> NMU along the lines Joerg's wrote.

        You have examples pro teams.  There are also anecdotes where
 teams do not work.  Teams are akin to marriages: somethimes they work
 wonderfully, other times they result in the analogue to a nasty
 divorce. Even worse are teams that function like bad marriages: there
 is tension in the air, people distrust other members on the team,
 commits are reverted with no discussion, changes are made to SVN
 trees without any discussion, and the whole project suffers.

Please don't attack the team model, without pointing where it could be
better if it was a one-man approach. "The team foo is broken!" but it
would better with you or me maintaining the package(s) alone? Who
knows?

        So, if teams form naturally, and work well, that great.

        Mandating it from up on high is not.

I think the discussion is around how to put the teams to work well and
some kind of better relationship between the teams and less strict NMU
rules to non team maintaned packages.

regards,
-- stratus



Reply to: