Re: svn management, git, etc

[Frans Pop]

On Saturday 19 August 2006 20:26, David Nusinow wrote:
> > Huh?
> > cd 
> > svn export . 
> >
> > Works fine here...
>
> I don't get the xsfbs directory. Do you?

Haven't tried in your specific case, but used it quite a few times in 
other situations in local checkouts of the d-i repo and also the sarge 
branch for xfree86 of the XSF repo.

Maybe you need to 'svn up' just before the export?


pgpD9dz5e2hYF.pgp
Description: PGP signature

Re: svn management, git, etc

[David Nusinow]

On Sun, Aug 20, 2006 at 12:13:52AM +0200, Frans Pop wrote:
> On Saturday 19 August 2006 20:02, David Nusinow wrote:
> > Ok, it doesn't work locally. I guess that's a bug against svn then.
> 
> Huh?
> cd 
> svn export . 
> 
> Works fine here...

I don't get the xsfbs directory. Do you?

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Frans Pop]

On Saturday 19 August 2006 20:02, David Nusinow wrote:
> Ok, it doesn't work locally. I guess that's a bug against svn then.

Huh?
cd 
svn export . 

Works fine here...


pgpf2dejv6idt.pgp
Description: PGP signature

Re: svn management, git, etc

[David Nusinow]

On Fri, Aug 18, 2006 at 01:22:00AM +1000, Drew Parsons wrote:
> David wrote:
> > > I'm somewhat confused about the change you made on the svn page about
> > > using export to build and upload to Debian.  Export works just fine,
> > > including the xsfbs directory.  I think it's a much cleaner approach
> > > than copying the working directory since it ensures you're only
> > > uploading what is definitely in the repository.
> > 
> > It doesn't work here. Are you exporting from a local checkout or the remote
> > repository?
> 
> Remote, using the command I put on the wiki, e.g. most recently,
> 
> svn export svn://necrotic.deadbeast.net/xorg-x11/branches/7.1/lib/libxfont

Ok, it doesn't work locally. I guess that's a bug against svn then.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Drew Parsons]

David wrote:
> > I'm somewhat confused about the change you made on the svn page about
> > using export to build and upload to Debian.  Export works just fine,
> > including the xsfbs directory.  I think it's a much cleaner approach
> > than copying the working directory since it ensures you're only
> > uploading what is definitely in the repository.
> 
> It doesn't work here. Are you exporting from a local checkout or the remote
> repository?

Remote, using the command I put on the wiki, e.g. most recently,

svn export svn://necrotic.deadbeast.net/xorg-x11/branches/7.1/lib/libxfont

Drew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 15, 2006 at 10:17:28PM +, David Nusinow wrote:
> Ok, I've requested the alioth project. I've also added information about
> the git stuff at http://wiki.debian.org/XStrikeForce/Contrib

It has been created, I copied my docs there:
 git clone 
ssh://costa.debian.org/srv/git.debian.org/git/pkg-xorg/doc-hackers.git/
for a writable checkout (XSF members) and
 git clone http://arch.debian.org/git/pkg-xorg/doc-hackers.git/
for anonymous checkout, and updated the wiki.
At the moment, there is no git.debian.org alias, hence this strange URL ;)
More canonical URLs will certainly be available later.
Feel free anyone to send patches (or commit directly) to these docs,
this is a staging area to learn using git.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Wed, Aug 16, 2006 at 05:20:59PM +1000, Drew Parsons wrote:
> David wrote:
> > Ok, I've requested the alioth project. I've also added information about
> > the git stuff at http://wiki.debian.org/XStrikeForce/Contrib
> 
> Thanks for the updates to the wiki.
> 
> I'm somewhat confused about the change you made on the svn page about
> using export to build and upload to Debian.  Export works just fine,
> including the xsfbs directory.  I think it's a much cleaner approach
> than copying the working directory since it ensures you're only
> uploading what is definitely in the repository.

It doesn't work here. Are you exporting from a local checkout or the remote
repository?

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Mattia Dongili]

On Tue, Aug 15, 2006 at 09:31:02PM +, David Nusinow wrote:
> On Tue, Aug 15, 2006 at 11:16:51AM +0200, Mattia Dongili wrote:
> > On Mon, Aug 14, 2006 at 08:34:59PM +, David Nusinow wrote:
> > [...]
> > > Everyone should feel free to scratch any itch they feel like, but I want
> > > there to be a sense of ownership that's available if people want it.
> > 
> > David, XSF,
> > 
> > I'm wondering if it makes some sense for you and the XSF to push
> > xserver-xorg-input-synaptics[1] into your repository.
> > It makes sense for me at least, I suppose I could benefit some XSF
> > cohordination and ease cohoperation/help with the package.
> > And now that Xorg is modular... :)
> 
> Sure, but I think that ideally you should get access to the repo and do it
> yourself :-) If you want to do it, just write Branden with a public ssh key
> and he'll give you access. If not, we can wait until we move to git in a
> few months. Whatever you feel is best, but you're more than welcome on the
> team :-)

Great! Thanks :)

I'll wait for git on alioth, I already have a local git repository for
the package, it could be easily pushed then (or copied as is).

many thanks again!
-- 
mattia (waiting a few months for the new repo announce)
:wq!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Drew Parsons]

David wrote:
> Ok, I've requested the alioth project. I've also added information about
> the git stuff at http://wiki.debian.org/XStrikeForce/Contrib

Thanks for the updates to the wiki.

I'm somewhat confused about the change you made on the svn page about
using export to build and upload to Debian.  Export works just fine,
including the xsfbs directory.  I think it's a much cleaner approach
than copying the working directory since it ensures you're only
uploading what is definitely in the repository.

Drew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 15, 2006 at 09:36:52PM +, David Nusinow wrote:
> On Tue, Aug 15, 2006 at 09:20:41AM +0200, Denis Barbier wrote:
> > I started writing some documentation (mostly copied from the wiki and
> > READMEs), available via
> >   git clone http://people.debian.org/~barbier/git/xsf-docs.git/
> > If these pages are moved to Alioth, people could learn how to use git
> > by writing docs :-)
> 
> Nice! I'll request and alioth "xorg" project right now and we can maybe use
> these docs as a first stab once it's ready. It usually takes a few
> days/weeks to get a new project implemented on alioth from my previous
> experience, but since we're still in the early phases I'm happier with
> that. In the meantime maybe we can use the patch export/posting features
> that the kernel guys use to trade patches for the docs.

Ok, I've requested the alioth project. I've also added information about
the git stuff at http://wiki.debian.org/XStrikeForce/Contrib

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 15, 2006 at 09:20:41AM +0200, Denis Barbier wrote:
> On Tue, Aug 15, 2006 at 01:45:59AM +, David Nusinow wrote:
> > As per http://lists.debian.org/debian-devel/2006/08/msg00599.html we now
> > can use git.debian.org to hook in to alioth and do our work. We don't have
> > any projects set up yet, and I'm not sure exactly how this will go down,
> > but the biggest barrier outside of our own knowledge has fallen. If people
> > are really chomping at the bit, I'm willing to start putting something like
> > the apps in to git so we can get started learning it. The apps may prove to
> > be a big challenge though, since we're bundling them.
> 
> I started writing some documentation (mostly copied from the wiki and
> READMEs), available via
>   git clone http://people.debian.org/~barbier/git/xsf-docs.git/
> If these pages are moved to Alioth, people could learn how to use git
> by writing docs :-)

Nice! I'll request and alioth "xorg" project right now and we can maybe use
these docs as a first stab once it's ready. It usually takes a few
days/weeks to get a new project implemented on alioth from my previous
experience, but since we're still in the early phases I'm happier with
that. In the meantime maybe we can use the patch export/posting features
that the kernel guys use to trade patches for the docs.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 15, 2006 at 10:35:47PM +1000, Drew Parsons wrote:
> David wrote:
> > Please do go back and tag the uploads you made over the past several days
> > though. Those *need* to be done and it's something I plan to actively
> > enforce. Further, I'm going to ask you to not make any more uploads before
> > those tags are done. It's ok if you forget them on occasion, since I do
> > that myself. But they need to get done before they're forgotten. Thank you!
> 
> http://wiki.debian.org/XStrikeForce/svn-usage   ;)

Ah, I hadn't even looked at that page yet. I guess I should edit it a
little bit so it fits the way I've been using things.

> I reasoned that experimental wasn't important, and only the uploads to
> unstable need tagging.  I'll get it fixed up.

