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

Bug#366938: svn commit access to the d-i repo ...



On Sat, May 13, 2006 at 07:28:28PM +0200, Frans Pop wrote:
> As to Sven's request to remove some of his contributions from the d-i 
> repository, IMO there is absolutely no basis for that:
> - any contributions to open source (sub)projects become part of that
>   project
> - the relevant components are maintained by the d-i team with Sven as
>   main developer and Uploader, but the Maintainer is debian-boot@l.d.o,
>   although even that is IMO irrelevant
> - Sven still has read access to the repository, so if he wants he can
>   check out and fork the components which means that his rights as a
>   copyright holder are in no way violated
> - as the components are an integral part of the installer, forking them
>   only makes sense if the whole installer is forked
> - the d-i team has at least some say over _any_ udebs uploaded into the
>   Debian archives as randomly uploaded udebs can interfere with the
>   working of the installer
> - this implies that Sven should not be allowed to hijack the components

Frans, you understand that you just argued for me to get svn commit access
back in order to work on those component, right ? 

The current DPL proposal is that i work on those, without the backing of the
svn repo, do an anonymous checkout, and upload the result (supposedly as NMU,
but since i am uploader, i don't see why it should be an NMU).

You said that i couldn't do that without forking d-i, and i agree that this
solution is pretty suboptimal, and not in the best interest of both debian and
the debian installer.

So, let's end this dispute now, restore my svn commit access, and i will
repeat what i said earlier on. I will work on those parts which will not be
addressed by Colin Watson, namely, pegasos support (the new pegasos OF i am
preparing will need some nobootloader changes), working on apus and prep
support, fixing IBM chrp based installs.

I had proposed to do so silently. I don't believe there is any sane reason for
rejecting this. As there is no sane reason to reject help on things one is
unable to do himself, nor to hinder people wanting to do the work. This is
opposite to debian's philosophy, which is a lead-by-action one.
(doing it silently meaning working on the fixes, committing them to the
archive and uploading them, doing the work on the hardware i have, or working
with users on debian-powerpc which have he one i don't have. With zero
involved traffic on debian-boot apart from uploads and svn commit logs).

Notice, that this is a technical issue, completely orthogonal with any social
dispute you have with me, and you are free to let us continue having our
little social warfare if you so desire, but once the technical hurdle is out
of the way.

This is why i thought it was ok to bring this to the TC, and why i tried to
keep it devoid of those messy social disputes.

So, bring the social dispute to medias appropriate to social disputes, and use
tools corresponding to social disputes to fight in it, like going for a ban on
debian-boot or ignoring me or whatever, but let me do the work than needs
doing.

And notice, that without those actions of yours, none of this would have
happened, and we would all be happily coding. Please think about this next
time you try to abuse your powers to solve a social problem.

TC members. This is in reality the question i ask, if this is not going to be
what you are judging on, let's better drop the issue, i had no intentions of
bringing the social warfar here. 

Friendly (maybe ?),

Sven Luther




Reply to: