Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 2:17 PM, Raphael Hertzog <email@example.com> 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
> working on dpkg-source to ensuring that the new formats can be used in
> sid. In other cases, it can be modify our infrastructure to collect debug
> information and make it available as .ddebs, or maybe modify our
> infrastructure so that we can provide updated translations in point
> releases, etc.
Well, I really don't see a way.
Take for example when the Homepage field was added as another field in
the control file instead of being in the description. This is a very
easy switch, and I guess most packages that have had an upload since
then have updated that. This became a standard almost as soon as it
was done, because it was easy to adopt and technically better.
The change in dpkg is like the other extreme. It's something that
implies a lot of things to take into account, a lot of changes, and
the documentation is not clear enough (I've looked at the wiki and at
the links in the wiki, but there's no simple centralized howto for
people to follow).
The processes are already established: when something useful is
adopted by enough people, it enters policy, first as a should, then as
a must. Meanwhile, lintian first informs and then warns about such
situation. The problem with the dpkg example is that a lot of people
are still not willing to do the migration, and I don't think this can
be changed through "processes".
>> Now, I do find very interesting this question very interesting. One
>> thing is to be more open to new ideas. Another thing is to encourage
>> people to try new things. It's mostly a cultural thing, we used to
>> have a culture of innovation and now we don't. We need to bring it
>> back, but I don't see an easy way for this. I'll ponder some more
>> about this.
> Do you believe that our NM process could be responsible of this by
> unvoluntarily favoring packagers over developers?
Uhm, that's a very hard question. I do believe that the NM process
favors patient people over brilliant people. But I'm not sure what you
are referring to with "developers". In any case, I wouldn't say that
the NM process is the reason why we don't have a culture of
I think there may have been too many flamewars about people
introducing changes, so much that it could be that some developers
don't like to introduce too innovative changes because they fear
they'd be flamed for them.
It could also be that other fronts have been better at attracting
people with novel ideas than we have been.
I find it very hard to find the reason for the situation and to
propose changes. However, I think that in order to make Debian great
we should fix this.