Nope, I consider them pretty important. They are releases, even if they're
just development releases. Thanks for taking care of it!

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 15, 2006 at 11:16:51AM +0200, Mattia Dongili wrote:
> On Mon, Aug 14, 2006 at 08:34:59PM +, David Nusinow wrote:
> [...]
> > Everyone should feel free to scratch any itch they feel like, but I want
> > there to be a sense of ownership that's available if people want it.
> 
> David, XSF,
> 
> I'm wondering if it makes some sense for you and the XSF to push
> xserver-xorg-input-synaptics[1] into your repository.
> It makes sense for me at least, I suppose I could benefit some XSF
> cohordination and ease cohoperation/help with the package.
> And now that Xorg is modular... :)

Sure, but I think that ideally you should get access to the repo and do it
yourself :-) If you want to do it, just write Branden with a public ssh key
and he'll give you access. If not, we can wait until we move to git in a
few months. Whatever you feel is best, but you're more than welcome on the
team :-)

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 15, 2006 at 09:38:33AM +0200, Denis Barbier wrote:
> On Mon, Aug 14, 2006 at 08:30:32PM +, David Nusinow wrote:
> > On Sun, Aug 13, 2006 at 01:39:48PM +0200, Denis Barbier wrote:
> > > On Tue, Aug 08, 2006 at 07:23:20PM +, David Nusinow wrote:
> > > [...]
> > > > > I like the patching system that's currently in place.
> > > > 
> > > > Me too. I think the consensus is to keep it, although I think pushing 
> > > > the
> > > > logic in to the quilt package is wise.
> > > 
> > > Can you please explain the last part of this sentence?  I do not 
> > > understand
> > > what should be pushed into quilt.
> > 
> > All the quilt-related stuff that's in xsfbs. Ideally we won't maintain it,
> > but it'll be part of what's included in quilt instead.
> 
> It looks like /usr/share/quilt/quilt.make is provided for this purpose,
> It does not redirect quilt output into a log file, but this is not a
> blocker for me.  What should be pushed into it before we can use it?

Logging might be nice, but I'd like it to have a patch-audit target too.
That's a valuable one. Aside from that though, nothing.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Re: svn management, git, etc

[Drew Parsons]

David wrote:
> Please do go back and tag the uploads you made over the past several days
> though. Those *need* to be done and it's something I plan to actively
> enforce. Further, I'm going to ask you to not make any more uploads before
> those tags are done. It's ok if you forget them on occasion, since I do
> that myself. But they need to get done before they're forgotten. Thank you!

http://wiki.debian.org/XStrikeForce/svn-usage   ;)

I reasoned that experimental wasn't important, and only the uploads to
unstable need tagging.  I'll get it fixed up.

Drew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Mattia Dongili]

On Mon, Aug 14, 2006 at 08:34:59PM +, David Nusinow wrote:
[...]
> Everyone should feel free to scratch any itch they feel like, but I want
> there to be a sense of ownership that's available if people want it.

David, XSF,

I'm wondering if it makes some sense for you and the XSF to push
xserver-xorg-input-synaptics[1] into your repository.
It makes sense for me at least, I suppose I could benefit some XSF
cohordination and ease cohoperation/help with the package.
And now that Xorg is modular... :)

Thoughts?

[1]: btw, the source package is still called xfree86-driver-synaptics,
I'm planning to change it in etch+1
-- 
mattia
:wq!


signature.asc
Description: Digital signature

Re: svn management, git, etc

[Denis Barbier]

On Mon, Aug 14, 2006 at 08:30:32PM +, David Nusinow wrote:
> On Sun, Aug 13, 2006 at 01:39:48PM +0200, Denis Barbier wrote:
> > On Tue, Aug 08, 2006 at 07:23:20PM +, David Nusinow wrote:
> > [...]
> > > > I like the patching system that's currently in place.
> > > 
> > > Me too. I think the consensus is to keep it, although I think pushing the
> > > logic in to the quilt package is wise.
> > 
> > Can you please explain the last part of this sentence?  I do not understand
> > what should be pushed into quilt.
> 
> All the quilt-related stuff that's in xsfbs. Ideally we won't maintain it,
> but it'll be part of what's included in quilt instead.

It looks like /usr/share/quilt/quilt.make is provided for this purpose,
It does not redirect quilt output into a log file, but this is not a
blocker for me.  What should be pushed into it before we can use it?

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 15, 2006 at 01:45:59AM +, David Nusinow wrote:
> As per http://lists.debian.org/debian-devel/2006/08/msg00599.html we now
> can use git.debian.org to hook in to alioth and do our work. We don't have
> any projects set up yet, and I'm not sure exactly how this will go down,
> but the biggest barrier outside of our own knowledge has fallen. If people
> are really chomping at the bit, I'm willing to start putting something like
> the apps in to git so we can get started learning it. The apps may prove to
> be a big challenge though, since we're bundling them.

I started writing some documentation (mostly copied from the wiki and
READMEs), available via
  git clone http://people.debian.org/~barbier/git/xsf-docs.git/
If these pages are moved to Alioth, people could learn how to use git
by writing docs :-)

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

Ok, I think it's time to take stock of it all and lay down some policy:

On Sat, Aug 05, 2006 at 06:12:19PM +, David Nusinow wrote:
> Hi everyone,
> 
>So we need to talk about how we manage the svn archive and plans for the
> future. Given upstream's move, I think it's pretty apparent that if we are
> going to change our repository, it's going to be to git. Since a number of
> people are clamoring for that, I think it's a safe bet that it needs to
> happen. The problem is that we almost completely lack experience with git.
> Andres has some experience with it, although I'm not sure he knows about
> certain details like repository conversion, and how our repo would convert
> over to a git repo. We may need to solicit Keith for advice on this, since
> he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> of switch until after we're frozen for etch, and even then there are issues
> like where to host it that need to be solved.

As per http://lists.debian.org/debian-devel/2006/08/msg00599.html we now
can use git.debian.org to hook in to alioth and do our work. We don't have
any projects set up yet, and I'm not sure exactly how this will go down,
but the biggest barrier outside of our own knowledge has fallen. If people
are really chomping at the bit, I'm willing to start putting something like
the apps in to git so we can get started learning it. The apps may prove to
be a big challenge though, since we're bundling them.

>As such, we need to make some decisions on certain things:
> 
> 1) Do we keep using the vendor branches? 

Since no one spoke up in favor of vendor branches, vendor is essentially
dead now. Commit directly to the branch of interest.

> 2) Do we keep putting the upstream tree in our svn repo?> 

While I'd love to have automated tools and such to make it easy to keep the
upstream tree out of the repo, svn-buildpackage doesn't work with our
current setup as far as I can see. Rather than worry about adapting to it,
or adapting it to our needs, I'd rather just push ahead and get moving
towards git. Once we're there and more experienced with it, let's
re-evaluate.

> 3) Do we need to keep using quilt?

The answer to this seems to be an unequivocal yes. We'll have to
re-evaluate when we move to git. stgit may prove to be a good replacement
for quilt, since we'll definitely want to keep a stack of patches that we
don't push upstream, for example to handle non-free bits of drivers.
However, I don't know how good git will be at managing this on its own. The
quilt stuff we've got is proven and workable and it seems to make many of
us very happy, so we can keep using it for now.

Other things I'd like to implement in the future, given people's comments,
are:

 1) Naming branches based on either a feature being implemented (such as
autodetection) or else based on Debian archive. Using upstream katamari
release numbers seems to be a pretty good policy for things like the
xorg package, but it just gets confusing for our branches. We'll name
them "experimental" and such instead. trunk should stay as trunk
though, corresponding to whatever is in unstable.

 2) Whittle away at xsfbs. This involves pushing the quilt stuff to the
quilt package, and whatever else we can come up with, maybe even
dh_xdriver or something.

 3) Write or support git-buildpackage. Not only would this prevent me from
risking carpal tunnel every time upstream rolls a new katamari, but it
would allow us to only keep the debian packaging in our repo if we so
choose. I think that git provides benefits to keeping the tree in-repo
though, since we can just pull from upstream directly, but this will
still prove to be a valuable tool.

 4) Set up a second list, probably on lists.debian.net that pasc announced
a little while ago, for repository commit mails. We're all probably
filtering them with procmail anyway, so moving them out of the way to
make it easier for people browsing the list that aren't subscribed is
probably wise. We may also want to stop providing diffs for the
changes. I use them constantly, but it's a lot of mail and they can be
really annoying at times.

> Please reply and let me know what you want and why you want it that way.
> Again, I don't care so much about the details provided that we are working
> in the best way possible. If what we're doing now isn't working for people,
> then we need to find a solution.

Thanks to everyone who replied. If anyone wants to take the lead on any of
these, please feel free to do so. If not, I'll get on it when I'm content
with our status for the release.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Mon, Aug 14, 2006 at 08:34:59PM +, David Nusinow wrote:
> Everyone should feel free to scratch any itch they feel like, but I want
> there to be a sense of ownership that's available if people want it.

That said, I want to encourage people to take ownership of whatever bits
they're interested in. Co-ownership is cool with me too, if someone wants
to co-own the server and some drivers with me. I'm happy to take my name
off the apps and libs if someone steps up and decides to grab them too.

I'm basically trying to strike a balance between the traditional Debian
"My Package Is My Fief" system, and the essentially freeform system used by
Ubuntu, so it does want for some package ownership. 

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: svn management, git, etc

[David Nusinow]

On Sat, Aug 12, 2006 at 09:27:37PM +1000, Drew Parsons wrote:
> > I'd
> > honestly rather keep it all in quilt and chuck the vendor branches (I'll
> > make a firm decision after the weekend on this so that anyone who wants to
> > weigh in has time).
> 
> I should 'fess up at this point that I didn't bother updating vendor
> for my most recent upgrades (libxi and libxaw I think), in anticipation
> of killing the vendor branch.  
> 
> If you decide to keep them after all, I'll do the update.

That's fine. I wanted to give anyone else the chance to speak up over the
weekend while I was away, but since they didn't we can just stop using them
and let them rot.

Please do go back and tag the uploads you made over the past several days
though. Those *need* to be done and it's something I plan to actively
enforce. Further, I'm going to ask you to not make any more uploads before
those tags are done. It's ok if you forget them on occasion, since I do
that myself. But they need to get done before they're forgotten. Thank you!

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Sun, Aug 13, 2006 at 01:48:58PM +0200, Denis Barbier wrote:
> On Tue, Aug 08, 2006 at 07:15:21PM +, David Nusinow wrote:
> [...]
> > I need to clean out the uploaders fields of packages, but basically my
> > policy on the issue is that the uploaders field defines who is the person
> > taking final responsibility within the XSF for the package. If you just
> > want to hack on things generally, please do so, but don't add your name to
> > the uploaders field unless you want to take full responsibility for any
> > changes in the package, including shielding your fellow teammates from
> > criticism for mistakes they've made.
> 
> Okay, but the upload is then considered as an NMU. Lintian complains
> and bugs are not closed, this is not ideal.  
> Maybe XSF people could put their name in the Uploaders field in the

To be quite honest, I don't care if lintian complains about this, and nor
should you. Lintian doesn't get to decide how we run the XSF, and I'm not
going to let it dictate a sub-optimal policy to us. 

I think it's vastly more important to have at least one person taking full
responsibility for every package maintained by the team than it is to have
lintian be 100% happy. I don't want a zillion people in the uploaders field
while only one or two actually make regular uploads, like we see in the
Gnome team. 

Everyone should feel free to scratch any itch they feel like, but I want
there to be a sense of ownership that's available if people want it.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Sun, Aug 13, 2006 at 01:39:48PM +0200, Denis Barbier wrote:
> On Tue, Aug 08, 2006 at 07:23:20PM +, David Nusinow wrote:
> [...]
> > > I like the patching system that's currently in place.
> > 
> > Me too. I think the consensus is to keep it, although I think pushing the
> > logic in to the quilt package is wise.
> 
> Can you please explain the last part of this sentence?  I do not understand
> what should be pushed into quilt.

All the quilt-related stuff that's in xsfbs. Ideally we won't maintain it,
but it'll be part of what's included in quilt instead.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 08, 2006 at 07:15:21PM +, David Nusinow wrote:
[...]
> I need to clean out the uploaders fields of packages, but basically my
> policy on the issue is that the uploaders field defines who is the person
> taking final responsibility within the XSF for the package. If you just
> want to hack on things generally, please do so, but don't add your name to
> the uploaders field unless you want to take full responsibility for any
> changes in the package, including shielding your fellow teammates from
> criticism for mistakes they've made.

Okay, but the upload is then considered as an NMU. Lintian complains
and bugs are not closed, this is not ideal.  
Maybe XSF people could put their name in the Uploaders field in the
uploaded package but not in SVN?

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 08, 2006 at 07:23:20PM +, David Nusinow wrote:
[...]
> > I like the patching system that's currently in place.
> 
> Me too. I think the consensus is to keep it, although I think pushing the
> logic in to the quilt package is wise.

Can you please explain the last part of this sentence?  I do not understand
what should be pushed into quilt.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: svn management, git, etc

[Drew Parsons]

> I'd
> honestly rather keep it all in quilt and chuck the vendor branches (I'll
> make a firm decision after the weekend on this so that anyone who wants to
> weigh in has time).

I should 'fess up at this point that I didn't bother updating vendor
for my most recent upgrades (libxi and libxaw I think), in anticipation
of killing the vendor branch.  

If you decide to keep them after all, I'll do the update.

Drew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Russ Allbery]

Denis Barbier <[EMAIL PROTECTED]> writes:

> Here are some things that annoy me:

>   * Flood of SVN commits to debian-x.
> I can use a procmail rule to filter them, but I often browse web
> archives.  See for instance current archive:
>   http://lists.debian.org/debian-x/2006/08/threads.html
> Dak messages are also annoying, but there is not much we can do
> if we want the Maintainer field to be debian-x.  IMO commit messages
> could be sent to another list, maybe at teams.debian.net?

The pkg-perl group uses separate addresses for the maintainer, the
discussion list, and the CVS commit list.  I think I like that setup a bit
better.  The package maintainer list gets all the bugs and therefore much
of the discussion, but that way there's a separate list for coordination
on major things.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 08, 2006 at 07:15:21PM +, David Nusinow wrote:
[...]
> > So David, do what you want, I have no strong opinion on anything related to
> > SCM, but please let us have fun.  This is surely what you want too, I hope
> > it will happen soon.
> 
> I'm truly sorry you feel that way. I had no idea. Please give me some
> feedback on what you want to make things more fun.

Here are some things that annoy me:
  * Flood of SVN commits to debian-x.
I can use a procmail rule to filter them, but I often browse web
archives.  See for instance current archive:
  http://lists.debian.org/debian-x/2006/08/threads.html
Dak messages are also annoying, but there is not much we can do
if we want the Maintainer field to be debian-x.  IMO commit messages
could be sent to another list, maybe at teams.debian.net?
This is especially true when there is an experimental branch, see
  * Web SVN interface:
I do not know if there is a good SVN web interface, svn.debian.org
is not better than XSF.  http://git.freedesktop.org/ looks much more
usable.
  * SVN layout:
This one is really minor, but there are some strange things, like
/tags which contains monolith/, or the contents of /tags/debian/{,xorg/}
  * Lack of documentation:
Documentation is never where I am looking for, this is bad ;)
For instance, I read Branden's message
  http://lists.debian.org/debian-x/2006/08/msg00055.html
about his tutorial on svn when coming back from vacation.  As it did
not contain an URL, I did not go to the wiki and after reading
hundreds of mails I forgot about Branden's post.  I found his (very good)
tutorial[0] yesterday when browsing XSF docs on the wiki.  IMO sending
this tutorial to the list with a link to the wiki would be much better,
people could read it easily and send comments.
Enough rants, since anyone can contribute to this one without any
particular knowledge, I hereby volunteer to work on improving current
documentation.  Not sure if it will be fun, but definitely useful ;)

Denis
[0] http://wiki.debian.org/XStrikeForce/svn-usage


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Wed, Aug 09, 2006 at 08:37:55PM +, David Nusinow wrote:
> Now with the modular tree, I'm willing to keep it all in the repo,
> depending on how things go. If git really does help us to push changes
> upstream, and I'm able to do this frequently and keep our patch number
> down, stopping quilt use may be a good idea.

For one of my packages, I experimented switching from quilt to feature
branches as described by Manoj in
  http://arch.debian.org/arch/private/srivasta/
first with tla, then baz and git.  I am still not convinced that
merging with new upstream versions is easier than with quilt.
OTOH I use git only to track my Debian packages locally and it is
obvious from Daniel's post (thanks Daniel for your explanations!) in
another subthread that my knowledge of git can be improved a lot.
Glad that we will switch to git, this is a fantastic opportunity to
learn new cool stuff :)

> We'll see how it plays out, but right now the benefits of using quilt
> for us seem to outweigh the downsides.

Absolutely.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Wed, Aug 09, 2006 at 11:50:55AM +0200, Christan Chiesa wrote:
> hello,
> 
> OK, first of all i introduce myself as no one know me and i never did
> something for X :). I'm Christian, I'm not a Debian Developer but, for
> the moment, I'm the maintainer of some packages (all packages
> maintained by Riccardo Setti, he's busy at the moment) and I'm
> interested in X :)

Pleased to meet you.

> I use svn for pkg-galago and pkg-utopia project (all hosted on Alioth)
> and atm I'm really happy with it. I'm not a svn guru or something
> similar i just use it for my Debian work without have any kind of
> problem :)
> As David said you don't need to have all source code in the svn but
> only Debian/ for autobuild your packages (through svn-buildpackage). I
> don't know how git could be more useful for you (maybe i should say us
> ;) ) but whit a suitable structure i think we couldn't switch to git.

Does svn-buildpackage work with our current repo layout? When I looked at
the various svn addon tool for Debian, they required a specific repo layout
and I wasn't sure if it was compatible with ours. I haven't spent the time
to investigate it closely.

> My idea is to have 3 master-branches experimental unstable and stable
> which have only the Debian Dir of all packages. something like:

This setup is more or less like we already have, at least in my mind. It's
not laid out by debian distribution so much as by upstream version, but it
maps to the Debian distribution in my brain (which is probably why it's
hazy to everyone else). Removing the upstream source is do-able, but
potentially a bit of a pain, especially if svn-buildpackage and friends
don't work for us.

> - we could switch to Alioth which have more bandwidth and has a lot of
> cool feature .

Yes, but also serious complaints over how well it has been maintained. I'm
interested in using it for a git repo, but I don't think the features it
buys us for svn usage amount to much.

> I'm not a coder so i cannot provide (code) patch for X,  what i can do
> is maintain the Debian packages: clean lintian errors, add copyright,
> change something if policy changes, triage bugs, talk with upstream.
> 
> I need for it only  a easy-to-use svn structure, nothing else.

No you don't. Using git to do simple things like this is fairly easy. See
http://wiki.freedesktop.org/wiki/UsingGit for info. This class of users I'm
not too worried about.

> If I'm a coder and a Debian maintainer i will need the same tools of
> the freedesktop guys plus a easy-to-use svn structure.

The freedesktop guys are all using git now, or will be soon. All the
upstream stuff for Xorg is in git. So in this case, you should know git and
not need the easy-to-use svn structure.

> - open a project on alioth. Import the 7.1 branches as experimental,
> trunk as unstable...for stable?

There's no need to move the svn repo to alioth. Branden has been responsive
enough about getting people accounts, and for my needs (and I guarantee you
that I have the most intense needs for this repo) the bandwidth is
sufficient, so that's a no-go right now. I'm interested in moving to alioth
at this point only if we're going to make a full switch to git.

> - Document what i made, and write a simple tutorial on how people
> should work on it. (Debian provides a lot of cool apps which will help
> our work)

The repo is actually fairly well documented for beginners by Branden.
People who get an account get the instructions. They need to be updated,
but they do exist.

The other thing you're completely ignoring is that git is vastly superior
for our needs in certain areas. Andres has complained about the various
branches. I have, sitting on my hard drive, three complete branches of the
Xorg source. The vendor branch (most all of 7.1), the Debian branches for
trunk (what's in unstable) and 7.1 (in experimental). Taking the size of
the X server tree from upstream, complete with 100% full history and every
single upstream branch in the main repo, the directory totals 61M. Just the
xserver from the Debian svn 7.1 branch is 119M. That's without any history.
And I have three of these on my hard drive just to do basic work. Forget
about feature branches too, this is just basic packaging stuff.

Furthermore, I have to do a lot of manual work to get upstream sources in
to our repo. Granted, with your plan this could be eliminated, but with git
I simply clone the upstream repo and I'm done. Then we have our own copy of
everything upstream has. Every single Debian contributor has a local copy
of not only the Debian changes but also upstream's. This is potentially
pretty huge in terms of convenience. If it helps me push patches upstream,
and also lets upstream know what we're doing, this is a big plus too.

Thank you for weighing in though. It's good to hear how other people are
using svn successfully.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Wed, Aug 09, 2006 at 07:53:13AM +0300, Daniel Stone wrote:
> Oh, if you're committing it anyway, then that works too, but if you have
> it in git, then given that all you need is 'git push origin' (to push
> everything), or whatever, then the barrier to entry for you is lowered a
> great deal, and the barrier to entry to us finding out exactly what
> Debian's done (I'm obviously comfortable dissecting Debian packages,
> others are not) is also lowered a great deal.

Right... the main reason Branden used to give me for keeping the patches
all in svn was that it was easy for upstream to figure out what we were
doing. A simple svn diff of the two URL's would do it.

In practice, keeping the quilt stuff constantly applied was sort of a pain
so I didn't do it although I did attempt it for a few days. That was the
other reason that, quite frankly, I forgot about in favor of keeping the
vendor branches around. Apparently we haven't been using them the way
they're meant to be used. That's fine by me though, at this stage. I'd
honestly rather keep it all in quilt and chuck the vendor branches (I'll
make a firm decision after the weekend on this so that anyone who wants to
weigh in has time).

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Wed, Aug 09, 2006 at 11:29:06PM +0200, Denis Barbier wrote:
> I use patch systems for some of my own packages, so am not against their
> use, but we must realize that external people have valid arguments
> against this use.

That's fair. I acknowledge that, and I admit that quilt isn't the be-all
end-all. But when we were carrying around over 100 patches to the
monolithic source tree, we couldn't reasonably keep them as one big glob in
svn. And moving to quilt allowed me to release 6.9 about 5-10x faster than
6.8 simply due to architecture improvements in the system.

Now with the modular tree, I'm willing to keep it all in the repo,
depending on how things go. If git really does help us to push changes
upstream, and I'm able to do this frequently and keep our patch number
down, stopping quilt use may be a good idea. We'll see how it plays out,
but right now the benefits of using quilt for us seem to outweigh the
downsides.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Daniel Stone]

On Wed, Aug 09, 2006 at 10:34:39PM +0200, Denis Barbier wrote:
> On Wed, Aug 09, 2006 at 07:53:13AM +0300, Daniel Stone wrote:
> [...]
> > > Yeah, getting all our patches merged upstream is of course a goal of mine,
> > > so this is heartening. Just out of curiosity, how would git be more 
> > > helpful
> > > than producing a diff and applying it to the upstream tree, followed by
> > > commit 'n push?
> > 
> > Oh, if you're committing it anyway, then that works too, but if you have
> > it in git, then given that all you need is 'git push origin' (to push
> > everything), or whatever, then the barrier to entry for you is lowered a
> > great deal, and the barrier to entry to us finding out exactly what
> > Debian's done (I'm obviously comfortable dissecting Debian packages,
> > others are not) is also lowered a great deal.
> 
> Are you implying that we will drop our patch system?  If not, I am
> curious to know how having our patches in git will help merging with
> upstream.

No, not necessarily.  The reason having your patches in git will help
merging, is because git diff will work fine, and git format-patch origin
will give you a list of all your patches against upstream, and if sent
as they are, we can just apply them with git-applymbox, and it preserves
date, ancestry (it gets applied at the right point in time, which makes
merges a lot easier: git will DTRT based on commits since, instead of
manually fixing rejects), and authorship information.

It also gives you a proper modification history.


signature.asc
Description: Digital signature

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 08, 2006 at 07:30:14PM +, David Nusinow wrote:
> On Sun, Aug 06, 2006 at 07:04:28PM +1000, Drew Parsons wrote:
[...]
> > Like you, I tend to feel keeping explicitly separate patches makes for
> > a cleaner solution when dealing with upstream source the size of
> > X.org.  Otherwise you've got to rabbit through the entire debian
> > diff.gz file to try to find what we changed from the upstream source. 
> > Keeping separate patches makes it simpler to push particular fixes
> > upstream, I think.
> 
> I agree. I think quilt has worked out extraordinarily well for us.

This issue is currently discussed on debian-devel in the "Centralized
darcs" thread.  Ian Jackson has valid points (IMO).  I also experienced
some trouble because of patch systems: I co-maintain the script which
extracts l10n material from source packages to generate statistics at
   http://www.debian.org/intl/l10n/
This script extracts PO files from tarballs, and apply .diff.gz.  It
works pretty well, but cannot deal with patch systems.  It is indeed
very difficult to know which patches are applied, and in which order.
Not to mention that tarballs-in-tarball source packages make this
task even more difficult.
The only safe way to do it would be to build the package, which consumes
way too much resources.  So when someone complained that a PO file
listed on these pages had already been patched in the Debian package,
I decided to ignore packages which use a patch system, because I could
not find a realiable way to extract l10n files.  That is unfortunate,
but I see no better solution at the moment.

