Bug#673538: transition: gnustep-base, gnustep-gui
At Sun, 06 Jul 2014 11:41:07 +0200,
Paul Gevers wrote:
> On 03-07-14 18:44, Yavor Doganov wrote:
> >>> I'll ping you when the new core packages pass through NEW, OK?
> >>
> >> I don't see gnustep-gui 0.24 in NEW or in the archive. Was that ever
> >> uploaded? How are things looking here?
Release team: gnustep-gui/0.24 is already in experimental (thanks Aron
Xu and Luca Falavigna). I'm waiting for gnustep-back to get ACCEPTed
and built everywhere. Once done, we're basically ready (I only have
to backport my gnustep-base patch for the gnutls transition).
> It seems the GNUStep team is seriously lacking some help to upload its
> packages. I can only assume that there is no DD on your team (or that
> the team consists of one person).
The team consists of three people nowadays -- Gürkan Sengün, Federico
Gimenez Nieto and myself. None of us is DD/DM. The last DD in the
team stepped down 5 years ago.
> I am will to help with this transition by reviewing prepared
> packages and uploading.
Thanks.
> What exactly do you think is needed, all uploads related to [1]? Are
> the specific for this transition, or can they be done beforehand
> straight into unstable?
Everything that is at mentors.d.n is suitable for uploading to
unstable. I'm holding back the packages that depend on the new
libraries.
> How sure are you that they are real problems, I read you say they
> *may* lead to issues. Is there a way to check?
The way to check is to run the application, trying to test every bit
of functionaility on as many architectures as possible, or careful
code review. Both are very time consuming tasks.
> Which bugs you think *must* be fixed for this transition to be
> successful?
It depends which bit of the functionality of the package is affected.
If it makes the package mostly unusable then it is obviously a RC bug.
I plan to test all of them and adjust the severities accordingly.
I would like to fix all found bugs before the freeze, regardless of
their severity. We also want to ship the newest upstream releases,
and not versions that are obsolete and/or known to be buggy.
Currently there is a very bad publicity towards Debian in the GNUstep
community because of the wheezy release and the current status. There
are forked Debian/Ubuntu packages maintained in a PPA which nearly
every debianized GNUstepper is using. We definitely want to make
amends here.
> I have one request. As I don't know GNUStep and its apps (I haven't
> used any package of it before that I am aware of)
There is nothing special, really. Things are a little bit boxy,
that's all. aclock.app should be able to display the current time in
the clock, textedit.app should be able to do what a basic text editor
does, etc. There are some specialized apps like adun.app or
cenon.app, I don't know how to write a proper README.testing for
those.
> We started adding these README.testing files to packages maintained
> by the accessibility team to aid team members and I really like the
> idea.
Yes, the idea is good, but that is too much work for us currently. Is
it going to be proprosed for standartization? If I'm going to do
this, I'd better write a proper manual for the benefit of all users.
> For an example of what I mean you can look at daisy-player
If the package doesn't have decent documentation, large bits of this
file are suitable for README.Debian, IMHO.
Reply to: