On Tue, May 27, 2008 at 6:20 PM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2008 at 06:11:10PM +0800, John McCabe-Dansted wrote:
>> On Tue, May 27, 2008 at 2:18 PM, Markus Hitter <[EMAIL PROTECTED]> wrote:
>> > - Even if it's distribution specific it's still a commitment to the
>> > whole as long as it's open source. Other developers can look there to
>> > get an idea how some tasks were done. Always better than starting
>> > from scratch entirely.
>>
>> To my mind the biggest contribution downstream projects make is saving
>> developers time. My experience suggests that it if you are a developer
>> and you want to spend less time fighting your distro and more time
>> doing actual productive coding, then Ubuntu is one of the better
>> choices.
>
> Interesting... Could you explain this in more detail?
In a pure waterfall model downstream projects don't give *anything*
back to upstream projects... except a finished project.
There isn't a clear dividing line between users and developers. The
time I spend trying to get printing to work is time I don't spend
coding. Just because I know how to do a "simple"
configure ; wget ; wget ; configure ; make ; vim ; make ; make install
doesn't make it a productive use of a weekend. For this reason I like
using a "Just works" distro.
As others have mentioned previously the Ubuntu is also fairly friendly
to new developers.
>> It could perhaps make things even easier for developers, but thats
>> another kettle of fish.
>
> I'd be interested in hearing your further thoughts on this. (I've had
> my own thoughts on this, but would love to see other's ideas.)
Well the development aspects of Ubuntu aren't as polished as the
end-user facing applications. Unlike firefox and OO, pbuilder and
make-kpkg don't really "just work". Debhelper seems less
"user-developer friendly" than emerge. A developer has to learn a
programming language or two more or less by definition, but in
practice has to also learn autoconf, automake, make, am_edit,
pbuilder, make-kpkg, svn/cvs just to be able scratch their own itch.
In principle, developing could be as simple as doing "dev edit
<package-name>" finding whatever you wanted to change, perhaps
changing a constant like MAX_COL from 80 to 160 in your favourite
editor, doing a "dev test-sandbox", and perhaps a "dev install". Then
when the next apt-get update is run it could be smart enough to use
apt-get source and merge the changes into the new version, unless
conflicts arise.
Often I find that after finally fixing a problem, I've run out of
time and have to move onto something else. Perhaps then there could be
run a simple "dev share" command which would the developer to, at
their leisure, annotate each of their patches and upload them
somewhere others could re-use and comment on them. Presumably apport
should also make note of what patches are in use, and bug reports with
patches could have a "test this patch in a sandbox" option and ...
I am not necessarily suggesting that it is wise use of resources at
this time to focus on making development tasks more "user friendly",
just that it is conceptually possible and potentially useful.
--
John C. McCabe-Dansted
PhD Student
University of Western Australia
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