I use patch systems for some of my own packages, so am not against their
use, but we must realize that external people have valid arguments
against this use.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Wed, Aug 09, 2006 at 07:53:13AM +0300, Daniel Stone wrote:
[...]
> > Yeah, getting all our patches merged upstream is of course a goal of mine,
> > so this is heartening. Just out of curiosity, how would git be more helpful
> > than producing a diff and applying it to the upstream tree, followed by
> > commit 'n push?
> 
> Oh, if you're committing it anyway, then that works too, but if you have
> it in git, then given that all you need is 'git push origin' (to push
> everything), or whatever, then the barrier to entry for you is lowered a
> great deal, and the barrier to entry to us finding out exactly what
> Debian's done (I'm obviously comfortable dissecting Debian packages,
> others are not) is also lowered a great deal.

Are you implying that we will drop our patch system?  If not, I am
curious to know how having our patches in git will help merging with
upstream.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Christan Chiesa]

hello,

OK, first of all i introduce myself as no one know me and i never did
something for X :). I'm Christian, I'm not a Debian Developer but, for
the moment, I'm the maintainer of some packages (all packages
maintained by Riccardo Setti, he's busy at the moment) and I'm
interested in X :)

I use svn for pkg-galago and pkg-utopia project (all hosted on Alioth)
and atm I'm really happy with it. I'm not a svn guru or something
similar i just use it for my Debian work without have any kind of
problem :)
As David said you don't need to have all source code in the svn but
only Debian/ for autobuild your packages (through svn-buildpackage). I
don't know how git could be more useful for you (maybe i should say us
;) ) but whit a suitable structure i think we couldn't switch to git.

My idea is to have 3 master-branches experimental unstable and stable
which have only the Debian Dir of all packages. something like:

unstable/
app/
mesautils/
 Debian/
tarballs/mesatuils_some-version.orig.tar.gz
(note:  tarballs will not be in the svn repo,  it will exist only on
the local machine )
data/
driver/
font/

experimental/
app/
..

stable/
.

Now, why switch to this style:

- easy to understand how you (maybe we ;) ) work. (atm i guess it's
not so understandable,  i agree with Danis though about this issue)

- easy for developer who are not involved in the project
(they don't have to know how we work) to work on it.
"hey, I'm $someone and i want to work on X but i don't know what
branch is should check out"

- we will not need anymore  the code in the svn.

- we could switch to Alioth which have more bandwidth and has a lot of
cool feature .

Why not :

I'm not a Debian X developer, in fact I don't know what are your
needs, this is only my experience with svn and Debian.

What i think is, if people want develop X and maintain it for Debian
they should distinguish the 2 things.

For example:

I'm not a coder so i cannot provide (code) patch for X,  what i can do
is maintain the Debian packages: clean lintian errors, add copyright,
change something if policy changes, triage bugs, talk with upstream.

I need for it only  a easy-to-use svn structure, nothing else.

If I'm a coder and a Debian maintainer i will need the same tools of
the freedesktop guys plus a easy-to-use svn structure.

Now, if people want code on X will need git for theyr work, i guess :).

OK, these are a lot of words (a italian man said "the facts count the
words are zero" (literals translation)).

What i can do now if people agree with my proposal (or at last want
try this style) is :

- open a project on alioth. Import the 7.1 branches as experimental,
trunk as unstable...for stable?
- Document what i made, and write a simple tutorial on how people
should work on it. (Debian provides a lot of cool apps which will help
our work)

regards,
christian

p.s (sorry for my bad english :( )


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Daniel Stone]

On Wed, Aug 09, 2006 at 10:12:42AM +0200, Michel Dänzer wrote:
> I think I'm becoming a relatively experienced git user, but I
> have very little experience with administration of a shared repository.
> We'd probably need an actual guru like Keith Packard for that, at least
> initially until we've accumulated the necessary know how.

It's pretty easy, you've just got to make sure sharedRepository is set
to 'true' in the core section of .git/config.  You can then push this
somewhere to be served by gitserve, or you can make sure
git update-server-info is run on every commit (maybe in the hook) if
the shared repository is exported via HTTP.

(Although I might be wrong, and this time anholt isn't around to correct
 me.)

Cheers,
Daniel


signature.asc
Description: Digital signature

Re: svn management, git, etc

[Michel Dänzer]

On Tue, 2006-08-08 at 19:36 +, David Nusinow wrote:
> On Tue, Aug 08, 2006 at 04:14:33PM +0200, Michel Dänzer wrote:
> > On Tue, 2006-08-08 at 15:40 +0300, Daniel Stone wrote:
> > > 
> > > If the eventual goal is to get all the patches merged upstream -- and I
> > > really hope it is -- then tracking git makes this infinitely easier, and
> > > infinitely more appealing from both sides to do so.
> > 
> > +1
> > 
> > It should simplify maintenance in general, e.g. we could just have
> > copies of the upstream repos with branches for the Debian packaging.
> 
> If I understand correctly, we'd initially clone the upstream repo and keep
> pulling that repo. Then we have separate debian (maybe deb_unstable,
> deb_experimental, etc) branches for our own work. To update to a new
> version from those branches, we update our cloned master branch, checkout
> the debian branch of interest, and pull the changes and we magically have
> the new upstream version. Is this correct?

Basically, yes. :)


BTW, I'm afraid calling me a git 'guru' is giving me way too much credit
though. I think I'm becoming a relatively experienced git user, but I
have very little experience with administration of a shared repository.
We'd probably need an actual guru like Keith Packard for that, at least
initially until we've accumulated the necessary know how.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Re: svn management, git, etc

[Daniel Stone]

On Tue, Aug 08, 2006 at 07:33:10PM +, David Nusinow wrote:
> On Tue, Aug 08, 2006 at 03:40:18PM +0300, Daniel Stone wrote:
> > FWIW, my vote (now from a purely upstream perspective) is to go with
> > git, despite my public reservations about git at the time we moved.
> > 
> > If the eventual goal is to get all the patches merged upstream -- and I
> > really hope it is -- then tracking git makes this infinitely easier, and
> > infinitely more appealing from both sides to do so.
> > 
> > (But maybe I'm missing something, because I never saw the point of the
> >  vendor branches.)
> 
> Yeah, getting all our patches merged upstream is of course a goal of mine,
> so this is heartening. Just out of curiosity, how would git be more helpful
> than producing a diff and applying it to the upstream tree, followed by
> commit 'n push?

Oh, if you're committing it anyway, then that works too, but if you have
it in git, then given that all you need is 'git push origin' (to push
everything), or whatever, then the barrier to entry for you is lowered a
great deal, and the barrier to entry to us finding out exactly what
Debian's done (I'm obviously comfortable dissecting Debian packages,
others are not) is also lowered a great deal.

Cheers,
Daniel


signature.asc
Description: Digital signature

Re: svn management, git, etc

[Christian Perrier]

> Christian, I appreciate your concern, but I can assure you that learning
> to use git is worth it. :) Especially if you're not familiar with any
> other truly decentralized SCM.


Hmmm, well, I already had to learn tla, then baz, then bzr and I also
use darcs, so I tend to accumulate experience with decentralized SCM
(which, btw, are a real PITA and no value added at all when it comes
at l10n maintenancebut I perfectly understand the reasons of
developers who use it for code maintenance).

As usual, all I will need is finding a good wizard for
"the-One-True-SCM-that-rocks" of the moment...until, of course, some
brand new shiny thing comes up

So, folks, go for the tool that will better suit your needs and the
l10n folks will follow you..:-)




signature.asc
Description: Digital signature

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 08, 2006 at 04:14:33PM +0200, Michel Dänzer wrote:
> On Tue, 2006-08-08 at 15:40 +0300, Daniel Stone wrote:
> > 
> > If the eventual goal is to get all the patches merged upstream -- and I
> > really hope it is -- then tracking git makes this infinitely easier, and
> > infinitely more appealing from both sides to do so.
> 
> +1
> 
> It should simplify maintenance in general, e.g. we could just have
> copies of the upstream repos with branches for the Debian packaging.

If I understand correctly, we'd initially clone the upstream repo and keep
pulling that repo. Then we have separate debian (maybe deb_unstable,
deb_experimental, etc) branches for our own work. To update to a new
version from those branches, we update our cloned master branch, checkout
the debian branch of interest, and pull the changes and we magically have
the new upstream version. Is this correct?

