On Thu, Apr 03, 2003 at 02:33:40PM +0200, Sven Luther scrawled:
> On Thu, Apr 03, 2003 at 08:10:09PM +1000, Daniel Stone wrote:
> > i386, powerpc, alpha - these are the architectures I have access to.
> > sparc and ia64 also usually get built, but I don't have direct access to
> > them. As I'm not a developer, I can't use d.o machines, either. alpha
>
> A, ... i didn't know that, this is rather a surprise, ... I suppose
> branden's X packages are also built by hand, are they not, or do the
> autobuilder build them ?
No, autobuilders build them automatically, because they're uploaded to
sid. If he needs to test building or a patch or such, porters do that,
however.
> What are your needs for the other arches ? Do we have a status report
> somewhere or something such ?
Someone to build it, check it builds, send me the output of (cd
debian/tmp && find ./ -type f | sed -e 's/^..//;'), wait for
*.files.$(ARCH) files and an updated MANIFEST, build *that*, and see if
it works. Not a huge amount of work, only if patches are needed for that
particular architectures.
> > hasn't built lately due to a gzip bug, but aj and asuffield are banging
> > out a patch on IRC right now.
>
> Ok, so 3 arches are building. I have access to a sparc box, altough not
> all the time, it is currently disconnected from the net and i will have
> access to it only next week. I also have plans to have access to a mips
> box, but it only has a small disk.
I've already got SPARC under control - it's ported, and there's a box
with a porter already I can use to build the debs. Right now, hppa, sh3,
sh4, m68k, mips, mipsel, *bsd-*, and maybe another I've forgotten, are
completely un-ported. s390 is in the process of porting.
> > Which will be a shame, sure. I've never attempted to claim otherwise.
>
> So let's do things so this don't happen. I suppose that once 4.2.1 makes
> it into testing, it would be ok to have an official 4.3.0 package, but i
> don't know Branden's plans. What will you do once that happens ?
I'm not doing anything in this regard. I'm just making the packages and
hosting them externally, until Branden has the time to take them up,
alter them as he sees fit (hopefully it will be almost zero alteration),
and upload them. The progress of XFree86 into sid has little to do with
me, other than I'm hastening and easing it.
> > Thing as, as I've said, Branden's working for free. And, not only are
> > you demanding he do something, but you're demanding he do something
> > *fundamentally* different, which he disagrees with.
>
> Did i demand anything of branden ? No i did not, i would not dare. But i
> am hoping that there are ways around it, like your packages for example.
My packages aren't subverting Branden's in any way, nor are they
attempting to be a fork, or anything. I do what I can to ensure that
Branden has to do as little as possible to pick them up and put them
into sid.
> > How does my public stance of "Hello, I need help, please give me a hand,
> > I'm happy to work with you" not invite cooperation? I've asked for help
> > at every turn, and thanked absolutely anyone involved with anything;
> > look at my initial mail about 4.3 to debian-x, if you're unsure about
> > either of these points.
>
> Well, ok, your meant Branden, and the official X strike force web page
> stance here.
Branden's typically been quite receptive to people who actually do the
work (e.g. Ishikawa-san), as opposed to people who just blow a lot of
hot air.
> > To be fair, coming in and saying that you'll NMU XFree86 for a minor bug
> > probably isn't the best way to approach it.
>
> It was no minor bug, i crashed my disk and needed to reinstall, and
> there was _no_ X package for ppc around, there was no such package for
> weeks, and every ppc developper was a bit pissed about it, at the same
> time, the next upstream release 3.3.6 i think, did contain the fixes for
> ppc, and built without problems. Sure i should not have done an NMU, but
> as said, i was a novice developper, and well, i was unstable.
As I wasn't there at the time, I can't really comment further on it.
> > Core stuff, sure. But what about something that, say, includes Xrandr
> > support in a ./configure check? What if that check gets tripped in 4.3
> > and it then fails in 4.2? There's a lot more scenarios, too, if you
> > stopped to have a think about it. Sure, libX11 hasn't bumped soname, but
> > a great deal of other things have.
>
> What's the problem with that ? If a library needs Xrandr, then it
> depends and build depends on xlibs (>> 4.3.0) and no problem shall
> appear. I have done so by using a shlibs override, but this could even
> be included in the upstream dpkg-shlibs or whatever the name of the tool
> is.
Except that it will be uninstallable and unbuildable for
everything/everyone that doesn't have 4.3. If you look at my
xlibs.shlibs, you'll notice that I've already done all the necessary
work here.
> > Not just that. New APIs. Lots of them.
>
> As said, our dependencies and build dependencies can handle that.
End result: people with 4.2.1 get shut out.
> > No, it's not public. "Do you think I should apply the IPv6 patch for
> > -0ds1? Looks quite clean to me and appears to work", (the reply was:
> > "I'm uneasy about introducing such a radical new feature in -1", FWIW),
> > isn't interesting to debian-x, it's just spam.
>
> And all the bug merging and such are not ?
The only thing I do with bugs is what you see with my BTS handling,
which is clearly visible through the BTS itself. Everything myself and
Branden do is visible through our changelogs; mine are certainly quite
verbose.
> Seriously, if you don't communicate, it seems as an opaque stuff and
> don't invite help, not that many people will join i know, but still. If
> it is too much for debian-x, then maybe a debian-x-4.3.0 or
> debian-x-devel mailing list ?
Considering there are only three of us actually doing Debian X
development, it would be quite a small list, really. As I said,
discussion is not the problem. The problem is that there are only three
people out there who are willing to/have actually done the work
required. That's not a large number, when you consider the demands of
XFree86 packaging.
I'll say it again: what we do *not* need more of is more invective on
mailing lists. We need more people to check and rediff patches, to try
and chase down old bugs, to track down user problems, to fix bugs. If
you want to help, there's a very clear way you can: look in the BTS,
find a bug, fix it, send the fix to the BTS. If there's no bug filed for
your problem, file one - "Tags: patch". It's quite simple.
The "development model" you cite isn't closed at all. Hell, jump on IRC
and you'll see half of it in public. My mails to Branden are generally
large, running through large swathes of patches, asking his opinion on
them, and every now and then, posing a few questions on how to do
something or rather, as well as a bit of personal communication.
I assure you it would bore you to tears. Really.
> > The key point here is that you haven't offered help, only demanded
> > Branden and I change our development models. I cooperate quite
>
> Hey no, i didn't demand, i just asked what were the plans, and pointed
> my fear, and told you my opinion on this. I understand why you are
> reluctant to do so, and respect that decision. I cannot join and help
> right now for time constraints, but this may change in the future, and i
> will try to help as much as i can.
Well, as I said, we don't need more mailing lists, or to have the
development model changed. In fact, for a team of 3, each working on
different parts with different aims, and none of us working anything
near full-time on it, we're doing remarkably well. What *is* needed, on
the other hand, is packagers, bug sweepers, patch people.
> > I have enough things in my plate, both paid and unpaid, to consume about
> > four times the time I currently have available. I don't want to take on
> > the responsibility of yet more upstream stuff.
>
> No problem, i didn't think you should, i think it would be the natural
> place for one of the debian X strike force members though.
Not necessarily; I see packaging and upstream as separate, although our
porting situation does blur the lines a bit.
> > Although I wasn't there at the time, I've been told that Mike just made
> > a mistake, not terribly much to it.
>
> As i understand it, he commited a bunch of untested stuff the day before
> the freeze, which broke things, needed work for undoing it, and delayed
> the release.
Fair enough. However, if he was quite inexperienced at the time,
pointing him in the right direction is more productive than shutting him
out altogether.
> > And our packages *are* IMHO the best quality, yes. That's why I don't
> > want to degrade that reputation by uploading packages I don't feel are
> > ready, to sid. Or packages that don't run on all our architectures. Your
> > two goals are conflicting: have the best packages, ergo get commit
> > access, and pump everything in before it's released.
>
> ???
Well, you're saying that we have the best quality packages, and that
they're very good. I agree with this.
However, you're also saying that we should focus on unreleased CVS
source, instead of what's in sid. This would drag our packaging down
quite badly, by not having the released stuff, guaranteed good quality.
You see what I'm getting at?
> > Which architectures is 4.2.1 lacking support for?
>
> Did i said it lacked suppport, no it just is out of date on 2/3 arches
> right now, i know it is being worked on though.
Yeah, something that's being actively worked on.
> > My discussions with Branden can best be described as "menial",
> > "semantical" and "utterly boring". They're about semantics. They're
> > nothing earth-shattering. They're not even interesting, unless you're
> > the one actually doing the packaging (i.e. me).
> >
> > I'll say it again: hot air on mailing lists isn't in the least helpful.
> > Contributions are.
>
> Sure, but keeping an archive of the problems going on helps one to know
> in what capacity he can get involved or if there is no need, or
> whatever.
They're not really problems as such, more just seeking Branden's opinion
on things. As I'm going to hand over to him, there's no point in me
doing things the way I like it, if it's just going to be more work for
him. It's almost entirely consisted of deciding when to start work on
splitting some packages, and which patches to merge and which to delay.
Trust me, uninteresting.
> > Want to help?
>
> Ok tell me, what do you need help with for the 4.3.0 packages ? I will
> try to build them this WE, and make myself familiar with the build
> system, and then we will see. But like said, i don't really have time
> right now, but this may change.
Porting - m68k, hppa, mips, mipsel, {free,net}bsd-*. Merging Michel
Daenzer's radeon-ddc patch - it doesn't apply at all cleanly.
That sort of thing. Nothing sexy, I'm afraid. Repetitive, long,
frustrating, menial, and boring. The stuff that needs to get done.
--
Daniel Stone <dstone@trinity.unimelb.edu.au>
Developer, Trinity College, University of Melbourne
Attachment:
pgpu0dujvYMRc.pgp
Description: PGP signature