If I'm right, this is a whole lot easier than the current method, which is
a hassle and includes juggling a lot of different paths in the svn repo.
 
 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 08, 2006 at 03:40:18PM +0300, Daniel Stone wrote:
> On Tue, Aug 08, 2006 at 07:26:46AM -0500, Christian Perrier wrote:
> > /me dances happily when learning that I will have to learn Yet Another
> > Source Control Management System if I want to continue maintaining the
> > debconf l10n. 
> > 
> > Sure, this is a very minor aspect of the development of X packages,
> > but if my vote has some importance, it would definitely go for "stick
> > with SVN".
> 
> FWIW, my vote (now from a purely upstream perspective) is to go with
> git, despite my public reservations about git at the time we moved.
> 
> If the eventual goal is to get all the patches merged upstream -- and I
> really hope it is -- then tracking git makes this infinitely easier, and
> infinitely more appealing from both sides to do so.
> 
> (But maybe I'm missing something, because I never saw the point of the
>  vendor branches.)

Yeah, getting all our patches merged upstream is of course a goal of mine,
so this is heartening. Just out of curiosity, how would git be more helpful
than producing a diff and applying it to the upstream tree, followed by
commit 'n push?

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 08, 2006 at 07:26:46AM -0500, Christian Perrier wrote:
> Quoting David Nusinow ([EMAIL PROTECTED]):
> > Hi everyone,
> > 
> >So we need to talk about how we manage the svn archive and plans for the
> > future. Given upstream's move, I think it's pretty apparent that if we are
> > going to change our repository, it's going to be to git. Since a number of
> 
> 
> /me dances happily when learning that I will have to learn Yet Another
> Source Control Management System if I want to continue maintaining the
> debconf l10n. 
> 
> Sure, this is a very minor aspect of the development of X packages,
> but if my vote has some importance, it would definitely go for "stick
> with SVN".
> 

This is an important point, but to be honest you won't have to do much to
learn the stuff from git that you'll need. git clone/commit -a/diff/push
origin. Those commands should be sufficient for your needs. See also
http://wiki.freedesktop.org/wiki/UsingGit for more info.

That said, I'm a git newbie myself, so I share the trepidation about the
idea. On the other hand, I've seen some of the benefits upstream and I'm
excited by the possibilities it offers us.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Sun, Aug 06, 2006 at 07:04:28PM +1000, Drew Parsons wrote:
> David wrote:
> > Hi everyone,
> > 
> >So we need to talk about how we manage the svn archive and plans for the
> > future. Given upstream's move, I think it's pretty apparent that if we are
> > going to change our repository, it's going to be to git. Since a number of
> > people are clamoring for that, I think it's a safe bet that it needs to
> > happen. 
> 
> For my part, I don't have a really strong preference for one system
> over the other. I asked about git in a previous email just to hear what
> others think. It makes a degree of sense to follow upstream in using
> git, but we shouldn't feel obliged to have to do so. But I'm
> comfortable with it if we do switch.  By the way, I asked X.org why
> they preferred git, and they pointed to the arguments at
> http://lists.freedesktop.org/archives/xorg/2006-February/013113.html

The biggest issue with git for me at least is the lack of experience we
have with it. Upstream is still coming to grips with it, although they're
getting better at it. Andres has some experience with it, and Michel seems
to be our current reigning guru. I'm eager to learn more, but I'm worried
we'll struggle a lot with it at first when we need to focus on fixing RC
bugs for the release.

> > 1) Do we keep using the vendor branches? Are they worthwhile given that we
> >keep all important patches in quilt? My sense is no, they're not,
> >provided that we continue to use quilt this way.
> 
> Personally I don't truly understand what the vendor branch is for,
> maybe I'm too new to the XSF to appreciate it? Is it a back-up measure
> in case a holocaust strikes and all upstream copies of the original
> source are completely lost?  The only argument I've heard refers to the
> autobuild system, I'll comment on that at point 2.

Right, that's my sense.

> Like you, I tend to feel keeping explicitly separate patches makes for
> a cleaner solution when dealing with upstream source the size of
> X.org.  Otherwise you've got to rabbit through the entire debian
> diff.gz file to try to find what we changed from the upstream source. 
> Keeping separate patches makes it simpler to push particular fixes
> upstream, I think.

I agree. I think quilt has worked out extraordinarily well for us.

> That said, it does seem reasonable to me to keep a single copy of the
> upstream tarball (i.e. orig.tar.gz) in our repository.  And my comments
> here are perhaps not quite so useful in the case where we wrap our own
> orig.tar.gz tarball from the latest upstream git sources.

Yes, I think it's reasonable too, although perhaps not optimal. As Andres
noted, it does suck up a lot of bandwidth, as well as processor time when
working with such a large repo. I really like being able to make my patches
directly in the repo, but importing them with quilt is fairly simple as
well, so I'd be willing to sacrifice this conveneince for the added speed
elsewhere.

> > 2) Do we keep putting the upstream tree in our svn repo? My sense is that
> >we should continue to do so. The reason being that we regularly are
> >patching the auto* build system from upstream. Keeping those generated
> >files in-tree ensures that we have the same build system from machine to
> >machine. This is a hideously fragile system as it is, and keeping things
> >in-tree seems to provide some resiliancy. If someone has a good
> >mechanism to get around this, I'm all ears, because it is a pain to keep
> >it all in-tree.
> 
> I presume you mean here the upstream source in the working branch
> copy?  Don't patches apply well enough to the autobuild files as much
> as the source files?  I think I'd be comfortable keeping upstream
> source in branches, but I suppose it's "cleaner" to extract upstream
> source directly from the tarballs to ensure no patching is missed.  Is
> there any reason why any build-system changes can't be handled by
> patches like any other change?

Right, I think the autobuilder thing isn't really a big issue. There are
definite conveniences keeping the upstream tree in the repo. On the other
hand, svn-buildpackage is supposed to handle building packages from repos
that don't keep the upstream tree inside, but I'm not sure if this tool
will currently work with our repo.

> > 3) Do we need to keep using quilt? Branden's original plan was to keep the
> >upstream source in-tree and not use dpatch or quilt or anything like it.
> >This is an option, but if we go this route we need to keep using the
> >vendor branch. I'm inclined towards quilt myself, as its proven and it
> >works. On the other hand, we're carrying around quite a bit of code to
> >make sure quilt works for us. My plan is to switch our system over to
> >what's built-in to the quilt package to make the less of our problem,
> >but some people still prefer to keep it all in the repository.
> 
> I feel like I'm starting to repeat myself now :)  I 

Re: svn management, git, etc

[David Nusinow]

On Tue, Aug 08, 2006 at 03:59:13AM -0400, Andres Salomon wrote:
> On Sat, Aug 05, 2006 at 06:12:19PM +, David Nusinow wrote:
> > Hi everyone,
> [...]
> > he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> > of switch until after we're frozen for etch, and even then there are issues
> > like where to host it that need to be solved.
> > 
> 
> I've complained a lot about SVN in the past; however, a lot of my complaints
> have to do more with the way we're using it.  The SVN repo is hosted on a dsl
> connection, which makes it quite slow to do a check-out; on top of that, we
> need to deal w/ 3 separate branches (trunk, 7.1, and vendor) in order to work
> with it.  And finally, we're tracking upstream's source as well, which makes
> for a whole lot of unnecessary stuff that must go across the network (and
> sit on my hard drive).  Working with SVN would be a lot less of a hassle if
> the repository was a fraction of the size that it is now.

Right, I'm currently thinking that the vendor branch can and will go. I'll
give a few more days with it to see if anyone else speaks up in favor of
it, but currently it's slated for death.

As for the 7.1 versus trunk, I don't have a good way around that. It's just
a limitation of svn to need full checkouts for branches.

> > 1) Do we keep using the vendor branches? Are they worthwhile given that we
> >keep all important patches in quilt? My sense is no, they're not,
> >provided that we continue to use quilt this way.
> > 
> 
> Is there a point to keeping a vendor branch?  Upstream provides tarballs,
> upstream provides a git repository that's far more useful than our per-release
> vendor commits, and we have orig.tar.gz files on debian mirrors all over the
> world.. What does a vendor branch buy us?

Relatively little. If you want to easily diff the auto* stuff, it gives you
that. Other than that, not much. The auto* stuff didn't come in handy so
much as I'd hoped, so yeah... vendor can probably just go defunct unless
we have some real reason to keep it.

> > 2) Do we keep putting the upstream tree in our svn repo? My sense is that
> >we should continue to do so. The reason being that we regularly are
> >patching the auto* build system from upstream. Keeping those generated
> >files in-tree ensures that we have the same build system from machine to
> >machine. This is a hideously fragile system as it is, and keeping things
> >in-tree seems to provide some resiliancy. If someone has a good
> >mechanism to get around this, I'm all ears, because it is a pain to keep
> >it all in-tree.
> > 
> 
> The only good reason I'm aware of for keeping the upstream tree in our SVN
> repo is for the auto* stuff; and there is no guarantee that what's in
> the debian archive is actually what's in the SVN repo.  Have you ever
> autoreconf'd out of habit w/ updated auto*, without thinking twice about it?
> I have.  Committing those changes to a repository is an extra step, and
> doesn't seem overly worth it.
> 
> Instead, let's enforce certain things.  If we desire having a certain version
> of autoconf, automake, and libtool used for our packages, let's have checks
> in the actual code to ensure certain versions are used.  AC_PREREQ() in
> configure.ac comes to mind, for example.  Ensuring that a certain version
> of xutils-dev is used to rebuild could be done (looking closer, it appears
> someone's already implemented the framework for this:
> XORG_MACROS_VERSION(x.y)).  And so on..

I'd also like to shrink the repo. We'll need something concrete. We need to
know if we can use or adapt svn-buildpackage so that the build process is
automated. 

Also, would you mind producing a patch for some package to use as a testbed
for this? We'd need a way to easily enforce this across the whole package
set too. The patch mechanism we currently have isn't up to snuff for that
obviously, demanding a lot of manual labor. I don't know how to fix that
though.

> > 3) Do we need to keep using quilt? Branden's original plan was to keep the
> >upstream source in-tree and not use dpatch or quilt or anything like it.
> >This is an option, but if we go this route we need to keep using the
> >vendor branch. I'm inclined towards quilt myself, as its proven and it
> >works. On the other hand, we're carrying around quite a bit of code to
> >make sure quilt works for us. My plan is to switch our system over to
> >what's built-in to the quilt package to make the less of our problem,
> >but some people still prefer to keep it all in the repository.
> > 
> 
> I like the patching system that's currently in place.

Me too. I think the consensus is to keep it, although I think pushing the
logic in to the quilt package is wise.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[David Nusinow]

On Wed, Aug 09, 2006 at 12:35:11AM +0200, Denis Barbier wrote:
> External xsfbs modules are also time-consuming.  I rant against them whenever
> I do an update of the whole tree ;)

I agree, but I don't have a better solution for it yet. Perhaps git offers
something similar but superior? Alternately, I want to kill as much of
xsfbs as I can in the next release cycle, so maybe it's possible to kill it
all? dilinger keeps mumbling "cdbs2/3" in my general direction...

> But more generally, I guess that my rants come from some frustration on
> my side, it is no fun for me to hack on X.  It used to be too big, now
> it is modular but still complex, one has to understand what are all those
> branches and who can upload what.  My feeling is that I spend less time
> on hacking than on trying to understand how to do it the XSF way.
> So David, do what you want, I have no strong opinion on anything related to
> SCM, but please let us have fun.  This is surely what you want too, I hope
> it will happen soon.

I'm truly sorry you feel that way. I had no idea. Please give me some
feedback on what you want to make things more fun.

As for what you can do, feel free to commit to anything and pretty much to
upload anything you want. New upstream versions of libraries and the server
shouldn't be uploaded without some care, since they could break other
components. Especially now that we're near a freeze, we need to talk to the
release team before we do anything like this.

Bugfixes, especially packaging ones, can go up whenever you feel the desire. 

I need to clean out the uploaders fields of packages, but basically my
policy on the issue is that the uploaders field defines who is the person
taking final responsibility within the XSF for the package. If you just
want to hack on things generally, please do so, but don't add your name to
the uploaders field unless you want to take full responsibility for any
changes in the package, including shielding your fellow teammates from
criticism for mistakes they've made.

I think it's critical to have someone taking full responsibility for the
various packages to prevent the basic problem of teams where if everyone
has responsibility, no one takes responsibility.  It doesn't have to be me
though, so if you want to own more pieces than xkb-data, just go for it.

I really don't want to rule with an iron fist or anything, which is why I
tell people to just go for it and upload away. But I do want to make sure
every little piece is accounted for, even if it means that I have to do it.

I also want to make sure things are fun, and now that we're moving along at
a good pace we can relax a little and focus on doing cool things.  To me,
the two cool things I want are compiz (for this release) and autodetection
(next release). If you want to hack on something for fun (including those
projects, hint hint :-), just go for it.  That's what I'm doing :-)

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Denis Barbier]

On Tue, Aug 08, 2006 at 03:59:13AM -0400, Andres Salomon wrote:
> On Sat, Aug 05, 2006 at 06:12:19PM +, David Nusinow wrote:
> > Hi everyone,
> [...]
> > he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> > of switch until after we're frozen for etch, and even then there are issues
> > like where to host it that need to be solved.
> 
> I've complained a lot about SVN in the past; however, a lot of my complaints
> have to do more with the way we're using it.  The SVN repo is hosted on a dsl
> connection, which makes it quite slow to do a check-out; on top of that, we
> need to deal w/ 3 separate branches (trunk, 7.1, and vendor) in order to work
> with it.  And finally, we're tracking upstream's source as well, which makes
> for a whole lot of unnecessary stuff that must go across the network (and
> sit on my hard drive).  Working with SVN would be a lot less of a hassle if
> the repository was a fraction of the size that it is now.

External xsfbs modules are also time-consuming.  I rant against them whenever
I do an update of the whole tree ;)
But more generally, I guess that my rants come from some frustration on
my side, it is no fun for me to hack on X.  It used to be too big, now
it is modular but still complex, one has to understand what are all those
branches and who can upload what.  My feeling is that I spend less time
on hacking than on trying to understand how to do it the XSF way.
So David, do what you want, I have no strong opinion on anything related to
SCM, but please let us have fun.  This is surely what you want too, I hope
it will happen soon.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Michel Dänzer]

On Tue, 2006-08-08 at 15:40 +0300, Daniel Stone wrote:
> 
> If the eventual goal is to get all the patches merged upstream -- and I
> really hope it is -- then tracking git makes this infinitely easier, and
> infinitely more appealing from both sides to do so.

+1

It should simplify maintenance in general, e.g. we could just have
copies of the upstream repos with branches for the Debian packaging.

Christian, I appreciate your concern, but I can assure you that learning
to use git is worth it. :) Especially if you're not familiar with any
other truly decentralized SCM.


-- 
Earthling Michel Dänzer   |  http://tungstengraphics.com
Libre software enthusiast |  Debian, X and DRI developer

Re: svn management, git, etc

[Daniel Stone]

On Tue, Aug 08, 2006 at 07:26:46AM -0500, Christian Perrier wrote:
> /me dances happily when learning that I will have to learn Yet Another
> Source Control Management System if I want to continue maintaining the
> debconf l10n. 
> 
> Sure, this is a very minor aspect of the development of X packages,
> but if my vote has some importance, it would definitely go for "stick
> with SVN".

FWIW, my vote (now from a purely upstream perspective) is to go with
git, despite my public reservations about git at the time we moved.

If the eventual goal is to get all the patches merged upstream -- and I
really hope it is -- then tracking git makes this infinitely easier, and
infinitely more appealing from both sides to do so.

(But maybe I'm missing something, because I never saw the point of the
 vendor branches.)

Cheers,
Daniel


signature.asc
Description: Digital signature

Re: svn management, git, etc

[Christian Perrier]

Quoting David Nusinow ([EMAIL PROTECTED]):
> Hi everyone,
> 
>So we need to talk about how we manage the svn archive and plans for the
> future. Given upstream's move, I think it's pretty apparent that if we are
> going to change our repository, it's going to be to git. Since a number of


/me dances happily when learning that I will have to learn Yet Another
Source Control Management System if I want to continue maintaining the
debconf l10n. 

Sure, this is a very minor aspect of the development of X packages,
but if my vote has some importance, it would definitely go for "stick
with SVN".



signature.asc
Description: Digital signature

Re: svn management, git, etc

[Andres Salomon]

On Sat, Aug 05, 2006 at 06:12:19PM +, David Nusinow wrote:
> Hi everyone,
[...]
> he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
> of switch until after we're frozen for etch, and even then there are issues
> like where to host it that need to be solved.
> 

I've complained a lot about SVN in the past; however, a lot of my complaints
have to do more with the way we're using it.  The SVN repo is hosted on a dsl
connection, which makes it quite slow to do a check-out; on top of that, we
need to deal w/ 3 separate branches (trunk, 7.1, and vendor) in order to work
with it.  And finally, we're tracking upstream's source as well, which makes
for a whole lot of unnecessary stuff that must go across the network (and
sit on my hard drive).  Working with SVN would be a lot less of a hassle if
the repository was a fraction of the size that it is now.

[...]
> 
> 1) Do we keep using the vendor branches? Are they worthwhile given that we
>keep all important patches in quilt? My sense is no, they're not,
>provided that we continue to use quilt this way.
> 

Is there a point to keeping a vendor branch?  Upstream provides tarballs,
upstream provides a git repository that's far more useful than our per-release
vendor commits, and we have orig.tar.gz files on debian mirrors all over the
world.. What does a vendor branch buy us?


> 2) Do we keep putting the upstream tree in our svn repo? My sense is that
>we should continue to do so. The reason being that we regularly are
>patching the auto* build system from upstream. Keeping those generated
>files in-tree ensures that we have the same build system from machine to
>machine. This is a hideously fragile system as it is, and keeping things
>in-tree seems to provide some resiliancy. If someone has a good
>mechanism to get around this, I'm all ears, because it is a pain to keep
>it all in-tree.
> 

The only good reason I'm aware of for keeping the upstream tree in our SVN
repo is for the auto* stuff; and there is no guarantee that what's in
the debian archive is actually what's in the SVN repo.  Have you ever
autoreconf'd out of habit w/ updated auto*, without thinking twice about it?
I have.  Committing those changes to a repository is an extra step, and
doesn't seem overly worth it.

Instead, let's enforce certain things.  If we desire having a certain version
of autoconf, automake, and libtool used for our packages, let's have checks
in the actual code to ensure certain versions are used.  AC_PREREQ() in
configure.ac comes to mind, for example.  Ensuring that a certain version
of xutils-dev is used to rebuild could be done (looking closer, it appears
someone's already implemented the framework for this:
XORG_MACROS_VERSION(x.y)).  And so on..

> 3) Do we need to keep using quilt? Branden's original plan was to keep the
>upstream source in-tree and not use dpatch or quilt or anything like it.
>This is an option, but if we go this route we need to keep using the
>vendor branch. I'm inclined towards quilt myself, as its proven and it
>works. On the other hand, we're carrying around quite a bit of code to
>make sure quilt works for us. My plan is to switch our system over to
>what's built-in to the quilt package to make the less of our problem,
>but some people still prefer to keep it all in the repository.
> 

I like the patching system that's currently in place.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn management, git, etc

[Drew Parsons]

David wrote:
> Hi everyone,
> 
>So we need to talk about how we manage the svn archive and plans for the
> future. Given upstream's move, I think it's pretty apparent that if we are
> going to change our repository, it's going to be to git. Since a number of
> people are clamoring for that, I think it's a safe bet that it needs to
> happen. 

For my part, I don't have a really strong preference for one system
over the other. I asked about git in a previous email just to hear what
others think. It makes a degree of sense to follow upstream in using
git, but we shouldn't feel obliged to have to do so. But I'm
comfortable with it if we do switch.  By the way, I asked X.org why
they preferred git, and they pointed to the arguments at
http://lists.freedesktop.org/archives/xorg/2006-February/013113.html

> 
>As such, we need to make some decisions on certain things:
> 
> 1) Do we keep using the vendor branches? Are they worthwhile given that we
>keep all important patches in quilt? My sense is no, they're not,
>provided that we continue to use quilt this way.

Personally I don't truly understand what the vendor branch is for,
maybe I'm too new to the XSF to appreciate it? Is it a back-up measure
in case a holocaust strikes and all upstream copies of the original
source are completely lost?  The only argument I've heard refers to the
autobuild system, I'll comment on that at point 2.

Like you, I tend to feel keeping explicitly separate patches makes for
a cleaner solution when dealing with upstream source the size of
X.org.  Otherwise you've got to rabbit through the entire debian
diff.gz file to try to find what we changed from the upstream source. 
Keeping separate patches makes it simpler to push particular fixes
upstream, I think.

That said, it does seem reasonable to me to keep a single copy of the
upstream tarball (i.e. orig.tar.gz) in our repository.  And my comments
here are perhaps not quite so useful in the case where we wrap our own
orig.tar.gz tarball from the latest upstream git sources.

> 2) Do we keep putting the upstream tree in our svn repo? My sense is that
>we should continue to do so. The reason being that we regularly are
>patching the auto* build system from upstream. Keeping those generated
>files in-tree ensures that we have the same build system from machine to
>machine. This is a hideously fragile system as it is, and keeping things
>in-tree seems to provide some resiliancy. If someone has a good
>mechanism to get around this, I'm all ears, because it is a pain to keep
>it all in-tree.

I presume you mean here the upstream source in the working branch
copy?  Don't patches apply well enough to the autobuild files as much
as the source files?  I think I'd be comfortable keeping upstream
source in branches, but I suppose it's "cleaner" to extract upstream
source directly from the tarballs to ensure no patching is missed.  Is
there any reason why any build-system changes can't be handled by
patches like any other change?

> 3) Do we need to keep using quilt? Branden's original plan was to keep the
>upstream source in-tree and not use dpatch or quilt or anything like it.
>This is an option, but if we go this route we need to keep using the
>vendor branch. I'm inclined towards quilt myself, as its proven and it
>works. On the other hand, we're carrying around quite a bit of code to
>make sure quilt works for us. My plan is to switch our system over to
>what's built-in to the quilt package to make the less of our problem,
>but some people still prefer to keep it all in the repository.

I feel like I'm starting to repeat myself now :)  I like patching
because it declares explicitly what Debian has changed from upstream.
It lets us keep those changes in discrete units so we know what each
individual one is for. I'm inclined to think that makes it easier for
pushing the patches upstream.

In fact that was why I had chosen to use dbs for xprint - dbs keeps the
upstream source explicitly in its original pristine tarball which is
only unpacked at build time.  Patches to that upstream source are
created separately and explicitly.

> Please reply and let me know what you want and why you want it that way.
> Again, I don't care so much about the details provided that we are working
> in the best way possible. If what we're doing now isn't working for people,
> then we need to find a solution.

Likewise, I don't really mind what we do, so long as the consensus is
documented so that we know what we're doing!

Drew


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

svn management, git, etc

[David Nusinow]

Hi everyone,

   So we need to talk about how we manage the svn archive and plans for the
future. Given upstream's move, I think it's pretty apparent that if we are
going to change our repository, it's going to be to git. Since a number of
people are clamoring for that, I think it's a safe bet that it needs to
happen. The problem is that we almost completely lack experience with git.
Andres has some experience with it, although I'm not sure he knows about
certain details like repository conversion, and how our repo would convert
over to a git repo. We may need to solicit Keith for advice on this, since
he's got a lot of experience. Either way, I'm 100% unwilling to do any sort
of switch until after we're frozen for etch, and even then there are issues
like where to host it that need to be solved.

   In the interim, the question of how we manage the current repo has come
up. Specifically, with respect to vendor branches, but also to keeping the
upstream sources in-tree. This came up in the past, and I just went with
Branden's preferences, but now that we've got a lot more people committing,
we need to reach some kind of consensus rather than impose it from on high.
Personally, I don't really care how we manage the repo, provided that it
helps us work on providing excellent packages quickly. Perfection is, as
far as I'm concerned, a losing game.

   As such, we need to make some decisions on certain things:

1) Do we keep using the vendor branches? Are they worthwhile given that we
   keep all important patches in quilt? My sense is no, they're not,
   provided that we continue to use quilt this way.

2) Do we keep putting the upstream tree in our svn repo? My sense is that
   we should continue to do so. The reason being that we regularly are
   patching the auto* build system from upstream. Keeping those generated
   files in-tree ensures that we have the same build system from machine to
   machine. This is a hideously fragile system as it is, and keeping things
   in-tree seems to provide some resiliancy. If someone has a good
   mechanism to get around this, I'm all ears, because it is a pain to keep
   it all in-tree.

3) Do we need to keep using quilt? Branden's original plan was to keep the
   upstream source in-tree and not use dpatch or quilt or anything like it.
   This is an option, but if we go this route we need to keep using the
   vendor branch. I'm inclined towards quilt myself, as its proven and it
   works. On the other hand, we're carrying around quite a bit of code to
   make sure quilt works for us. My plan is to switch our system over to
   what's built-in to the quilt package to make the less of our problem,
   but some people still prefer to keep it all in the repository.

Please reply and let me know what you want and why you want it that way.
Again, I don't care so much about the details provided that we are working
in the best way possible. If what we're doing now isn't working for people,
then we need to find a solution.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]